The Dusk and Dawn of AEM: The Dilemma of Traditional Development Models and the Prospects of Edge Delivery

Release Date: 2026-08-31

Author: William

Introduction

The research by MACH Alliance presents a striking figure: enterprises adopting a fully composable architecture are six times more likely to achieve clear returns on technology investments compared to other enterprises [1]. Corporate technology architecture is shifting from "one platform does it all" to "choosing the best service for each link"—an increasing number of clients are consulting on how to split, migrate, or at least partially migrate traditional AEM sites to a lighter delivery architecture.

Characteristics of the target scenario:

l Has been running AEM for over 5 years, with significant technical debt, and each release is a battle.

l The content team complains about the editor being difficult to use, the marketing team complains about slow pages, and the development team complains about slow builds.

l Wants to adopt a headless/edge architecture but is trapped by "existing investments" and "migration costs."

l Heard of EDS but is unsure what problems it solves and what problems it does not solve.

We have extensively used AEM 6.x full-stack technology on multiple large enterprise sites. This article documents observations from practical experience: where the structural issues of the traditional model lie, and whether Adobe's Edge Delivery Services (EDS) is a viable solution.

(The picture illustrates the characteristics of the AEM target scenario.)

1. Traditional AEM development model: a precise yet sluggish clock.

1.1 The "fossil layer" of the technology stack.

The technology stack of AEM is a geological profile. At the bottom is JCR (Java Content Repository), a tree storage model designed in the XML era; above it is Apache Sling—essentially a URL router deeply rooted in the server-side rendering worldview; further up is OSGi, whose dynamic loading and configuration management brings endless class loader debugging; at the top is Granite UI / Coral UI—a component layer based on jQuery, which today, in an era dominated by React/Vue/Svelte, resembles a museum exhibit: creating a slightly complex editing dialog requires writing XML node definitions, with no type checking and no modern means of component reuse.

These technologies themselves are not without reason; the problem is that they are a closed ecosystem that does not evolve in sync with the outside world. While the front-end world manages dependencies with TypeScript + npm, AEM packages clientlib with Maven; while the back-end world uses Spring Boot or serverless, AEM is still registering services in OSGi; and while the deployment world uses Docker + K8s, AEM's deployment unit is the CRX Package—a ZIP file.

1.2 Cognitive Load of Dual Content Trees

The content architecture of real projects often evolves into a split: one tree for display pages and another for data/configuration pages, where display pages reference data pages at runtime through Sling Model and QueryBuilder. The separation of data and display has its rationale, but the cost is implicit coupling—the relationships do not exist in the type system and foreign key constraints, but only in the developer's mind and the query string. When data pages are renamed or deleted, display pages do not throw errors; they simply render a blank area quietly.

This is not a bug, but an inevitable cost of the architecture: JCR has no foreign keys, Sling has no compile-time checks, all associations are string paths, and all errors are deferred to runtime—adaptTo() failing to adapt results in null rather than a compile error, and a typo in the query path results in an empty result set rather than an exception.

1.3 The Layers of Fog in Frontend Engineering

The frontend engineering of modern AEM projects is a product of compromise: writing code with Webpack + TypeScript + SCSS, moving the compiled products to the clientlib directory, and then packaging and deploying with Maven, with friction created at every step.

There are two more fundamental issues:

First, manual mapping layers have replaced compile-time guarantees.Clientlib cannot use standard code splitting—it is a static tag included on the server side, so a webpack entry list and a clientlib output configuration must be manually maintained, along with matching style class names in the component strategy XML. Any error in this chain will not produce compile errors or runtime exceptions; it will simply result in a component's styles not loading. Too many mapping layers relying on human reconciliation have been inserted between the frontend and runtime.

Second, server-side rendering and frontend enhancement are disconnected.The main body of the page is generated by Sling/HTL on the server side, while interactive behaviors are processed by jQuery in the browser—there is no single source of truth for the "final form" of the same page. By default, all content is stuffed into the server-side HTML and then hidden using JS, leading to a serious inconsistency between server output and what users actually see; content dynamically injected via Ajax is also unfriendly to SEO and the first screen. Team members have to switch between two mental models simultaneously, and during debugging, they first need to determine "who rendered this piece of content."

