Traditional AEM Sites, Edge Delivery Services or headless is the wrong first question

Architecture conversations often begin with three labels: traditional AEM Sites, Edge Delivery Services or headless.

The label quickly becomes a preference. Edge Delivery Services is associated with performance and speed. Headless is associated with modern front ends and omnichannel reuse. Traditional Sites is associated with an existing estate that stakeholders want to modernise.

None of those associations is a requirement.

The first question should be: what must authors, customers and operators be able to do, and which responsibilities is the organisation prepared to own? The delivery architecture should follow that answer.

The three approaches move responsibility differently

Traditional AEM Sites

Traditional Sites combines component-based page authoring, templates, workflows, publishing and delivery in a mature AEM operating model. It is strong when marketers need structured in-context page composition, established governance and deep platform integrations.

Its cost appears in platform specialisation, component lifecycle and the temptation to preserve years of customisation because it already exists.

Edge Delivery Services

Edge Delivery Services changes both delivery and authoring choices. Adobe supports document-based authoring with tools such as Word or Google Docs and AEM authoring with Universal Editor, while delivery is built for high-performing edge-served experiences.

It is not merely a faster Dispatcher configuration. Teams need new content conventions, block development, repository and release practices, asset integration and author support.

AEM Headless

AEM Headless uses Content Fragments and APIs such as GraphQL to deliver structured content to independently built applications. It is valuable when the same governed content must serve several channels or when the experience application genuinely needs independent technology and release cycles.

It also moves layout, preview, routing, caching, personalisation integration and much of the experience assembly into the consuming application.

Headless removes page delivery from AEM. It does not remove the work required to deliver pages.

Start with the authoring job

Ask authors to demonstrate real work:

• launch a campaign landing page;
• reuse a governed content block;
• localise content across markets;
• preview an unpublished change in context;
• schedule a release;
• correct a production error; and
• understand why publication failed.

Then evaluate each architecture against those tasks.

Document-based authoring can reduce CMS friction for familiar editorial workflows. Universal Editor can provide in-context editing across supported implementations. Traditional page authoring can provide stronger composition and established controls. Structured Content Fragment editing can serve omnichannel content but may feel abstract when authors need to visualise a complete page.

An architecture that improves Lighthouse scores while doubling campaign assembly time has shifted cost rather than removed it.

Headless needs a real multi-channel case

Content Fragments are appropriate for page-independent structured content. They should be designed as durable schemas because front ends and integrations depend on their field names and relationships.

Headless is compelling when:

• several channels consume the same content model;
• a custom application cannot use AEM page delivery;
• front-end release independence creates measurable value;
• content is structured enough to survive outside one layout; and
• the organisation can own the API and preview experience.

It is weak when “headless” simply means rebuilding a marketing website in another framework while authors lose in-context control and the organisation inherits two platforms.

Adobe recommends persisted GraphQL queries for performance. They can be cached at CDN and Dispatcher tiers and create a more deliberate API contract than arbitrary client queries. The team still needs invalidation, update-frequency and personalised-content strategies.

Edge Delivery Services changes the migration unit

For a greenfield site, teams can design blocks, content conventions and authoring around Edge Delivery Services from the start.

For a brownfield estate, the migration is rarely a technical switch. Existing templates, components, workflows, localisation, analytics and author habits do not map one-to-one. The unit of migration should be a business journey or content family, not the entire repository by default.

An incremental pattern can be safer:

• keep stable Sites experiences operating;
• use Edge Delivery Services for a new campaign family or market;
• establish shared design, analytics and asset rules;
• measure author and delivery outcomes; and
• expand only when the operating model is proven.

Hybrid is not architectural failure if boundaries and ownership are explicit.

Cloud operation changes more than hosting

AEM as a Cloud Service brings immutable application deployment, Cloud Manager pipelines, managed scaling and different constraints around Dispatcher, CDN and runtime access. Local behaviour is not sufficient evidence for cloud behaviour.

Dispatcher rules, HTTP methods, headers and caching can also be affected by upstream CDN and managed-service controls. Validate the complete request path in a cloud environment rather than assuming a local Dispatcher reproduction is equivalent.

For AMS-to-Cloud or AEM 6.5 LTS work, separate platform migration from experience-architecture change. Doing both at once can be appropriate, but it increases the number of causes behind every defect and makes rollback harder.

Use a decision scorecard

Score each candidate against weighted requirements.

Authoring and governance

• in-context composition;
• structured reuse;
• workflow and approval;
• localisation;
• training and adoption; and
• accessibility and brand control.

Experience delivery

• performance objectives;
• personalisation and experimentation;
• channel count;
• preview requirements;
• release independence; and
• resilience and fallback.

Engineering and operations

• available skills;
• deployment and support model;
• caching and invalidation;
• integration complexity;
• observability; and
• security and compliance.

Migration economics

• reusable content and code;
• content transformation;
• duplicate operation during transition;
• author change management;
• retirement plan; and
• total lifecycle cost.

Do not give every criterion equal weight. A regulated author-approval requirement can be more important than marginal delivery performance. A high-volume public experience may reverse that weighting.

Keep cross-product personalisation deliberate

AEM, Target, AJO, AEP and Dynamic Media can create powerful personalised experiences. They can also produce overlapping ownership.

For each experience, define:

• where content is authored and approved;
• where eligibility and decisioning occur;
• which system renders the final experience;
• how page and campaign context are passed;
• where exposure and conversion are measured; and
• how the experience behaves when one dependency is unavailable.

Embedding an AJO form or Target offer into an AEM page is not only a component problem. Styling, consent, identity, analytics and operational ownership cross the boundary.

What to measure

• author task completion time and support demand;
• time from approved brief to production;
• reuse across pages, markets and channels;
• Core Web Vitals and business conversion;
• deployment lead time and failure rate;
• content and API cache effectiveness;
• incidents caused by unclear cross-platform ownership;
• custom code and component lifecycle cost; and
• legacy estate retired after migration.

Adovo’s view

Traditional Sites, Edge Delivery Services and headless are not maturity levels. They are different allocations of responsibility.

Choose from authoring work, channel needs, delivery objectives and the operating capability the organisation will actually fund. Use headless when content genuinely needs independent consumers. Use Edge Delivery Services when its authoring and delivery model fit the experience. Keep traditional Sites where its composition and governance create more value than a rewrite.

Modern architecture is not the newest label. It is the smallest set of responsibilities the organisation can operate well.

Primary documentation and further reading

• Adobe AEM Sites and Edge Delivery Services
• Adobe headful and headless AEM models