First published as a LinkedIn article on June 8, 2025. Rewritten for this site in October 2026. Client scenarios are illustrative: "it's possible to do this", not "we did this x times".
What changed since I wrote this
Two things moved. The first is authoring. In July 2025 Adobe added da.live, then in early access, as a third supported way to author Edge Delivery sites, which I covered in Making sense of the three EDS offerings. Document Authoring has since been renamed Experience Workspace, and Adobe's guide Where to author your site lists four options: Experience Workspace, Microsoft SharePoint, Google Drive, and Universal Editor in AEM Sites.
The second is code at the edge. Below I say EDS has no backend code. In 2026 Adobe made Edge Functions generally available: your own code running on Adobe's CDN in front of an Edge Delivery site, and I used them to add Google sign-in and members-only pages in AEM Edge Functions on a laptop. The pages are still static and cached. What's new is that you can choose to run code in front of them.
The rest is my June 2025 view, including the platform comparison, which I haven't re-checked against those products since.
Why the enterprise is ready for the edge
There's a clear shift in how enterprise content is delivered. Traditional CMS platforms, once deeply embedded in monolithic infrastructure, are being split apart. Systems are going modular. Authoring is becoming more distributed. The frontend is decoupled, the backend is lean, and publishing needs to be instant.
Many organizations feel this tension. Marketing teams need to move faster. Developers want to simplify their stacks. Authors want fewer tools to learn. Docs are intuitive; Google Docs or Word already feel like home. The idea that those surfaces can power live websites is no longer science fiction. It's architecture.
Adobe isn't entering an overcrowded space this time. It's bringing something new at the enterprise level. Edge Delivery Services brings static generation, content workflows and edge rendering together in one system, ready for enterprise scale.
How Adobe's CMS went from CQ5 to Edge Delivery
When Day entered the CMS space with CQ5, it wasn't first. But it was better. Authoring stood out, Dispatcher came bundled, and TarMK made deployment easier. Compared to Documentum and others, CQ offered a unified way to manage content that was both powerful and intuitive.
Then came AEM as a Cloud Service, a big step forward. Infrastructure became Adobe's responsibility, and clients stopped worrying about replication queues and JVM tuning. It moved AEM into the containerized world. Even so, many of the legacy assumptions stayed. Authoring was still tied to Sites. Deployment pipelines still needed DevOps overhead. Monoliths got smaller, but they didn't disappear.
CQ5 and on-premise AEM
Better, not first
- Authoring that stood out
- Dispatcher bundled
- TarMK made deployment easier
AEM as a Cloud Service
Infrastructure becomes Adobe's job
- Containers, no JVM tuning
- Authoring still tied to Sites
- Pipelines still need DevOps
Edge Delivery Services
A reimagining
- No backend code, no Dispatcher
- GitHub for templates and blocks
- Word or Google Docs for content
- Rendered at the edge
Edge Delivery Services is the next big leap. It's not an upgrade of AEM; it's a reimagining. Fully cloud native. No backend code, no runtime errors, no Dispatcher. Templates live in GitHub, content lives in Word or Google Docs, and the path to edge rendering is fast. AEM came later as a content repository, with the same concept.
In my view the model is foolproof by design. There's nothing to compile, and nothing to break and give you a 500. Business teams use Docs. Developers define templates and blocks. Pages get rendered at the edge, which means fast performance, easy collaboration and no cold starts.
Cloud platforms like Azure are more and more the invisible backbone of modern websites, and next to an edge-native delivery system like EDS they shine. They're more than hosting environments: they offer API orchestration, durable functions and serverless compute. These are the tools of a modern cloud engineer, and they complement Edge Delivery well.
And Adobe is betting early. I didn't see this as a trend-following move. I saw it as a market-breaking one.
How EDS compares with five other platforms
It's tempting to put EDS in the same category as static site generators or edge-hosted frameworks. On the surface the architecture looks familiar: static HTML, Git-based deployments, fast global delivery. That's where the similarities end.
Most developer-first platforms focus on building fast websites, and they assume developers do the authoring. Markdown, YAML and command line tools are fine for personal blogs or startups. Enterprise organizations need more: legal reviews, structured approvals, personalized content delivery, and preview links that don't require standing up a preview server.
That's where I think EDS shines. It isn't cobbled together from third-party services or custom glue code. Authoring, previewing, publishing and personalization come as one, with edge performance, and it meets legal and compliance needs without giving up speed. Here's how I compared it with five popular options in June 2025, on the same five capabilities.
Pick a capability below to line up all six platforms on that one row. Authoring and enterprise workflows are where they split most: the other five assume a developer does the authoring, or leave approvals to custom work.
| Platform | Authoring surface | Preview support | Personalization | Enterprise workflows | Edge support |
|---|---|---|---|---|---|
| Adobe EDS | Google Docs or Word | Live with Universal Editor, or preview on aem.live | Can be integrated manually with AEP and Adobe Target | Native review, approval and legal compatibility with Universal Editor and Sites | First-class, deeply integrated |
| Cloudflare Pages | Markdown | Manual or CLI-based | Not natively supported | Requires custom implementation | Excellent, but developer-driven |
| Netlify + composable CMS (for example Sanity) | CMS UI + Markdown | Possible with configuration | Varies with the CMS integration | Partial, often pieced together | Strong, but fragmented |
| Next.js static generation | Developer-built, or a headless CMS | Available, but takes effort | Possible with middleware or APIs | Not native, needs architecture | Optimized with the Next.js Edge Runtime |
| Hugo | Markdown, Word with extensions | Local preview with the CLI | Not built in | Manual. The Word-to-Hugo workflow exists, but it's fragile | Requires configuration, not native |
| Jekyll | Markdown | Local only | Not supported | Minimal | Limited without a custom CDN setup |
The Hugo row is from experience. I built jackconsults.com with Hugo and explored pipelines that turn Word documents into Hugo pages. The workflow exists, but it's fragile.
The bigger difference is in what these platforms prioritize. Most developer-first tools treat authoring as an afterthought. They optimize for builds, not for business enablement. EDS flips that. It starts with authors, not code. It supports the preview cycle, not just the publish. And it supports teams beyond marketing: legal, governance, campaign managers. Everyone gets a seat at the table.
My conclusion in June 2025: EDS is complete, from authoring to publishing and from compliance to performance. To me it was the first enterprise-ready edge CMS.
Where EDS could go, and what it still lacked in June 2025
Adobe's move with EDS is bold. Unlike the early days of CQ, there's no crowd to stand out from. This is new territory, and Adobe is leading it.
EDS is more than a shift in technology. It reshapes how teams think and operate. Business users keep working in tools they already know and trust, like Word or Google Docs. Developers define templates and step aside, so authors can publish confidently and independently.
The backend doesn't slow things down. There's no complex infrastructure to debug or deploy, and pages render fast and reliably from the edge. Frontend teams are still critical: they build the templates and the scaffolding. Once that's done, business teams can preview and publish on their own, without waiting.
My notes from that week also had a wishlist. For business teams to run campaigns without developers, Edge Delivery needed more parity with Sites: content fragments, variations, and easy authoring for personalization. And since marketing briefs already live in documents, maybe EDS just needs a better default template to deliver them.
This is the kind of architecture shift that changes more than platforms. It changes how teams work. In June 2025 I was doubling down on Adobe's bet on EDS, and I liked my odds.