AEM 6.5 End of Support Dates per hosting model, the three paths afterwards and how target values secure the migration
The support periods for Adobe Experience Manager 6.5 are running out. For many platforms in the DACH region, this means a migration is due, and every migration shifts load time, input responsiveness and layout stability. This page summarizes the dates according to Adobe, assesses the three paths after AEM 6.5 from a performance perspective and describes how target values set before the first sprint prevent the new platform from becoming slower than the old one.
Dates according to Adobe, as of 1 November 2026Adobe's current information is binding
AEM 6.5 end of support: the dates per hosting model
| Hosting model | Date | Source |
|---|---|---|
| Adobe Managed Services | Support ended on 31 August 2026 | Adobe release roadmap |
| On-premises, core support | End planned for February 2027 | Adobe release roadmap |
| On-premises, extended support | Until February 2028, terms via Adobe | Adobe knowledge base |
After the end of support, Adobe no longer provides service packs and security updates for the affected version as part of regular support. For operators, this means the decision on the way forward is being made now, and with it the decision whether performance is part of the requirements or only becomes noticeable after go-live.
Three paths after AEM 6.5: 6.5 LTS, Cloud Service or Edge Delivery Services
AEM 6.5 LTS: same architecture, same performance debt
Adobe continues AEM 6.5 as a long-term support version. The architecture with publish instances, Dispatcher and client libraries remains, and with it all existing causes of slow pages. This path buys time but improves no metric unless the cache, the bundles and the third parties are worked on at the same time.
AEM as a Cloud Service: delivery from the service, browser unchanged
In the Cloud Service, the CDN, scaling and updates are part of the service, and deployments run through the Cloud Manager pipeline. This improves the starting position for server response time. What happens in the browser moves over unchanged: client libraries, tags, consent and personalization. A platform that delivers the same bundles after the migration achieves the same input responsiveness and layout stability values as before.
Edge Delivery Services: new delivery, new frontend
Edge Delivery Services replaces the classic delivery and requires a newly built frontend. The architecture is leaner, but the good starting position in the lab holds in production only if the tag manager, consent banner and personalization are not carried over unchanged. In the AEM Core Web Vitals Benchmark 2026, 54.0 percent of websites on Edge Delivery Services pass the Core Web Vitals, compared with 49.4 percent for the classic delivery.
Baseline before the migration: what to measure on the 6.5 platform
- Field data per page type and market from the Chrome User Experience Report (CrUX), split by mobile and desktop, as the baseline for sign-off.
- Cache hit ratio of the Dispatcher cache and response time of the publish instances per page type.
- Size of the client libraries per page type and the share of it that runs before the first interaction.
- An inventory of all third-party scripts with owner and blocking time.
- The renditions of the images in the visible area and their size on mobile devices.
A direct check of the websites shows that 140 of 486 detected AEM websites in the DACH region still deliver via the paths of the generations up to 6.3. For these platforms, the baseline is especially important, because the migration there is also a change of generation.
Performance sign-off in the migration: target values before the first sprint
The target values per page type belong in the requirements specification of the migration before the first component is built. The measured baseline is the lower limit: no page type may be slower after the migration than before. Above that are the target values for Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. Each migrated area is signed off individually against real-user data, so that a deterioration can be attributed to an area instead of surfacing as a single number only after the full go-live.
The wording for this is in the AEM Performance Requirements Template. How implementation partners and independent sign-off work together is described under Performance Partner for AEM Agencies. The technical causes on AEM platforms are explained under Adobe Experience Manager Performance.
Book a free performance analysis
30 minutes by video. You receive Google's real-user data for your platform compared with two competitors, whether or not a collaboration follows.
Frequently asked questions about the AEM 6.5 end of support
When does support for AEM 6.5 end?
According to Adobe's release roadmap, support for AEM 6.5 on Adobe Managed Services ended on 31 August 2026. For on-premises installations, the end of core support is planned for February 2027, and according to the Adobe knowledge base, extended support is available until February 2028. Adobe's current information is binding.
Does an AEM platform become faster by moving to the Cloud Service?
In delivery, usually yes, because a CDN and an up-to-date cache layer are part of the service. In the Core Web Vitals, not automatically, because input responsiveness and layout stability mostly arise in the browser. Without target values and work on client libraries, tags and personalization, these values stay the same after the migration.
When should performance measurement start in a migration?
Before the migration. Without a baseline per page type, it is impossible after go-live to prove whether the new platform is faster or to attribute a deterioration to a migrated area.