2. Daily pains of development and deployment

2.1 Build: A pipeline designed for 2010

The build speed is a slow motion.A complete build for a medium-sized project may take five to ten minutes, even skipping tests. What’s more torturous is the feedback loop: change the code → build, package, deploy → wait a few minutes → F5 → no effect → check logs → find out the bundle hasn’t been updated → uninstall and reinstall → wait a few more minutes → finally see it. Frontend changes can theoretically bypass Maven for direct builds, but the output still needs to be manually synchronized into AEM. The root cause is that this is a full pipeline: the effectiveness of any single line change must go through the complete chain of compilation, packaging, and installation, with no increments and no reliability for hot replacement.

2.2 OSGi Bundle: The illusion of hot deployment

The biggest trap is the version number.Bundles with the same version number will not be automatically replaced. Code has been changed, deployed, and the logs show everything is normal—but the old code is still running. There are no errors: the bundle shows as Active, the logs have no exceptions, but the functionality is incorrect. Developers stare at the code to confirm the logic is correct, only to remember to check the actual version of the bundle—everyone in the team has been caught at least once.

Dependency resolution delayed failure.After bundle deployment, it may be in Installed rather than Active state, indicating unmet dependencies. This error is not reported during deployment and requires checking each imported package in the console—this is a search game in projects with dozens of bundles.

Sling Model's "silent failure".The initialization method of Sling Model is generally wrapped in try-catch and only logs errors; any runtime exceptions do not lead to HTTP 500, but instead the component renders as blank: status code 200, no frontend errors, and other parts of the page function normally. The only clue is the stack trace in error.log, and the log is huge, making it necessary to note the time point before performing a text search—this makes the judgment of "page normal" unreliable.

2.3 The gap between Author and Publish: caching is that unsolvable deadlock.

Content is edited in the Author instance and published to Publish through Replication—the architecture is theoretically clear, but practically full of gaps. The WCM model hides variables: Author runs in edit mode by default, and parameters are added during development to simulate the publishing environment, but the real environment also includes Dispatcher, CDN, and load balancing, and behaviors are not entirely equivalent. The Replication queue can get stuck: editors unknowingly click "publish" repeatedly, causing more and more requests to pile up in the queue.

But the real deadlock is the contradiction between caching and dynamic content. The value of the Dispatcher lies in full-page caching, but once there are dynamic components on the page that need real-time aggregation—such as a "related insights" list generated based on the current page context—the traditional approaches leave only two options: not caching the entire page, rendering from Publish each time, which is a performance disaster; or using Ajax for asynchronous loading on the frontend, causing first-screen flicker and being SEO unfriendly. The invalidation granularity is also a dilemma: too much invalidation leads to performance collapse, too little invalidation means content does not update, and the multi-level caching strategies from Dispatcher → CDN → browser are inconsistent at each layer. We have dealt with such cases: after a news release, Author is normal, and curl on Publish is also normal, but users still access the old version—CDN cache has not expired, and the troubleshooting spans three systems without a unified "cache status view".

We ultimately broke the deadlock using external means on the global website of an international law firm: Sling Dynamic Include (SDI) replaces dynamic components with ESI (Edge Side Includes) placeholders during the AEM rendering phase [4], and Cloudflare Worker resolves placeholders at the CDN edge, streaming and assembling real content—page bodies and dynamic fragments are independently cached and invalidated, with global TTFB stable at the millisecond level, and Publish load reduced to single-digit percentages. The complete implementation process of this solution is detailed in our article "AEM Dynamic Include combined with Cloudflare ESI: Building a Global Brand Site with Extreme Performance" [5].

But this is precisely where the problem lies: this contradiction is inherent in the AEM architecture, and the official has not provided an answer.SDI is only responsible for outputting placeholders, while the parsing, assembling, and cache coordination at the edge rely entirely on self-developed solutions; we need to add a layer of capability that AEM should inherently possess at the CDN level. When the core contradiction of a platform requires users to patch it outside the platform, it is time for the architecture of that platform to be re-examined.

