01 — Introduction
AEM Sites and Edge Delivery Services solve similar business problems through very different delivery architectures. Both can publish and serve web experiences at enterprise scale, but they differ substantially in architecture, authoring, delivery model, development workflow, caching, deployment, extensibility and operational ownership.
This is not a question of old versus new. AEM Sites is a deeply extensible content and application platform. Edge Delivery Services is an edge-first delivery and development model with a different set of assumptions. Treating them as rivals obscures the real engineering question: where does the complexity of a given experience actually live, and which model carries that complexity with the least friction?
The comparison below is written for AEM developers, solution architects and technical leads evaluating how to deliver — or modernize — a specific set of experiences. It stays close to current Adobe terminology and avoids benchmarks or results that depend on a particular implementation.
AEM SITES EDGE DELIVERY SERVICES
--------- ----------------------
Author Content source
| |
Publish Edge
| |
Dispatcher Browser
|
CDN
|
Browser02 — What is AEM Sites?
AEM Sites is the traditional Adobe Experience Manager web experience platform. Content is created on an Author instance, replicated to Publish instances, cached and secured by Dispatcher in front of Apache, and typically fronted by a CDN before reaching the browser. The page is rendered by the AEM runtime through Sling resource resolution and HTL templates backed by Sling Models and OSGi services.
Its defining characteristic is depth of extensibility. Pages are composed from components and templates; structured and reusable content is modeled with Content Fragments and Experience Fragments; assets are governed in the DAM; business processes run through workflows; and custom backend logic lives in OSGi services and servlets. Enterprise integrations — commerce, search, identity, personalization, line-of-business systems — are commonly implemented as Java services inside the platform.
In other words, AEM Sites is as much an application platform as a CMS. The runtime application tier participates directly in page delivery, which is what makes it so customizable and what gives it its operational footprint.
Author -> Publish -> Dispatcher -> CDN -> Browser
\ /
OSGi services · Sling Models · HTL
Content/Experience Fragments · DAM
Workflows · enterprise integrations03 — What is Edge Delivery Services?
Edge Delivery Services (EDS) is a different content delivery and development model within the Adobe ecosystem. It is edge-first: pages are assembled and served close to the user, with reduced involvement of a traditional AEM application runtime in the delivery path. The result is a lighter request path and a frontend-led development workflow.
Authoring supports more than one pattern. Content can be authored in documents (for example, document-based authoring) or through AEM-based authoring, depending on how the project is set up. Frontend behavior is implemented with blocks — JavaScript and CSS composed per content structure — and the frontend code is deployed independently of content, commonly through a Git-based workflow.
It is a mistake to reduce EDS to “just static HTML.” It is a composable delivery approach with its own authoring, build and runtime conventions, oriented toward fast iteration and performance. The point is architectural: more of the delivery model is pushed toward the edge, and less of it depends on a traditional server-side application tier.
04 — The core architectural difference
The clearest way to see the distinction is the request path. In AEM Sites the runtime application tier is central to delivery; in EDS the edge is central, and the content source feeds it.
This single difference cascades through everything else in this article. When the application tier is in the delivery path, you gain deep server-side extensibility but you own more runtime, more caching topology and more operational surface. When delivery is edge-centric, the request path is simpler, but server-side extensibility moves elsewhere and the shape of customization changes.
AEM Sites
Author -> Publish -> Dispatcher -> CDN -> Browser
(runtime application tier participates in delivery)
Edge Delivery Services
Content source -> Edge delivery layer -> Browser
(delivery pushed toward the edge)05 — Development model
The two models ask for different engineering skill sets. AEM Sites development is Java-centric: Sling and OSGi services, HTL templates, Sling Model-backed components, repository and node-type design, Maven multi-module builds and Dispatcher configuration. The engineer reasons about the server-side runtime, the JCR and the publish topology.
EDS development is frontend-oriented: JavaScript and CSS, block-based composition, content delivered from the edge, and Git-centric workflows where applicable. The application runtime an engineer must reason about is lighter, and much of the work is in structuring content and shaping delivery and client behavior rather than extending a server-side platform.
Neither is inherently harder. They demand different competencies, and a team’s existing strengths — deep Java/OSGi versus modern frontend engineering — are a legitimate input into the architecture decision.
07 — Performance model
The two approaches embody different performance philosophies. AEM Sites performance is a topology discipline: Dispatcher caching, CDN caching, publish-tier scaling, runtime and backend optimization, and careful cache invalidation. Done well, it is fast; the cost is that performance is a property of the whole delivery chain you operate — a caching and invalidation strategy you design and maintain.
EDS is edge-first by design, aiming to minimize runtime dependency in the request path and to lean on aggressive edge caching combined with disciplined frontend performance. Conceptually, shifting assembly and delivery toward the edge reduces request-path complexity, because fewer tiers participate in producing each response.
No performance scores are claimed here, and real numbers always depend on implementation. The durable point is architectural: one model optimizes a multi-tier delivery chain you control; the other reduces the number of tiers in the path.
08 — Deployment & DevOps
Operationally, the release lifecycles differ. AEM Sites ships application releases: AEM packages built with Maven, delivered through Cloud Manager or enterprise CI/CD, alongside Dispatcher deployments, OSGi configuration and environment-specific settings. Code and content are coupled to a runtime that must be validated, deployed and operated.
EDS separates content from code and leans toward frontend code deployment through Git-centric patterns, which tends to reduce backend release complexity. The unit of change is often smaller and more frontend-scoped, which can shorten iteration cycles.
This difference matters for team structure as much as tooling. A mature AEM pipeline carries real platform-engineering responsibility; an edge-centric model moves part of that weight out of the application release and into content and frontend delivery.
09 — Customization & extensibility
AEM Sites remains stronger where behavior is deeply server-side: custom OSGi services, workflow and repository-based logic, complex CMS behavior, bespoke authoring experiences and tightly coupled enterprise Java integrations. When the experience’s complexity lives in backend logic and platform customization, that depth is the point.
EDS may be the better fit where the experience is content-driven and the server-side logic is comparatively light: high-performance delivery, simpler frontend architecture, rapid publishing and a desire to reduce runtime complexity. The composition model favors speed and delivery over deep server-side extension.
This is not a winner-and-loser comparison. It is a question of where extensibility is needed. Put the complexity where the platform is designed to carry it.
10 — Migration considerations
Moving from AEM Sites to EDS is not a frontend rewrite. It is an architectural change that touches the content model and the authoring model as much as the presentation layer. The scope is defined by what the current application actually depends on, not by the pages you can see. The same discipline applies to version work such as a 6.4 to 6.5 migration or a 6.5 LTS modernization: the risk lives in dependencies, not in the version number.
A credible assessment reviews the content model and authoring model; the component inventory; backend dependencies and OSGi services; workflows; integrations; personalization; analytics; forms; DAM usage; URL structure and SEO; caching; and the deployment model. Each of these can anchor logic that an edge-first model expects to live elsewhere.
Architecture should be evaluated against real application dependencies. The experiences that are genuinely content-driven may move cleanly; the ones backed by substantial server-side logic require a deliberate decision about where that logic goes.
- Content model and authoring model review
- Component inventory and backend dependencies
- OSGi services, workflows and integrations
- Personalization, analytics and forms
- DAM usage, URL structure and SEO
- Caching strategy and deployment model
11 — When AEM Sites may be the better fit
AEM Sites tends to be the stronger choice when the experience’s complexity is server-side and the platform investment is already mature.
- Deep custom backend logic and extensive OSGi services
- Complex authoring workflows and governance
- Tightly coupled enterprise Java integrations
- A mature Dispatcher and publish architecture
- Heavy platform customization and bespoke authoring
12 — When EDS may be the better fit
EDS tends to be attractive when the experience is content-led, performance-sensitive and comparatively light on server-side logic. It is not universally superior — it fits a particular shape of problem well.
- Content-heavy public websites
- Performance-sensitive marketing experiences
- Simpler application logic
- Rapid content publishing and frontend-led development
- A deliberate goal to reduce runtime complexity
13 — Hybrid architecture
The decision does not have to be binary. During modernization it is often practical for AEM to remain the content source while selected experiences adopt edge delivery, and other application areas stay on traditional AEM Sites.
A common shape keeps AEM as the governed source of structured content, exposes that content through APIs — for example Content Fragments over GraphQL — and lets edge-delivered experiences consume it, while server-side-heavy areas continue to run on the full platform. This lets teams modernize where it pays off without discarding mature, working investments.
AEM (content source of record)
|-- Traditional Sites (server-side-heavy areas)
|-- Content Fragments / APIs (GraphQL, structured content)
'-- Edge-delivered experiences (content-led, performance-first)14 — Comparison at a glance
The table condenses the differences. Treat it as a map of tradeoffs, not a scorecard.
| AEM Sites | Edge Delivery Services
----------------------+-------------------------------+------------------------------
Architecture | Author/Publish runtime tier | Edge-first delivery
Delivery | Dispatcher + CDN | Edge delivery layer
Backend runtime | Central to page delivery | Reduced in delivery path
Authoring | Component-driven, in-context | Document-based / AEM-based
Development model | Java/Sling/OSGi/HTL | JS/CSS blocks, frontend-led
Java/OSGi dependency | High | Low
Caching | Dispatcher + CDN topology | Aggressive edge caching
Deployment | Packages, Maven, Cloud Mgr | Git-centric frontend deploy
Customization | Deep server-side extensibility| Composition + frontend
Operational complexity| Higher (multi-tier runtime) | Lower delivery-path surface
Performance model | Optimize the delivery chain | Minimize the request path
Best suited for | Complex apps + integrations | Content-led, perf-first sites15 — My perspective
The interesting part is not choosing a fashionable architecture. It is understanding where the application’s complexity actually lives. Once that is clear, the right model is usually obvious, and it is often different for different parts of the same estate.
In practice I evaluate six things before the technology: the content and its model, the real backend logic, the integrations, how authors actually work, the operational model a team can sustain, and the delivery requirements. Those inputs decide the architecture — not the reverse.
Read that way, AEM Sites and EDS are tools with different centers of gravity. A pragmatic engineer matches the center of gravity of the problem to the center of gravity of the platform, and is comfortable running both where that serves the estate.
16 — Conclusion
AEM Sites and Edge Delivery Services are not simply old versus new. They represent different architectural tradeoffs: one puts a deeply extensible application runtime in the delivery path, the other pushes delivery toward the edge and keeps the path light.
The correct choice depends on the content model, the authoring needs, the backend logic, the integrations, the performance goals and the operational model a team can realistically run. Evaluate those honestly, allow for hybrid approaches during modernization, and the architecture decision becomes an engineering judgment rather than a trend.
References
Related engineering notes
Related engineering work
- AEM 6.4 to 6.5 Migration: Compatibility and Release Validation
- AEM 6.5 LTS Modernization: Java, OSGi and Legacy Code Readiness
- Headless AEM: GraphQL and Sling Model Exporter Delivery Boundaries
- AEM Dispatcher and CDN Caching: Keys, Invalidation and Freshness
- AEM Content Fragment Modeling: Reuse, References and Schema Evolution