The Real 3-Year Cost of AEM: Edge Delivery with Document Authoring vs. Cloud Service
If you ask anyone who runs a traditional AEM as a Cloud Service program what it actually costs to operate year over year, the license is rarely the number that stings. The real cost lives in everything around it: the specialized developers, the pipeline waits, the dispatcher tuning, and the steady backlog of small component changes that each somehow take a sprint. This piece sets aside the initial build entirely and asks a narrower question: once a site exists on each platform, which one costs more to keep running and extend over the next three years? Compared honestly on that basis, AEM Edge Delivery Services with Document Authoring comes out ahead not because the license is cheaper, but because almost everything surrounding it costs less.
Calculate!
Authoring: Document Authoring uses a document-based interface, so authors work in an environment they already understand. There are no component dialogs to learn and no template constraints to work around, which means ramp-up is measured in hours rather than weeks. With the new Experience Workspace, authors also get a proper WYSIWYG editing experience, along with an integrated AI assistant and real-time collaboration, and none of it requires developers to build dialogs first. In classic AEM, a good visual editing experience is something the development team constructs one component at a time. In EDS with DA, it comes with the platform.
This has a knock-on effect on content operations that's easy to underestimate. In a traditional AEM shop, content teams generate a continuous stream of small development requests: a new field in a dialog, a variation of an existing component. Individually they're minor; collectively they're a permanent tax on the roadmap. With document-based authoring, content teams handle most of these themselves, and the changes that still need a developer are far simpler. In our model that works out to roughly half the cost per change, and for organizations with high content velocity, content operations turns out to be the single largest line of savings.
Development: EDS development uses plain web technologies (HTML, CSS, and JavaScript), so there are no dialogs to build, no Sling Models to wire up, and no proprietary backend APIs to learn and maintain. A block in EDS takes a fraction of the effort of an equivalent AEM component once you account for all the plumbing the AEM version requires.
Over three years this compounds in ways that matter more than any single line item. You can hire from the general population of web developers rather than competing for scarce AEM specialists, and new team members are productive in days instead of months. Deployment is Git-based and takes seconds, where Cloud Manager pipelines routinely run 45 to 90 minutes. Spread that idle time across every release, hotfix, and developer over three years and it becomes a significant cost that never appears on an invoice. Less custom backend code also means a smaller regression surface, so QA effort shrinks along with it.
Performance: Strong Lighthouse scores are the default on EDS rather than the result of an optimization project. Delivery runs on globally distributed, push-invalidated infrastructure that Adobe operates. Achieving the same outcome on Cloud Service takes dispatcher tuning, CDN configuration, and ongoing front-end optimization work, all of it billable and none of it one-time. Performance also cuts the other way in a TCO model: faster pages rank better and convert better, so the gap is wider than the cost side alone suggests.
SEO, accessibility, and GEO: The boilerplate ships with semantic markup, excellent Core Web Vitals, and accessibility-friendly patterns, so search visibility and a11y compliance are a starting point rather than remediation projects. There's also a newer consideration. EDS content is markdown-native and cleanly structured, which makes it unusually legible to AI crawlers. As generative engines mediate more discovery, that positioning comes at no additional cost.
Composability: Delivery is decoupled from content management and served from resilient, distributed infrastructure. There's no publish farm to size, no dispatcher to configure, and no single origin to worry about during a traffic spike. The composable model also lets you integrate the services that fit your needs rather than bending every requirement into one platform, which is useful insurance against the most expensive event in any TCO analysis: a forced replatform.
Existing AEM investment: Choosing EDS doesn't mean walking away from AEM. Existing instances and legacy business logic can keep running in the backend, exposed headlessly, while EDS handles the experience layer. You protect what you've already built while reducing spend on the parts of the stack that cost the most to operate. Migration can happen incrementally, page by page, rather than as a risky big-bang cutover.
To be fair: EDS with DA typically sits under the same AEM Sites license, so this isn't an argument for canceling the Adobe contract. The argument is that the same license delivers considerably more with considerably less effort around it. You'll also hear that EDS can't handle deeply transactional sites, and it's worth addressing that directly, because it isn't true. EDS doesn't eliminate complex business logic; it moves it to a service layer where it belongs, behind clean APIs, independently deployable and independently scalable. That's not a limitation, it's the architecture the rest of the industry already converged on. The objection tends to come from teams invested in the old model, not from anything the platform can't do.
Putting numbers on it: To make this concrete, we modeled the ongoing cost of running and extending an already-implemented site across five categories: build, deployment overhead, content operations, infrastructure and ops, and QA. Implementation and migration costs are excluded by design; the question here is simply which platform costs more to operate for the next three years. We tuned the inputs to be conservative, and where we weren't sure, we leaned against our own conclusion: three dev-days per AEM component rather than five, a 20 percent specialist rate premium, content changes on EDS costed at 0.3 dev-days rather than near zero, and an AEM ops allocation of less than a third of an engineer. Even so, the three-year running cost comes out roughly 60 percent lower for EDS with DA, about $1.26 million on a mid-sized program, along with more than 600 developer-days returned to the roadmap. The model is a simple set of formulas with every assumption exposed, and the interactive calculator lets you adjust any input and share a link to your exact scenario. Skeptics are welcome to plug in their own numbers. The conclusion survives pessimistic inputs.
None of that changes the overall picture. Over three years, the difference shows up everywhere the invoice doesn't: features shipped in days rather than sprints, developers hired from the open market, deployments in seconds rather than pipeline-hours, performance and visibility as defaults rather than projects, and a content team that ships without filing tickets. The harder question at this point isn't whether EDS with DA has a better TCO. It's what justifies paying the old costs for another three years.