Adobe's been pushing Edge Delivery Services (EDS, formerly "Helix") hard, and it's a genuinely different architecture from traditional AEM Sites not just a performance patch. Here's what actually changes if you're evaluating it.

1. Authoring happens in Google Docs or Word/SharePoint, not the AEM UI

This is the biggest mental shift for teams. Content authors write in a Google Doc or Word document (via a connected Drive/SharePoint folder), and EDS converts that into structured markup automatically. There's no Touch UI page editor in the traditional sense the "CMS" experience is closer to writing a document than authoring components in dialogs. Teams with authors deeply trained on classic AEM component dialogs will need real change management here, not just a tooling swap.

2. Performance is the actual selling point, and it's measurable

EDS is built around aggressive Core Web Vitals targets out of the box pages are largely static, served from CDN edge, with minimal JS shipped by default. If your current AEM Sites implementation struggles with LCP/CLS scores because of heavy clientlibs and third-party scripts, EDS's default architecture forces a leaner build from day one rather than retrofitting performance fixes onto an existing heavy component library.

3. Component development model is fundamentally different from Sling Models/HTL

Instead of Sling Models + HTL + dialogs, EDS blocks are built with plain JavaScript/CSS following a block convention a <div> structure derived from document content, enhanced via a decorate() function per block. If your dev team has years of Sling Model muscle memory, this is a genuinely different skill set, closer to modern static-site/JAMstack development than classic AEM component development.

4. It's not a replacement for AEM Sites in every scenario

EDS shines for marketing/content-heavy sites where speed and simple authoring matter most landing pages, campaign sites, blogs, documentation sites. It's not (yet) the right fit for deeply personalized, component-rich experiences with complex authoring workflows, multi-level approval processes, or heavy integration with AEM Assets/DAM-driven personalization. Don't assume EDS replaces your existing complex AEM Sites implementation wholesale evaluate it per use case.

5. The authoring/dev disconnect can bite teams that skip governance

Because content lives in Google Docs/Word, there's a real risk of authors introducing unstructured formatting that doesn't map cleanly to blocks (nested tables, inconsistent heading levels, copy-pasted Word formatting artifacts). Without clear authoring guidelines and document templates, teams see inconsistent rendering that's harder to debug than a traditional AEM dialog-constrained authoring flow.

6. Governance and versioning move to your document platform, not AEM

Content history/versioning is now tied to Google Drive/SharePoint's native version history, not AEM's JCR versioning. If your organization has compliance requirements around content audit trails tied to AEM's version model, check whether your document platform's versioning satisfies the same requirements this is often overlooked until a compliance review surfaces it.

Bottom line: EDS is a legitimate architecture choice for speed-and-simplicity-first sites, not a universal upgrade path for every AEM implementation. The right question isn't "should we move to EDS" it's "which of our sites actually match the use case EDS was built for."

Has anyone shipped a real EDS site in production? Curious how the Google Docs authoring model actually landed with your content teams in practice.