Most Edge Delivery migrations don’t stall on the destination. They stall on the source.
The destination is well-documented and mostly the same from project to project. The source is a snowflake: every site was built by a different team, over a different decade, with its own quiet conventions and its own accumulated mess. So teams sit down and rebuild the extraction logic by hand, region by region, page type by page type, and they do it again from zero on the next site. That hand-built, un-repeatable labor is the real cost of a migration. Not the target.
We built Launch Studio’s migration engine around that observation, plus a second one: on a migration, you should never have to guess. It’s a no-code pipeline that turns content extraction into a consistent, repeatable process, keeps the destination model under your control, and shows you exactly what will migrate before anything does. It runs into three Adobe destinations: content into Document Authoring or JCR authored through the Universal Editor, and the assets on those pages into your DAM.
The snowflake tax
Here’s the pattern that makes migration quotes balloon. A team wins the work, opens the source site, and finds that the “article” template has been used eleven slightly different ways. The hero is a component on some pages and a stack of free-floating rich text on others. A promo that looks identical across the site is authored three incompatible ways underneath. None of it is wrong, exactly. It’s just bespoke, and bespoke doesn’t automate.
So the team writes a transformer for this site. It works, more or less, and it’s thrown away the moment the project ends because it encoded the quirks of one snowflake. The next migration starts the extraction logic over. The cost never comes down, because nothing compounds. That’s the tax, and it’s why “we’ll just migrate it” is the line that sinks so many EDS timelines.
The mistake underneath it is letting extraction stay improvised: eyeball each page, hand-pull the content, push it into the new place, fix what broke, do it again. Improvised extraction is per-site by definition, so nothing carries to the next project. The fix isn’t to skip extraction. It’s to make it a disciplined process a person configures once, by pointing at the elements that matter, and then reuses.
Two layers: consistent extraction, a model you control
It helps to separate two things most migrations blur together: pulling content off the old page, and shaping it for the new one.
Extraction is the first layer, and it works the same regardless of where the content is going. You identify the pieces that matter on a source page by their targetable elements, and the engine pulls them. No code, no per-page programming; someone who can recognize “this is the headline, that’s the eyebrow, those are the cards” can configure it. Because it keys off what’s on the page rather than where the content lands, the same extraction approach holds across a whole site, and it’s the part that carries from one migration to the next.
The model is the second layer, and it’s specific to the destination. Document Authoring and JCR use different content models, so mapping extracted content into a model is done per target: a DA model for a DA project, a JCR model for a JCR one. The extracted content is the raw material; the model is how you shape it for the place it’s going, and those places genuinely differ.
That split is also where we draw a line the rest of the category doesn’t. Other AEM migration tools point AI at the page and let it decide what your content is and where it belongs. That’s probabilistic: it’s a guess, and you find out whether the guess was right after thousands of pages have already moved. Launch Studio uses AI in exactly one place, to recommend a starting model from the page’s DOM. You accept it, adjust it, or replace it. The model and every mapping stay yours, and you audit them before a single page migrates. Deterministic, not probabilistic. No discovering you were off-target ten thousand pages too late.
See it before you run it
Determinism only means something if you can actually see what the configuration will do, so mapping is visual and hands-on.
Point the engine at any site and it crawls the source in a secured sandbox, so nothing you’re migrating runs in your own environment. Then you configure the mapping with Flightpath overlays: the live source with your mapping drawn on top of it, showing exactly which region of the old page becomes which block, before you commit. You’re auditing the migration against the real site, not guessing from a config file what a rule will capture.
Output lands as DA-HTML, Markdown, or DOCX, and migrated files are staged in Launch Studio’s connected data storage so images resolve as absolute URLs instead of hot-linking the origin you’re leaving. The crawl, map, and export loop has been in place since the start of the year; the modeling layer that turns those overlays into a saved, reusable configuration is what landed this summer.
Three destinations, one engine
The engine was built to migrate from any platform into AEM, and the three targets aren’t three products bolted together. Two of them are the same kind of thing, an EDS front end, that differ in content source and authoring tool. The third isn’t a separate migration at all: it’s the assets on those pages, extracted and sent to your DAM as the content moves.
| Destination | What it is | When you reach for it |
|---|---|---|
| Document Authoring (DA) | EDS content authored as documents on da.live | Teams that want the lightest authoring surface and fast document-based publishing |
| JCR / Universal Editor | EDS content sourced from AEM’s JCR, authored in-context in the Universal Editor | Teams that want structured, WYSIWYG in-context editing on top of the same edge delivery |
| DAM (assets) | Images and files pulled from the source pages during migration, mapped into your DAM | Every content migration; the page’s assets follow the content automatically |
Document Authoring and the Universal Editor: shared delivery, separate models
This is the pairing the market treats as a fork in the road, so it’s worth being precise. Document Authoring and the Universal Editor are both front-end EDS projects: the same edge-delivered blocks, the same repo conventions, the same AEM Code Sync, and the same extraction on the way in. What they don’t share is the content model. DA and JCR use different ones, so you build the model for whichever you’re targeting and map the extracted content into it. They aren’t two separate migrations held together by hope; the engine, the extraction, and the delivery are one, and the model is the piece that’s specific to where you land.
Assets ride along with the content
The images and files on a page aren’t a separate migration. As content is extracted, the assets on those pages come with it, and their references are linked to the migrated content so nothing hot-links the origin you’re leaving behind. You decide where they land: mapped into a taxonomy that mirrors the site, or into a specific assets location you choose. And if your assets already live on an external DAM or CDN that handles storage and delivery, you can leave them there and keep the existing production URLs rather than copying them into AEM at all. What migrates is what’s reachable from the pages themselves. This is asset extraction that completes a content migration, not a standalone DAM project.
Reuse is where it scales
Add all of that up and the payoff isn’t one clean migration. It’s the second one, and the fiftieth.
Any mapping you build in Launch Studio can be exported and imported into the next site’s migration. That matters most for teams standardizing many sites onto a shared template and block library: because the destination model stays mostly the same from site to site, the migration modeling is almost entirely reusable, and only the legacy-side extraction needs adjusting to fit each new source. In practice that takes roughly 80% of the design effort out of each additional site, on top of the visual mapping process that already made the first one faster.
That’s the real answer to the snowflake tax. The bespoke part of every migration, learning the quirks of one old site, gets confined to the extraction layer and done by pointing rather than programming. The expensive part, the model, is built once for a destination and carried forward. A lean team can run migrations at a scale that used to need a full practice, without a migration team’s worth of developers and without betting the outcome on an AI’s guess.
It’s the same principle we describe in Migrating to Edge Delivery Services Is a Paradigm Shift: the work doesn’t vanish, it moves to where it belongs. Here it moves out of disposable per-site labor and into a reusable configuration you own. That’s why we call Launch Studio snap-on, not rip-and-replace. You keep your content and your Adobe investment, and you stop paying the snowflake tax on every move.
If you’re scoping an EDS migration and want to see extraction configured by pointing at a page, a model you can audit before anything runs, and a mapping you can reuse on the next site, we’re happy to walk through your actual source. Tell us what you’re migrating and we’ll come back with specifics, or map a real site with you in about twenty minutes.
