While this has sparked numerous reactions across the AEM community, many enterprises currently on AEM 6.5 aren’t sure what it means or what their options are. Is now the time to upgrade, or do you have another choice?
In this article, I’ll explain what AEM 6.5 end of support means from a technical perspective, how it affects your business objectives if an upgrade wasn’t originally on your roadmap, and the options available to you going forward.
Key Takeaways
AEM 6.5's end-of-support deadline is a direct consequence of Java 8 and 11 reaching end-of-life. The platform won't stop working after support ends, but enterprises will be left to manage unpatched security vulnerabilities, compliance gaps, and growing integration limitations without Adobe's help.
Enterprises that want to remain in the Adobe ecosystem have two credible upgrade paths. AEM 6.5 LTS for teams that need infrastructure control, and AEM as a Cloud Service for those prioritizing long-term scalability.
The right choice depends on your compliance requirements, budget, and risk tolerance. Oshyn is an experienced Adobe partner that can offer migration support and help you evaluate the best option for your situation.
Why Is Adobe Deprecating AEM 6.5?
While this may seem like a purely Adobe-driven decision, it’s really a cascading effect caused by underlying platform dependencies.
AEM 6.5 runs on Java 8 and Java 11. Both versions reached the end of public support in 2023 and are now under extended support managed by Oracle. As these Java versions approach their own end of their life cycles, sustaining enterprise platforms built on them becomes more complex, costly, and risk-prone.
Because AEM 6.5 depends on these Java versions, Adobe’s support timeline is naturally aligned with Oracle’s roadmap. Consequently, the 2027/2028 end-of-support date reflects the broader lifecycle constraints of the ecosystem.
The Risks of Staying on AEM 6.5
Your existing AEM 6.5 will continue to run if you do nothing, but Adobe will no longer provide product support, security patches, or feature enhancements.
Running unsupported enterprise software exposes organizations to several critical issues, including:
Unpatched security vulnerabilities
Compliance and audit risks
Dependency and compatibility challenges
Limited integration with newer technologies
Innovation and competitive disadvantages
In enterprise environments, stability is not just about whether the system runs—it’s about whether it can be safely maintained, secured, and evolved over time. Staying on an unsupported version may appear stable in the short term, but it gradually increases operational and strategic risk. The next logical step is therefore to evaluate Adobe’s other offerings.
Options for Upgrading from AEM 6.5
When upgrading from AEM 6.5, you essentially have two main paths: staying on a modernized on-premises version or migrating to AEM as a Cloud Service (AEMaaCS). Each path comes with trade-offs in terms of architecture, features, and long-term strategy.
AEM 6.5 Long-Term Support (LTS)
AEM Long-Term Support is the latest on-premises version of Adobe Experience Manager. This means it runs on servers you manage—either in your own data center or through Adobe's managed hosting environment (AMS). Adobe released this updated on-prem version to provide organizations with a stable, supported option without requiring an immediate migration to the cloud.
AEM 6.5 LTS builds on the AEM 6.5.22 baseline and introduces upgraded core foundations, including Apache Felix, Sling, and Oak, as well as support for Java 17 and Java 21. This ensures the platform remains modern and compatible with the latest enterprise standards while keeping the familiar AEM user experience.
This release also removes legacy components and libraries, including AEM Communities, Guava, and Handlebars. See Adobe’s complete list of deprecated or removed features.
AEM as a Cloud Service (AEMaaCS)
The end-of-support announcement can also be seen as an opportunity to migrate to AEM as a Cloud Service (AEMaaCS) — Adobe’s cloud-native CMS. AEMaaCS receives continuous updates, scales automatically, and aligns with Adobe’s long-term roadmap, making it the strategic choice for organizations looking to modernize their digital experience platform.
Even within AEMaaCS, you have choices depending on how your site is built:
Traditional AEM: Uses HTL + Java, similar to classic on-prem architecture, providing a smoother transition for teams already familiar with AEM development.
Edge Delivery Service (EDS): A modern, front-end focused approach using plain JavaScript and CSS, optimized for speed, scalability, and cloud-native performance.
The graph below offers an opinionated reference on how these options generally compare in terms of effort and time required for migration:
AEM Upgrade Paths: Effort and Timeline Overview
Keep in mind, however, that the actual effort and timeline for your project will heavily depend on your specific business requirements, technical complexity, and organizational constraints. Each migration path should be carefully evaluated within your unique context.
Note: Adobe is actively developing AI-assisted capabilities to support EDS migrations, including the Modernization Agent. While EDS may initially seem challenging due to budget or time constraints, upcoming AI tools could significantly reduce the effort required for migration.Having the support of an Adobe partner like Oshyn can help you keep up with these advancements.
What to Consider When Choosing an AEM 6.5 Upgrade Path
Choosing the right AEM upgrade path is a strategic decision that goes beyond just technical feasibility. Here are key factors to consider:
Define Scope and Objectives: Clarify what you want to achieve with the upgrade, whether that means stability, scalability, access to new features, or preparing for future digital initiatives.
Assess Upgrade Complexity: Consider the technical effort required, including migrating content, templates, integrations, and any customization. More customizations increase planning, testing, and refactoring needs, affecting timeline, cost, and risk.
Budget and Business Constraints: Factor in both initial migration costs and ongoing operational expenses, including team readiness, infrastructure, and long-term sustainability.
Compliance and Regulatory Requirements: Industries such as finance, healthcare, and government have strict rules on data storage and handling, which can influence whether on-premises or cloud is the right choice.
Organizational Readiness and Skill Set: Ensure your team has the skills and processes to operate and maintain the new platform.
Risk Tolerance: Understand your organization’s appetite for risk. Some prioritize stability over innovation, while others are willing to take calculated risks for new features.
Wrapping Up
The end of support for AEM 6.5 is an opportunity to reassess your platform strategy. Whether you move to AEM 6.5 LTS or embrace AEM as a Cloud Service, the real goal isn’t just staying supported, but reducing risk, enabling innovation, and future-proofing your digital ecosystem. However, capitalizing on that opportunity requires a deep understanding of the AEM ecosystem.
Oshyn is an Adobe partner with experience handling migrations to AEMaaCS, integrating other products within the Adobe ecosystem, such as Target or Commerce, and providing DevOps and other maintenance support to help you maximize your AEM implementation.
We also offer decades of experience working with leading digital experience platforms such as Sitecore, Optimizely, and Contentstack if you believe that something outside the Adobe ecosystem might be a better fit. Regardless of what you need, our expertise can help guide your business in the right direction.
No, at least not in the foreseeable future. The need to upgrade AEM 6.5 was largely a side effect of Java’s lifecycle, not an intentional Adobe decision.
With AEM LTS, Adobe aims to provide stable, long-term support. The platform is built on Java 17 and Java 21, and at this point, Java 21 appears to be here to stay, with no clear end-of-support date in sight. While nothing in technology is guaranteed forever, AEM LTS should provide a solid and stable foundation for the next several years.
Once you’ve selected an upgrade path, the first practical and data-driven action you should take is to run the appropriate analysis tool:
- For AEMaaCS (non-EDS): use the Adobe Best Practices Analyzer (BPA)
- For AEM 6.5 LTS (on-premises): use the AEM Analyzer
These tools help you gain an early, realistic understanding of upgrade effort and complexity by assessing your current environment against patterns, requirements, and areas that need attention before you begin a full migration or upgrade. These assessments are best done in conjunction with an Adobe partner, but they can also help before reaching out to one.
For some organizations, staying on AEM on-premises gives them maximum control over their environment due to security, compliance, or data residency requirements, or for those whose risk appetite makes immediate cloud adoption challenging.
However, whenever possible, migrating to the cloud is generally the better long-term option as it ensures your organization stays competitive and prepared for upcoming digital challenges.