3. The Essence of Obsolescence: Why Traditional Models Are Unsustainable

Cognitive dissonance in server-side rendering.The traditional model assumes that pages are assembled on the server, which was established in 2012, but today users expect sub-second first screens. Each request requires parsing the URL, loading the model, executing queries, and rendering templates, resulting in delays of several hundred milliseconds. After that, the browser still needs to load clientlib and jQuery. Dispatcher caching can compensate for delays but introduces consistency issues; dynamic content cannot be cached, and each request must go back to the source.

Deployment units are too coarse and non-reversible.The CRX Package mixes component definitions, template configurations, content pages, and static resources, making fine-grained incremental updates impossible; when redeploying a previous version, data generated between two deployments may be lost—completely disconnected from modern delivery concepts like blue-green deployment and canary releases.

Deep coupling in content management.Storage, rendering, editing, and distribution occur within the same system, requiring version consistency and synchronous upgrades. This is in stark contrast to the decoupling philosophy of Headless CMSs like Contentful and Sanity: content is JSON returned by an API, not HTML bound to a specific rendering pipeline.

(The picture illustrates the essence of backwardness.)

4. EDS: Adobe's Bet on Edge

4.1 What are Edge Delivery Services

Edge Delivery Services (EDS) is Adobe's next-generation content delivery architecture launched in 2023, with the core idea that content is rendered at the edge rather than on the server [2]. Its technology stack is almost completely different from traditional AEM [3]:

l Content Source: "Document as Content" sources such as Google Docs, Microsoft Word, SharePoint, and traditional AEM Author

l Build Pipeline: GitHub-based automated pipeline, changes trigger builds and deployments to CDN edge nodes

l Rendering: Pre-built static HTML + native JavaScript, no more Sling/HTL server-side rendering

l Frontend: Native ES Modules + lightweight enhancements, no build steps or packagers

l Deployment: CI/CD triggered by Git push, second-level deployment to global CDN, no more OSGi bundles

l Performance: The official goal is a perfect score on Lighthouse, and actual projects can usually stably achieve above 95 points

It is worth emphasizing: In section 2.3, we implemented "page body caching + dynamic fragment edge assembly" on the CDN edge with SDI + ESI, which is exactly the default architecture of EDS—static body at the edge, dynamic parts fetched on demand, without the need to develop any edge engine.

4.2 Document as Content: A Paradigm Shift in Editing Experience

The most revolutionary change in EDS is not the technical architecture, but the editing experience. The traditional Touch UI is feature-rich but has a steep learning curve; editors need to understand concepts like components, templates, strategies, Blueprint/Live Copy, etc., and publishing requires going through the Replication process. EDS's alternative is radical and direct: edit content using Google Docs or Word, and after saving, the pipeline automatically converts the document to HTML and deploys it to the CDN—going from editing to online can take as little as 30 seconds, with no Replication, no cache invalidation, and no Publish instances.

For editors, it means zero learning cost—they already know how to use Google Docs; for developers, it means no longer needing to write component dialogs or configure editing interfaces. "Documents as content" is suitable for content pages like articles and news, while complex interactive pages still require code development, but the development method has changed to standard web development.

4.3 Comparison of Development and Deployment Experience

Taking "adding a custom component for a new page type" as an example. The traditional AEM approach involves 4-5 modules, 7-8 files, 3 languages, and 2 build systems: component node structure, XML editing dialog, HTL template, optional Sling Model, front-end entry and clientlib configuration, component strategy—then build, deploy, test, check logs, and validate cache behavior, requiring 2-4 hours for an experienced developer. The EDS approach involves 1 directory, 2 files, and 0 build configurations: write a native JS file and a CSS file in the blocks/ directory, reference it in the content document using a table tag, and a Git push completes the deployment—30 minutes.

