EDS Migration Is Not a CMS Swap — The Mental Model That Matters

Content Objective

This chapter covers:

• Why an EDS migration is not the same thing as a platform upgrade
• What changes in the delivery architecture when you move to EDS
• What from traditional AEM still matters and what no longer applies
• Why the authoring model changes when you move to da.live
• Where the complexity moves when you adopt EDS
• The mental model your team needs before migration work starts

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 is not what this is.

The biggest risk in an EDS migration is not the tooling. It is walking in with the wrong mental model of what EDS actually is.

What EDS Actually Is

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

In traditional AEM, every page request hits the stack. Sling resolves resources, components render HTML through HTL, OSGi services run business logic, and Dispatcher caches the result.

The CMS is doing real work on each request, or at least on the first one before caching kicks in.

EDS works the other way around. Content is processed and pre-rendered at publish time, then served directly from Fastly's CDN edge.

There is no origin server assembling a page per request. The rendering is done. The edge just serves it.

That shifts the development model completely. You are not writing server-side components anymore. You are writing blocks: lightweight JavaScript functions that decorate semantic HTML generated from the content source.

The stack is vanilla JS, plain CSS, and GitHub. No build pipeline. No transpilation. No Java.

What Stays The Same

If you are an experienced AEM developer, some of what you know still transfers.

Your understanding of content architecture still matters. How sites are structured still matters. How authors think about pages and components still matters.

In practice, that architectural understanding matters more than I expected when it comes to migration.

What does not transfer is most of the technical implementation.

• Sling Models have no equivalent in EDS.
• HTL templates do not exist.
• OSGi service layers do not map across.
• Component dialogs do not map across.
• JCR content trees do not drive the same rendering model.

You are starting the front end from scratch. That sounds daunting, but it is also what makes EDS fast to build on once the mental shift is complete.

The Authoring Model Changes Too

In our POC, authoring was done in da.live, Adobe's document-based authoring environment.

Authors structure content using documents and tables rather than component dialogs and page templates. It is much lighter, and non-technical authors usually pick it up quickly.

But it requires a different kind of content architecture thinking upfront.

The guardrails that AEM's dialog system gives you are not there in the same way, so the structure of the content needs to be designed more carefully.

Where The Complexity Goes

EDS is lighter, but it is not magic. The complexity does not disappear. It moves.

Less time goes into:

• OSGi configuration
• Sling resolution performance
• JCR query optimization
• Dispatcher rules
• Java dependency management

More time goes into:

• Content schema design
• Block architecture
• Governance for what authors can do
• CDN configuration
• Clean source content structure

That last point matters the most.

The quality of your source site's content structure determines how smooth the migration is more than any tool you use.

If the source content is inconsistent, the migration will be inconsistent.

What This Means For Teams

The teams that struggle with EDS adoption are usually treating it like a hosting change or a version upgrade.

It is neither.

It is a different paradigm for building and delivering web experiences.

The earlier your team internalizes that, the better the migration will go.

The development experience on the other side is genuinely fast.

Once you get through the recalibration period, building blocks in vanilla JS with no build pipeline and no deployment overhead is straightforward.

Performance is also built in. Lighthouse 100 scores are the default, not something you tune for after launch.

Final Rule

Do not ask, "How do we port AEM to EDS?"

Ask, "What authoring and delivery model does this content actually need?"

That is the question that keeps the migration grounded.

If you get the mental model right first, the rest becomes much easier.