What changed for AEM 6.5 LTS, AEM as a Cloud Service and Edge Delivery Services, and how should those changes influence architectural decisions?

In October 2025, I published Navigate AEM Flavors in 2025, covering the different ways organizations could run and deliver Adobe Experience Manager experiences.

The article focused on the available options, how AEM evolved into a cloud-native platform, and the trade-offs between traditional AEM implementations, Cloud Service and Edge Delivery Services.

A year later, the main options are still familiar, but each has changed in ways that affect how we approach new projects and existing implementations.

AEM 6.5 has a clear transition toward LTS (read more in CX Enterprise Atlas). AEM as a Cloud Service is becoming more flexible in how experiences are delivered, and Edge Delivery Services has expanded beyond its original positioning around lightweight, high-performance websites.

Main question for AEM implementations in 2026 is which combination makes sense for our requirements, and how do we get there?

From the journey to the cloud to choosing the right architecture

In the 2025 article, I covered AEM's evolution from Day Software and CQ through the architectural changes that made AEM as a Cloud Service possible.

The separation of application and content, containerization, federated services and the introduction of a control plane eventually led to the launch of AEM as a Cloud Service in 2020.

That evolution is still relevant, but in 2026 the more interesting changes are happening at the delivery and integration layers. Content authoring, content delivery and application runtime no longer have to follow the same architecture.

Organizations can use AEM for authoring while delivering content through Edge Delivery Services. Existing AEM Publish applications can coexist with EDS, and backend services can continue owning business logic and transactional state.

This gives us more flexibility, but also requires more deliberate architecture decisions.

Modern AEM platform options in 2026

The 2025 comparison showed four deployment and delivery options: AEM 6.5 on-premise, AEM 6.5 on Adobe Managed Services, AEM as a Cloud Service, and Edge Delivery Services.

For 2026, I would organize the comparison around three main architectural choices:

1. AEM 6.5 LTS: The continued support path for traditional, highly customized AEM implementations.
2. AEM as a Cloud Service: Adobe-managed operations with the established AEM Java runtime, headless capabilities and multiple delivery options.
3. Edge Delivery Services: CDN-first content delivery with flexible authoring and an expanding set of edge capabilities.

These are not three completely independent platforms. EDS is a delivery approach that can be combined with AEM as a Cloud Service authoring, rather than a separate replacement for the entire AEM platform.

AEM 6.5 LTS: Continued support for traditional AEM architectures

In 2025, the main reasons to choose AEM 6.5 were infrastructure control, extensive customization, mature DevOps practices, complex integrations and specific compliance requirements. Those reasons have not disappeared.

For organizations running large AEM implementations with custom Sling Models, OSGi services, workflows and integrations, retaining the traditional architecture is mostly the most practical decision. Main change during 2026 is the support timeline.

Support for the existing AEM 6.5 release on Adobe Managed Services ended on August 31, 2026, and core support for on-premise installations is currently planned to end on February 28, 2027.

Adobe has also identified AEM 6.5.26, currently targeted for November 19, 2026, as the final supported regular service pack. The continued support path is AEM 6.5 LTS.

LTS introduces updated platform dependencies, support for Java 17 and Java 21, and a continuing service pack schedule. SP3 was released in August 2026, with additional service packs planned throughout 2027.

Each LTS service pack is supported for up to 18 months, making regular upgrades part of the long-term maintenance model.

When would I choose AEM 6.5 LTS?

I would still consider LTS for organizations that need:

• Infrastructure control and specific deployment requirements.
• Extensive Java and OSGi customization that would be expensive to redesign.
• Complex integrations with existing enterprise systems.
• Compliance, operational or data-residency requirements that make the current hosting model preferable.
• A stable modernization path without immediately rebuilding the platform.

Moving from AEM 6.5 to LTS is generally less disruptive than migrating to Cloud Service, but it still requires assessment of compatibility, removed legacy functionality and custom dependencies.

The difference from 2025 is that continuing with the traditional architecture now requires a clear LTS upgrade and support strategy. It should be a planned upgrade rather than just extension of the existing AEM 6.5 implementation.

AEM as a Cloud Service: Managed operations with more delivery options

AEM as a Cloud Service remains Adobe's cloud-native platform for organizations looking to reduce infrastructure management while retaining the capabilities of AEM.

The main advantages described in 2025 are still valid: managed operations, autoscaling, continuous updates, integrated deployment pipelines and support for traditional and headless content delivery.

Teams can continue using the classic Author, Publish and Dispatcher architecture, including Java, HTL, Sling Models, OSGi services and Content Fragments.

For existing AEM applications, this remains a relevant architecture, especially when the implementation depends heavily on the AEM runtime. Biggest changed in 2026 is the flexibility around the runtime.

The Publish tier is becoming optional

With Cloud Manager 2026.10.0, Adobe introduced a beta capability allowing programs to be configured without a traditional Publish tier.

This applies to suitable Edge Delivery Services implementations using AEM authoring.

For those projects, AEM can remain the content management platform while EDS handles content delivery. That removes an entire runtime tier from the implementation, reducing configuration and operational overhead.

It also changes a common architectural assumption: using AEM for content authoring does not necessarily mean using AEM Publish for content delivery.

Runtime and deployment improvements

Cloud Service also received several improvements affecting development and operations.

Canary deployments are now generally available, allowing teams to validate a release against selected production traffic before making it available to all visitors.

Java 25 is the next runtime transition. The Cloud Service SDK already supports Java 25 for local development, optional enablement in Cloud environments is targeted for November 2026, and Adobe currently plans to complete the runtime migration across environments by May 2027.

For teams maintaining custom Java applications, dependency and deprecated API reviews should already be part of the preparation.