The gap in deployment experience is equally vast. Traditional deployment is measured in "minutes," with CRX Package being non-reversible and having an intermediate state of "bundle installed but not activated"; EDS deployment is git push, effective in seconds, and rollback is git revert, with no intermediate state of partial success. This comparison is brutal: the complexity of traditional AEM does not stem from business needs but from the framework itself—most of the time is spent not solving user problems but fighting with the infrastructure.

4.4 Generational Differences in Performance

Performance optimization in traditional AEM is a black magic: caching rules, JVM tuning, query optimization, clientlib compression, CDN strategies—each optimization is an independent configuration item and affects each other. Even so, the Lighthouse performance score of traditional AEM sites usually ranges from 30 to 60, with the first content rendering on the homepage potentially taking 2-4 seconds.

The performance advantage of EDS is architectural: content is pre-built static HTML, deployed at edge nodes, with TTFB being the CDN response time, usually within 50 milliseconds; without jQuery and clientlib, the JavaScript size can be controlled to below 50KB; achieving a Lighthouse score above 95 is the default behavior of the architecture, not a result of tuning.

5. A calm examination: EDS is not a silver bullet

EDS is suitable for content-driven sites: corporate websites, news portals, blogs, knowledge bases—where content is frequently updated, page structures are relatively fixed, interaction complexity is low, and performance requirements are high. However, before treating it as a "free upgrade" to AEM, one must acknowledge its boundaries and costs.

5.1 Functional Boundaries

l Complex personalized experiences.AEM's ContextHub and Target integration provides dynamic recommendations based on user profiles; EDS's static architecture has limited support for personalization, and while client-side API calls can be made, they sacrifice the performance advantages of edge rendering.

l Complex multi-site management.AEM's MSM and Blueprint/Live Copy manage multi-site content inheritance; EDS has no equivalent functionality, with each site being an independent repository.

l Complex forms and workflows.AEM Forms supports dynamic forms, workflows, and digital signatures, while EDS does not provide equivalent capabilities.

l Deep integration of the Adobe ecosystem.Enterprises that heavily rely on AEM Assets, Dynamic Media, and Marketo have the closest traditional AEM integration.

5.2 Migration costs: it's not an upgrade, it's a rebuild

The transition from traditional AEM to EDS is not an upgrade path, but a platform change:

l Content migration: JCR content needs to be exported as documents or JSON, preserving years of accumulated metadata, version history, and reference relationships is a project in itself.

l Template and logic rewriting: HTL templates are rewritten as native HTML + JavaScript, and the business logic of Sling Model is migrated to the client or Edge Functions, with no automatic conversion tools available.

l URL and SEO preservation: The URL structure, redirection rules, and continuity of search indexing need to be explicitly designed.

l Prerequisites: EDS is a component of AEM as a Cloud Service—enterprises still using AEM 6.x on-premise must first complete the migration or licensing to the cloud version, which is often an underestimated cost.

l Transitional dual-stack: Progressive migration means that for a period of time, two architectures operate in parallel, requiring maintenance of two sets of publishing processes and monitoring systems.

The migration costs are proportional to the site scale and depth of customization; for large, heavily customized sites, the migration expenses may be comparable to a platform change.

5.3 Maturity and Governance

EDS was officially launched in 2023, and community documentation, third-party components, and best practices are still rapidly evolving, lacking the depth accumulated by traditional AEM over the years. The governance model of "documents as content" also needs to be rebuilt: permissions, approvals, and metadata standards all need to be redesigned. Choosing EDS means accepting a certain degree of "early adopter" risk.

6. Outlook: Possibilities in the Post-AEM Era

For most enterprises, the most realistic path is a hybrid architecture: core marketing sites achieve optimal performance and editing experience with EDS, while complex application pages remain on traditional AEM—AEM as a Cloud Service has supported this combination, allowing enterprises to first migrate performance-sensitive pages and then gradually expand the scope.

The emergence of EDS is not isolated; it reflects the major trend in the CMS industry from monolithic to composable: enterprises are no longer seeking a CMS that does "everything," but rather choosing a replaceable best service combination. Traditional AEM finds itself in an awkward position: it does everything, but none of it is the best. The strategy of EDS is to simplify—cutting out server-side rendering, OSGi, HTL, and clientlib, retaining only the core content management and delivery capabilities.

