Migrating to AEM Edge Delivery Services: it's not what you think

When teams hear "migrate to AEM Edge Delivery Services," most of them picture a platform upgrade. Swap the CMS, move the content, update the components, go live.

That's not what this is.

I recently ran a POC migrating a site to AEM EDS, using da.live for authoring and AEMCoder for content migration and block development. The technical work was interesting, but the more useful thing I came away with was this: the biggest risk in an EDS migration isn't the tooling. It's walking in with the wrong mental model of what EDS actually is.

So before getting into the specifics of how the migration went, it's worth stepping back and explaining what changes when you move to EDS, because it's more fundamental than most people expect.

What EDS actually is

EDS is not a new version of AEM Sites. It's a different delivery architecture entirely.

In traditional AEM, every page request hits the stack. Sling resolves the resource, components render HTML via HTL, OSGi services run business logic, the Dispatcher caches the result. The CMS is doing real work on each request, or at least on the first one before caching kicks in. Your codebase reflects this: Java, Sling Models, component dialogs, JCR content trees, OSGi configurations.

EDS works the other way around. Content is processed and pre-rendered at publish time, then served directly from Fastly's CDN edge. There's no origin server assembling a page per request. The rendering is done. The edge just serves it.

This shifts the development model completely. You're not writing server-side components anymore. You're writing blocks: lightweight JavaScript functions that decorate semantic HTML that EDS generates from the content source. The stack is vanilla JS, plain CSS, and GitHub. No build pipeline. No transpilation. No Java.

What stays the same (and what doesn't)

If you're an experienced AEM developer, some of what you know transfers across. Your understanding of content architecture, how sites are structured, how authors think about pages and components, that still matters. In fact, it matters more than I expected when it came to migration.

What doesn't transfer is most of the technical implementation. Sling Models have no equivalent in EDS. HTL templates don't exist. Your OSGi service layer, your component structure, your dispatcher rules, none of it maps across. You're starting the front-end from scratch, which sounds daunting but is actually one of the things that makes EDS faster to build on once you've made the mental shift.

The authoring model is also different. In our POC we used da.live, Adobe's document-based authoring environment. Authors structure content using documents and tables rather than component dialogs and page templates. It's a much lighter interface, and non-technical authors pick it up quickly. But it requires a different kind of content architecture thinking upfront, because the guardrails that AEM's dialog system provides just aren't there.

Where the complexity actually goes

One thing I want to push back on is the idea that EDS is simpler than traditional AEM. It's lighter in some ways, but the complexity doesn't disappear. It redistributes.

Less time on: OSGi configuration, Sling resolution performance, JCR query optimisation, dispatcher rules, Java dependency management.

More time on: content schema design, block architecture, how you govern what authors can do without dialog constraints, CDN configuration, and making sure your source content is structured cleanly enough to survive the migration.

That last point turned out to be the most important thing in our POC. The quality of your source site's content structure determines how smooth the migration is, more than any tool you use. I'll get into that in detail when I write up the content migration side of this work.

What this means if EDS is on your roadmap

The teams that struggle with EDS adoption are usually the ones that treat it as a hosting change or a version upgrade. It isn't either of those things. It's a different paradigm for building and delivering web experiences, and the earlier you internalise that, the better your migration will go.

The good news is that the development experience on the other side is genuinely fast. Once you're past the recalibration period, building blocks in vanilla JS with no build pipeline and no deployment overhead is refreshingly straightforward. And performance is essentially built in, Lighthouse 100 scores are the default, not something you tune for after launch.

But you have to get the mental model right first. That's what this article is about.

In the coming weeks I'll be writing up the rest of the POC: how AEMCoder performed on content migration and block development, what the da.live authoring experience was like in practice, and what I'd do differently on a real project.

If you're working with AEM and EDS is coming up in your conversations, follow along.