Cloud Service also continues expanding its AI-assisted tooling. The unified AEM MCP Server provides access to content, governance, Cloud Manager and migration capabilities through supported AI clients, while CX Enterprise Coworker introduces additional agentic workflows.

These are useful additions for development and operations, although I would not choose a hosting model based on AI capabilities alone.

When would I choose AEM as a Cloud Service?

Cloud Service remains a strong option for organizations that want managed operations while retaining the traditional AEM application model.

It also fits headless implementations using Content Fragments and APIs, as well as migrations where substantial existing Java functionality needs to be preserved.

The main change is that I would no longer automatically assume every new Cloud Service Sites implementation needs the traditional Publish and Dispatcher delivery model.

That is now an architectural decision worth evaluating separately.

Edge Delivery Services: Beyond lightweight content delivery

In the 2025 comparison, Edge Delivery Services was positioned around performance, simplicity, content velocity and document-based authoring.

These remain important benefits, but the platform has expanded. Adobe now recommends Edge Delivery Services as the starting point for new AEM Sites projects, while continuing to support traditional and headless delivery approaches.

For new content-led websites, this means EDS should generally be evaluated first, with the architecture shaped by requirements that cannot be met through the edge delivery model.

More flexibility in content authoring

EDS no longer needs to be associated primarily with authors working in Word or Google Docs.

Teams can use document-based authoring or AEM authoring with Universal Editor, depending on their content management and governance requirements.

This gives organizations more flexibility in choosing how content is managed without tying the authoring experience to the delivery runtime. For existing AEM teams, that can make adoption easier because EDS does not necessarily require abandoning established content management practices.

Edge Functions and authentication

EDS has also gained more options for request-time behavior.

AEM Edge Functions support focused JavaScript execution at the CDN layer, including lightweight personalization, routing, API aggregation, response transformation and server-side HTML composition.

Edge Authentication, currently in beta, supports OpenID Connect-based authentication for suitable gated content experiences.

These additions expand the use cases for EDS, but they do not make it a replacement for a full application backend.

An Edge Function calling a remote API still depends on that API's response time. Likewise, authentication at the edge does not mean user state, entitlements or transactions should be owned there.

Edge compute and edge-local data are separate architectural concerns. Data locality, caching, state and backend dependencies still need to be considered.

Hybrid delivery and gradual modernization

Main advantage is that EDS does not require replacing an entire existing website at once. AEM Publish and EDS can coexist behind the same domain.

For example, an organization could use EDS for campaign pages, editorial content and product information while retaining AEM Publish or a dedicated application runtime for complex authenticated experiences.

This makes it possible to modernize route by route, reducing migration risk and allowing teams to validate the new delivery approach before expanding it.

When would I choose Edge Delivery Services?

I would start with EDS for most new marketing websites, campaigns, editorial sites and other content-led experiences where performance and content velocity are primary requirements. I would also consider it for suitable sections of existing enterprise platforms.

For applications with complex transactional state, deep Java dependencies or significant server-side business logic, AEM Publish or dedicated backend services may remain a better fit.

The goal is not to move everything to the edge. It is to put each responsibility in the right place.

Key considerations: Which AEM architecture is right for your organization?

The comparison criteria from 2025 are still useful. Control, operational overhead, authoring and delivery performance remain the main areas to evaluate.

For 2026, I would add runtime dependencies, support and modernization strategy.

TL;DR

Need maximum control and extensive customization? AEM 6.5 LTS remains a valid option, provided there is a clear support and upgrade strategy.

Need managed operations with the existing Java stack or headless delivery? AEM as a Cloud Service is the natural choice.

Building a new content-led website where performance and authoring velocity matter? Start with EDS and choose the authoring model that fits the organization.

These should be starting points, not rules that apply to every implementation.

Licensing

Licensing is another area that should remain part of the comparison. AEM 6.5 LTS continues to offer perpetual and term-based licensing options, while Cloud Service agreements and EDS entitlements follow different commercial and usage models depending on the products and services purchased.

The exact commercial model needs to be confirmed against the organization's Adobe agreement. As I mentioned in the 2025 article, licensing costs alone do not tell the full story.

Infrastructure operations, development approach, traffic, platform usage and maintenance can significantly influence the total cost of ownership.

A migration to a managed platform may reduce infrastructure responsibilities, but it can also require substantial redevelopment of existing features.

Final thoughts: From choosing a flavor to choosing an architecture

The 2025 comparison focused on choosing between traditional AEM, Cloud Service and Edge Delivery Services.

In 2026, those options have become more flexible, and organizations increasingly need to consider how they can work together. For an existing AEM 6.5 implementation, the next step might be upgrading to AEM 6.5 LTS while preparing for a longer-term migration. Another organization might move directly to AEM as a Cloud Service, keeping the existing Java runtime while reducing operational overhead.

For new content-led experiences, EDS may be the right delivery layer from the beginning. Existing platforms can also introduce it gradually, moving suitable routes without rebuilding everything at once.

I would start with five questions:

1. Which existing features genuinely depend on the AEM Java runtime?
2. Which parts of the website are content-led, and which behave more like applications?
3. Where does the data live, and how much state does the experience require?
4. Which routes can be modernized independently?
5. What operational complexity would the new architecture actually remove?

The answers are more useful than choosing a platform based only on feature lists.

AEM 6.5 LTS continues supporting organizations with specific infrastructure and customization requirements. AEM as a Cloud Service provides managed operations and the established AEM runtime. EDS is becoming the starting point for new content-led Sites implementations and an additional delivery option for existing platforms.

It was never about which flavor is better. Just try to answer which combination solves the requirements with the least unnecessary complexity, and how to get there without disrupting what already works.

At Cyber64, we help organizations evaluate AEM architectures, plan migrations and modernize existing implementations. Feel free to reach out if you are reviewing your AEM roadmap.