The direction of technological evolution is driven by developer experience. The developer experience of traditional AEM has seen almost no improvement over the past decade—not because Adobe hasn't tried, but because the foundations like JCR, Sling, and OSGi cannot be modernized without starting over. EDS starts from scratch with the current technology stack—native JavaScript, Git workflows, edge rendering, and documents as content are not new concepts, but this is the first time they have been truly adopted by AEM.

FAQ

Q1: We are already using AEM 6.x, is it necessary to migrate to EDS?

Not necessarily. If the site primarily displays content, performance is a pain point, and editors are dissatisfied with Touch UI, EDS is worth evaluating; if there is a deep reliance on AEM Forms, Assets, MSM, or a large number of custom OSGi services, traditional AEM is still more pragmatic. Note that EDS requires an AEM as a Cloud Service license, and on-premise users need to factor in this cost.

Q2: What impact does EDS's "document as content" have on content governance?

The positive impact is zero learning cost for editing, publishing in seconds, and version control handled by Git. The challenges are that permission management, approval processes, and metadata standards need to be redesigned—enterprise-level workflows will rely on GitHub's PR mechanism or external tools for supplementation.

Q3: Can EDS support personalized content recommendations?

Limited support. Personalization requires client-side JavaScript to call APIs for dynamic injection, which sacrifices some performance advantages. Lightweight personalization can be handled; deep personalization is still stronger with traditional AEM + Target.

Q4: What is the biggest cost of migrating from traditional AEM to EDS?

Content migration and template rewriting. JCR content needs to be exported as documents or JSON, HTL templates and Sling Model logic need to be rewritten in native JavaScript; additionally, there are implicit costs of AEMaaCS pre-authorization and dual-stack operations during the transition period. It is recommended to migrate in phases, prioritizing high-traffic, low-interaction pages.

Q5: How is the dependency lock risk of EDS?

The core of EDS is standard web technology + Git + CDN, and the content source can also be the AEM Author itself, making the tech stack open. The main lock points are in the build pipeline and Adobe CDN, which has significantly reduced compared to the full-stack lock of traditional AEM.

Q6: What is the relationship between EDS and AEM as a Cloud Service?

EDS is a delivery layer option for AEM as a Cloud Service, not a replacement. Enterprises can use both traditional AEM (content backend) and EDS (edge delivery frontend) simultaneously, and this hybrid model is the progressive migration path officially recommended by Adobe.

Conclusion

In its time, AEM was an amazing product—it integrated content management, asset management, site management, and marketing management into one platform, and many businesses' digital presence still relies on AEM today. But times have changed: users expect sub-second responses, developers expect second-level deployments, and infrastructure has shifted to CDN edge, serverless, and Git workflows. The traditional AEM tech stack is a finely tuned mechanical watch, but in the era of smartwatches, it is no longer the preferred timing tool.

EDS is not perfect—there are limitations in applicability, insufficient maturity, and high migration costs. But it represents the right direction: bringing content back to content, bringing code back to code, and bringing delivery back to the edge. Our attitude is cautiously optimistic: cautious because it still needs to prove its capabilities in large-scale complex scenarios; optimistic because there is finally a way out of the JCR-Sling-OSGi quagmire. The twilight of AEM has arrived, and there is light on the horizon.

References

[1] MACH Alliance, 《MACH Principles》, https://machalliance.org/mach-principles

[2] Adobe, 《Edge Delivery Services Documentation》, https://www.aem.live/

[3] Adobe Experience League, 《Edge Delivery Services Overview》, https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/edge-delivery/overview.html

[4] W3C, 《ESI Language Specification 1.0》, https://www.w3.org/TR/esi-lang

[5] 龙孚信息（DBC）, 《AEM Dynamic Include 结合 Cloudflare ESI：构建极致性能的全球品牌站点》, https://www.dragonsoftbravo.com/cn/zh/insights/aem-dynamic-include-cloudflare-esi-performance.html