AEM 6.5 End of Life: LTS vs Cloud Service, and How Long You Actually Have

AEM 6.5 has a published end date, and for most organisations it has already passed or is weeks away. This page gives the dates, the three destinations, and the arithmetic that tells you which one is still available to you.

The dates

Deployment	Support ends
AEM 6.5 on Adobe Managed Services	31 August 2026
AEM 6.5 on-premises, core support	February 2027
Service Pack 6.5.26.0 — the last supported service pack for AEM 6.5	28 February 2027
AEM 6.5 LTS	Continuing branch; Adobe's documented support runs to 28 February 2027, with LTS receiving ongoing updates thereafter

Source: Adobe's Experience Manager releases roadmap and the AEM 6.5 LTS FAQ. Verified 15 September 2026.

Each service pack is supported for up to 18 months from release. 6.5.26.0 is the last one, which is what makes February 2027 a hard floor rather than a soft one.

Working backwards

An enterprise AEM migration runs six to twelve months from kickoff to cutover, and that assumes the assessment is already done and the budget already approved. Count backwards:

• To be off 6.5 by February 2027, a twelve-month programme needed to start in February 2026. A six-month programme needs to start now, in September 2026, with no slippage, no procurement delay and no discovery surprises.
• If you are on Adobe Managed Services, the 31 August 2026 date has passed. You are running unsupported today.

If that arithmetic does not work — and for most organisations reading this in late 2026 it does not — AEM 6.5 LTS is not a failure, it is the correct answer. The mistake is drifting into it by default in February rather than choosing it deliberately now.

The three destinations

AEM 6.5 LTS

The long-term support branch. Keeps your existing infrastructure, your existing team, and your existing operational model. Adds support for Oracle Java 17 and Java 21.

Choose it when: the migration window has closed, your customisation is deep, your team has no cloud platform engineering capability yet, or you have a larger platform decision pending and need to buy eighteen months.

Understand before you choose it:

• Some legacy features and artifacts have been removed in LTS. Adobe provides the AEM Analyzer tool to assess what that does to your customisations — run it before committing, not after.
• LTS is not Cloud Service with a longer runway. It is a separate branch. The Cloud Service feature line, including Adobe's AI capabilities, is not coming to it. Choosing LTS is choosing to sit out that roadmap for the duration.
• You still own the servers, the patching, the JVM, the Dispatcher farm and the upgrade project at the end of it.

Cost shape: lowest immediate spend, unchanged run rate, and a deferred migration that will cost more later than it does now, because the gap between your codebase and the cloud target widens every year.

AEM as a Cloud Service

Fully managed, continuously updated, and the platform Adobe is actually developing.

Choose it when: you have the window, the budget and the appetite to change how your team works — because this is a change in operating model, not a hosting change.

Understand before you choose it:

• No SSH, no root, no shell. Debugging becomes log-driven and pipeline-driven.
• /apps and /libs are immutable at runtime. Any code that wrote there has to be redesigned.
• Cloud Manager is the only deployment path, and its quality gates will block releases. A Security Rating below B fails the pipeline outright.
• Adobe ships updates on Adobe's schedule. Your custom code has to survive them, which changes the economics of writing custom code at all.
• Migration stalls on custom OSGi bundles and third-party integrations far more often than on content.

Cost shape: a six-to-twelve-month implementation programme, then a predictable operating cost. Not a savings exercise — see what AEM actually costs.

AEM as a Cloud Service with Edge Delivery Services

Cloud Service plus a replacement for the Publish and Dispatcher tier: an Adobe-managed CDN, GitHub-based deployment, plain HTML and vanilla JavaScript, and either document-based authoring or the Universal Editor.

Choose it when: site performance is a business problem, your content operation would genuinely rather work in Word or Google Docs than in an authoring UI, or your front end is due a rebuild anyway.

Understand before you choose it: it is a front-end rebuild on top of a migration, not a switch you flip. EDS and AEM Sites can coexist on one domain and consume each other's content, so it can be adopted progressively — which is usually the sane route. Detail on the Edge Delivery Services page.

Side by side

	AEM 6.5 LTS	AEM as a Cloud Service	Cloud Service + EDS
Time to complete	Weeks to months	6–12 months	6–12 months plus front-end rebuild
Infrastructure you own	All of it	None	None
Upgrade model	Periodic projects	Continuous, Adobe-scheduled	Continuous, Adobe-scheduled
Deployment path	Yours	Cloud Manager only	Cloud Manager + GitHub
Shell access	Yes	No	No
Adobe's AI feature line	No	Yes	Yes
Performance ceiling	Your Dispatcher and CDN	Adobe CDN	100 Lighthouse as design target
Immediate cost	Lowest	Highest	Highest
Deferred risk	Highest	Lowest	Lowest

What to do in the next thirty days

Whichever destination you are heading for, the first step is the same and it is small.

1. Run the AEM Analyzer / Best Practices Analyzer against your production instance. It will tell you what your customisations do on each target, and it costs you an afternoon.
2. Inventory your custom OSGi bundles and third-party integrations. This is the list that determines the real timeline, not content volume.
3. Check your own support status. If you are on Adobe Managed Services, confirm what your contract says today, because the platform date has passed.
4. Decide deliberately. Pick LTS or pick Cloud Service. Do not arrive at February 2027 having picked neither.

We run this as a fixed-scope two-to-four-week readiness assessment that produces a written recommendation with the evidence behind it — including the recommendation to stay on LTS, where that is the right call. See Adobe Experience Manager services or request a quote.

Common questions

When exactly does AEM 6.5 support end?

Adobe Managed Services support ended 31 August 2026. On-premises core support ends in February 2027, with the final service pack (6.5.26.0) supported until 28 February 2027.

Is AEM 6.5 LTS the same as extended support?

No. LTS is a separate, continuing release branch that receives ongoing updates, Java 17 and Java 21 support, and has had some legacy features and artifacts removed. It is a version you upgrade to, not a support contract you buy.

What happens if we do nothing?

You run an unsupported platform: no security patches, no service packs, no Adobe support for incidents, and a compliance problem the first time an auditor asks. For regulated industries that is usually the argument that releases the budget.

Can we go to LTS now and Cloud Service later?

Yes, and for organisations that have run out of runway it is the pragmatic sequence. Be aware that the LTS upgrade work does not carry forward into the cloud migration — repository restructuring, immutability fixes and integration rework all still wait for you. You are buying time, not progress.

How long does a migration to AEM as a Cloud Service actually take?

Six to twelve months for an enterprise estate. Faster is possible for a single site with modest customisation. The variables that decide it are custom code volume, integration count and content volume, in that order.

Does staying on 6.5 LTS block Adobe's AI features?

Yes. Adobe's AI capabilities are on the Cloud Service line. This is a platform architecture boundary, not a temporary feature gap, and it is the point most worth raising with stakeholders who see the decision as purely infrastructural.

---

Related reading: Adobe Experience Manager services · What AEM costs in 2026 · AEM as a Cloud Service migration · Edge Delivery Services