AEM 6.5 end of support: Cloud Service or open source

What AEM 6.5 end of core support means for your migration window

Your constraint is a vendor support deadline, not a technical limit. Core support for on-premise AEM 6.5 ends on February 28, 2027, and extended support, which covers critical fixes only, ends on February 28, 2028. The real choice is between staying on a supported AEM path, moving to AEM as a Cloud Service, or replacing the CMS with a self-hosted open-source platform. Each option has a different timeline, so the decision should be made before the calendar forces it.

Adobe offers AEM Sites in three forms: AEM 6.5 and AEM 6.5 LTS, self-hosted or on Adobe Managed Services, and AEM as a Cloud Service on subscription with continuous updates. SP26 is the final planned service pack for 6.5, so any remaining 6.5 work is tied to that release line. Treat February 28, 2027 as the working deadline for any migration, because it is the earlier of the two dates and extended support is limited to critical fixes. Confirm the current terms of each offering with Adobe, and read the AEM 6.5 support timeline article to check the dates that apply to your contract.

Start by inventorying what must move: sites, components, content fragments, DAM assets, workflows and integrations with marketing and identity systems. Ask your Adobe account team and any implementation partner for written estimates tied to that inventory, and list which items depend on AEM-specific features. A replacement project needs time for content export, schema mapping, frontend work and parallel running, so compare those phases against the earlier deadline and decide early whether you need a bridge to a supported path.

What the support deadline requires from your team

The February 28, 2027 core support end date sets the clock, but each path needs its own decisions, runtimes and evidence before that date. The cards below cover what your team must settle, build and verify, in roughly the order the work depends on.

A dated migration decision

Choose the target before the work plan can start: AEM 6.5 LTS, AEM as a Cloud Service or an open-source CMS. Each option carries a different scope of rebuild, licensing and hosting, so the decision should name an owner, the sites in scope and a go or no-go date. Core support ends on February 28, 2027, and extended support with critical fixes only runs until February 28, 2028. Confirm with Adobe which service pack applies to your environment, since SP26 is the final planned service pack.

A supported runtime for the target

The target platform must run on versions that still receive security fixes at go-live, not on the versions you have today. For Drupal, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later, and Drupal 10 reaches end of life on December 9, 2026, so a Drupal 10 build started now would need an upgrade soon after launch. Check the PHP, database and web server versions against the target's current requirements before you fix the hosting design.

A content export that stays readable

Export content, assets and workflow state from AEM 6.5 while the source estate is still running and supported. Keep the export in an open format such as Jackrabbit FileVault packages or JSON, and store a copy outside the AEM environment. Verify that the export holds the component data, content fragments and asset renditions you need, and record what it does not carry, such as user roles, permissions and version history, so you know what to rebuild by hand.

Identity and access carried across

Editors, approvers and administrators need the same sign-in and role model on the new platform. Map AEM groups and ACLs to the target's roles before cutover, and decide whether authentication moves to your existing identity provider through SAML or OpenID Connect. For Drupal, the contributed samlauth module supports Drupal 10.3 and later and Drupal 11, and the OpenID Connect module creates accounts on first sign-in. Confirm each module version against your target Drupal release before you rely on it.

A cutover plan for URLs and workflows

Plan the switch as a sequence: freeze content on a set date, run a final export and import, rebuild editorial workflows and publish approvals, and move assets with their metadata. Build a redirect map from every indexed AEM URL to its new address, and test it against a crawl of the live site. Keep the AEM environment available for read-only reference through the extended support period, which ends February 28, 2028, so teams can check content and records after the switch.

Which AEM 6.5 end of support path fits your estate

This table compares AEM 6.5 LTS, AEM as a Cloud Service and self-hosted Drupal, Wagtail or Strapi on support dates, authoring and asset scope, licensing, hosting control and upgrade cadence. Read each row against your own content model, and confirm current vendor terms with Adobe and each open-source vendor before you decide. Most AEM 6.5 estates should start with the February 28, 2027 and February 28, 2028 dates, because every path needs a migration plan that finishes ahead of them.

Criterion	AEM 6.5 LTS	AEM as a Cloud Service	Self-hosted Drupal, Wagtail or Strapi
Support deadline	Core support runs to February 28, 2027, then extended support with critical fixes to February 28, 2028.	Continuous updates on a subscription, so on-premise support dates do not apply. Confirm the cutover path.	No vendor deadline for the platform. Pick a supported release line and confirm its dates, since Drupal 10 reaches end of life on December 9, 2026.
Page authoring	Keeps the AEM Sites page editor, components and templates as they are deployed today.	Keeps AEM Sites authoring with continuous updates and Edge Delivery Services.	Drupal: Canvas visual builder and CMS recipes. Wagtail: StreamField blocks and moderation. Strapi: content types, with page editing depending on your frontend.
Assets, forms and DAM	Keeps AEM Assets and any licensed AEM Forms in your environment. Confirm entitlements in your contract.	Keeps AEM Assets in the cloud subscription. Confirm which Assets and Forms features your plan includes.	Media libraries and document handling come with each platform, but none replaces AEM Assets or Forms one for one.
Licensing	Commercial Adobe license and support terms. Confirm the scope in your agreement.	Commercial subscription. Confirm terms, usage limits and renewal conditions in your Adobe agreement.	Drupal GPL-2.0-or-later with no paid edition of Drupal. Wagtail BSD-3-Clause. Strapi MIT Community, with ee/ code under Enterprise license.
Hosting control	Self-hosted or Adobe Managed Services, so you keep control of the stack.	Adobe operates the cloud platform. You do not host the application infrastructure yourself.	You host in your own cloud, data center or air-gapped network, and you run upgrades and backups.
Upgrade cadence	Service packs continue until SP26, the final planned service pack.	Continuous updates applied by Adobe under the subscription.	Drupal 11 is current and Drupal 12 is scheduled for the week of December 7, 2026. Wagtail 7.4 LTS is supported until November 2, 2027.
Commercial support	Adobe support under your existing agreement.	Adobe-managed operations under the subscription. Confirm support levels in writing.	Support comes from partners and vendors such as Torchbox for Wagtail. Confirm scope, response times and SLAs before signing.
Main trade-off	Keeps the current estate running, but the support clock ends in 2027 and 2028.	Moves operational control to Adobe and may require changes to your cloud architecture.	You own upgrades, hosting and integrations, and any capability gap needs design and build effort.
Other open-source options	Not applicable	Not applicable	Payload (MIT, Next.js) suits developer-led teams. Directus is not OSI open source under its MSCL-1.0-GPL license.

What each path keeps and gives up after 2027

AEM 6.5 LTS keeps the most of your current estate. Your team stays on the same Java-based platform, so existing components, page templates, content fragments, the Digital Asset Management repository and workflows carry forward without a rewrite. The clock still matters: according to Adobe's support timeline, core support for on-premise AEM 6.5 ends February 28, 2027, and extended support with critical fixes only runs until February 28, 2028.

Components and templates: Existing components and templates stay in place, but every service pack still needs regression testing.
Assets and workflows: DAM contents, metadata and workflow models remain in the same repository.
Fixes after 2027: After core support ends, only critical fixes arrive until February 28, 2028, so the next platform decision cannot wait for the last year.
Operations: Your organization operates the infrastructure, patching, backups and Java runtime, or Adobe Managed Services does if you choose that model.
Recurring cost: Licensing and infrastructure recur, and the eventual move to a later platform is still a separate project.

Confirm with Adobe which service packs and fixes your contract covers, and whether Managed Services changes who is responsible for each operating task.

What an AEM export carries over and what you must confirm

The export step decides how much of an AEM 6.5 estate can move before the deadline, so it should be scoped before any target platform is chosen. Ask Adobe and your own AEM team to confirm, in writing, which repository content, DAM assets, content fragments, page structures, workflows, user groups and launches can be exported, and in what format. Confirm separately whether custom code, OSGi configuration and project-specific components are exported as code or only as content. These are different problems, and a fragment export says nothing about whether the templates that render it can be reused.

The second and larger effort is the target content model. Whatever the destination, whether AEM as a Cloud Service, AEM 6.5 LTS or an open-source CMS, editors will need content types, page templates and component equivalents that match how AEM pages are actually built today. Export files rarely carry that design intent. Ask for an inventory that lists each template, component, dialog and workflow with its owning team, its traffic and its dependencies on third-party integrations, and check it against the current site before any path is funded.

Before choosing a path, require a written inventory that your team has validated by sampling real content. Confirm which assets carry usage rights or metadata that the new platform must preserve, which users and groups need to be recreated, and how URLs and redirects will be handled. Treat any export format or tool claim you have not verified in your own environment as open until it is tested on a representative subset of the estate.

How to deploy the chosen open-source CMS under the deadline

This sequence takes the team from a confirmed target version to a tested cutover in its own cloud account, data center or private network, so the AEM 6.5 site has a supported home before core support ends on February 28, 2027.

Confirm target version and runtime
Choose the CMS and its exact release before any infrastructure is built. For Drupal, confirm Drupal 11 on PHP 8.3 or later, since Drupal 10 reaches end of life on December 9, 2026. For Wagtail, confirm a supported Django line (5.2.x, 6.0.x or 6.1.x) and pick between 7.4 LTS and the planned 8.3 LTS. For Strapi 5, confirm an Active or Maintenance LTS Node.js version and PostgreSQL 14 or later, because Strapi 5 does not run on MongoDB. Done when the platform owner signs off a version matrix covering the CMS, runtime, database, web server and operating system.
Build a staging environment in your own infrastructure
Provision a staging copy of the production stack inside the organization's cloud account, data center or private network. It should match the target database, web server, object storage for assets and identity endpoints. Your DevOps or platform engineers build it, and DeployOpen can do so under a fixed-scope agreement if you choose that route. Done when a placeholder site builds and serves from staging, and the team can reach it only through the intended network path.
Rebuild content models and migrate in phases
Rebuild the AEM content fragment models, templates and components as CMS content types, blocks or templates, then move content in batches ordered by business priority, such as high-traffic public pages first and archives last. Map each AEM component to a Drupal content type, a Wagtail StreamField block or a Strapi content type, and record the mapping in a shared sheet. Done when each batch is loaded, reviewed by the content owners and signed off against the mapping sheet.
Connect identity through SAML or OpenID Connect
Configure how editors and administrators sign in before they touch content. In Drupal, the contributed samlauth module lets the site act as a SAML service provider, and the OpenID Connect module handles external OIDC providers and creates accounts on first sign-in. In Strapi, SSO covers administrator login to the admin panel only, so end-user authentication must be handled separately. Confirm the module versions against each platform's compatibility notes. Done when a test editor signs in through the identity provider and the role mapping grants only the intended permissions.
Test backup and restore before cutover
Run a full backup of the staging database and file store, restore it into a clean environment and verify that pages, assets, users, roles and workflows match the source. Record the restore procedure as a runbook, including the order of database and asset restore. For Strapi, back up the database before any upgrade, because downgrading is not supported. Done when a restore from the backup reproduces the staging site and the runbook has been executed once by someone other than its author.
Plan redirects and cutover
Build a URL map from the old AEM paths to the new CMS paths, including language variants and asset URLs, and load it as permanent redirects in the web tier. Schedule the cutover window with the business owners, freeze content edits on AEM for the final sync, and run the last delta export. Done when a crawl of the old URL list returns the expected status on the new site and analytics confirms traffic arriving on new paths.
Set the upgrade cadence and keep AEM as the fallback
After cutover, put the platform on a written upgrade calendar. Wagtail 7.4 LTS has security support until November 2, 2027, and Wagtail 8.3 LTS is scheduled for May 4, 2027 with support until November 6, 2028, so plan the move onto the newer LTS well ahead of the older line's end. Drupal security releases arrive on the third Wednesday of each month, and Strapi ships minor releases often. Keep the AEM 6.5 environment read-only until the team confirms the new site is stable. Done when the upgrade calendar, owners and rollback criteria are documented and approved.

What auditors and regulators ask to see during the move

An AEM 6.5 exit leaves a trail of dated decisions, exports, restore results and access settings that someone will later need to explain. The cards below list the evidence worth preparing before cutover, so the record shows what changed, when, and who approved it. DeployOpen prepares systems, controls and evidence for compliance assessments, while independent auditors and certification bodies issue the reports and certifications.

Dated support lifecycle record

Keep a written record that ties the migration plan to Adobe's published dates: core support for AEM 6.5 on-premise runs until February 28, 2027, and extended support with critical fixes only runs until February 28, 2028. Record which dates the plan depends on, which service pack is the final planned one, and what happens if cutover slips past core support. Confirm the current dates with Adobe before sign-off, since assessors will compare your plan against the vendor's published timeline.

Signed path decision

Document the chosen route, whether AEM as a Cloud Service, AEM 6.5 LTS or an open-source CMS, with the options considered, the cost and risk factors weighed, and the named approvers. Include the reasons for rejecting the other paths, such as content model gaps or a required move to Edge Delivery Services. A signed decision gives auditors a clear owner for each later change and shows that the choice was made deliberately rather than under deadline pressure.

Content and asset inventory with export results

Produce a complete inventory of pages, content fragments, DAM assets, workflows and users, then attach the output of each export run. Compare record counts and asset checksums between the source and the target, and list every item that failed to transfer with its disposition. Note that the export format and scope depend on the path chosen, so the inventory should state exactly which repository paths and asset folders were included and excluded.

Restore test records

Keep evidence that backups of the old AEM estate and the new platform can be restored into a separate environment, and that the restored content matches the inventory. Record the date, the person who ran the test, the environment used and the discrepancies found. A backup that has never been restored is difficult to present as a control, so schedule restore tests before the cutover window rather than after it.

Access control and identity configuration exports

Export the role assignments, group mappings, service accounts and single sign-on settings from both the old and the new estates. Show that editors, approvers and administrators hold only the permissions their role requires, and that the identity provider settings match the approved design. Retain the exports with a date, because access reviews after cutover will compare against this baseline.

Cutover change records

Keep a change record for each step in the cutover, including the approver, the window, the rollback criteria and the result. Link redirect rules, DNS changes and certificate updates to their tickets so that a reviewer can trace every production change. Confirm your own change management policy and the controls your assessor expects, since the format of these records is set by your organization and your auditor.

How long and how much effort does an AEM 6.5 exit take?

What does the February 28, 2027 date mean if we have not started?

It means on-premise AEM 6.5 receives core support until February 28, 2027, and extended support with critical fixes only until February 28, 2028, according to Adobe's support timeline article. A team that has not started has roughly the period between now and the core end date to choose a path, scope the estate, and move the highest-traffic sites first. Work that starts late usually lands in the extended window, where you get critical fixes only and no new feature support. Confirm the current support terms and any renewal conditions directly with Adobe or your Adobe account team before you set internal deadlines.

Is AEM 6.5 LTS a bridge while we plan a move?

It can be, but it is a licensing and support decision, not a technical shortcut. AEM 6.5 LTS is one of the offerings Adobe lists alongside AEM as a Cloud Service and self-hosted or managed options, according to Adobe Experience League. Confirm with Adobe whether LTS changes the support dates above, what it costs, and whether it covers your hosting model. Any bridge still needs a rebuild plan, because the component code, DAM structure and workflows will still have to move if you leave AEM later.

How are cost and effort split across licenses, hosting, rebuild and operations?

The split has five parts, and each is paid to a different party:

Licenses or subscriptions to Adobe, or the continuing cost of your current AEM contract.
Hosting and infrastructure, which you pay to a cloud provider or data center, and which recurs.
Rebuild of templates, components, front ends and integrations, usually a one-time project cost.
Content and asset migration, including DAM metadata cleanup and redirects, also one-time.
Operations after go-live: patching, backups, monitoring and upgrades, which recur.

Ask any outside firm to price each part separately so you can see which costs disappear after cutover and which remain.

What drives AEM exit effort up or down?

The main drivers are the count and complexity of components, the volume and metadata quality of DAM assets, the number of sites and languages, the custom workflows and approval chains your editors use, and the integrations with marketing, search, identity and commerce tools. Each one adds analysis, mapping and testing time. A large estate with many bespoke components and heavy asset use will take far longer than a single content-led site with a small component library. Ask for an inventory of these items before any quote, because the inventory is what makes an estimate reliable.

What does the work need from our own team?

It needs named owners who can make decisions quickly. Typical roles include a product owner for content and editorial priorities, a technical lead who knows the AEM codebase, a content lead to sign off on mapping and redirects, an identity or security contact, and staff who run the chosen hosting environment. Editors must also test migrated pages and approve workflows. Agree in writing which tasks your team owns and which the outside partner owns, because unclear ownership is a common cause of delay.

Can our in-house team run the exit without outside help?

Some teams can, particularly those with strong Java, front-end and content operations skills and capacity to run a parallel project alongside their normal work. Others find that the migration competes with daily support for the same people. A useful test is whether your team has already exported content, mapped component models and run a test migration on a sample. If not, you can ask for a fixed-scope plan from DeployOpen covering planning, implementation and cutover, or split the work so your staff own parts you already know. Be clear about what you need to hand over.

What should a written quote for an AEM exit include?

A written quote should list the scope in the inventory's terms: number of sites, templates, components, content items, assets by volume, workflows, integrations and languages. It should name deliverables, acceptance tests, a cutover approach, redirect handling, and what happens to content that is not migrated. Ask for the assumptions behind each line, the client responsibilities, the change process if scope grows, and whether ongoing support is priced separately. DeployOpen works on fixed scopes agreed in writing before work starts, so ask for the same clarity from any vendor you compare.

Which AEM exit figures must we confirm with Adobe or a vendor?

Confirm the support end dates, any extension or renewal terms, the subscription or license costs for AEM as a Cloud Service and AEM 6.5 LTS, and the terms for managed services in your contract. Confirm with the target platform vendor the licensing, hosting limits and support terms you plan to use. Confirm with your hosting provider the infrastructure costs for your traffic and storage. Put these figures in your business case with a source and a date, because they change and your contract, not a public page, governs what you pay.

How DeployOpen plans and deploys an open-source CMS under a support deadline

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For AEM 6.5 customers, that means a written scope that fixes content, asset, integration and cutover work against the February 28, 2027 core support date before any build starts.

How we scope

Inventory AEM 6.5 sites, content fragments, DAM assets, workflows and integrations before choosing a target platform
Agree the scope, deliverables and timeline in writing before work starts, since most engagements are fixed-scope
Confirm with your team which AEM features your editors rely on, such as the page editor, and which can be rebuilt

How we build

Deploy the chosen open-source CMS in your own infrastructure, with hardening applied to hosts, databases and web servers
Map content models, templates and identity integration, testing each migrated content type against source content
Run security testing on applications and APIs before cutover, so issues are found while AEM 6.5 is still in service

How we hand over

Deliver architecture, configuration and runbook documentation so your operations team can run the platform without us
Prepare backup and restore procedures and test them, recording the results as evidence for your own assessors
Provide compliance readiness material on controls and evidence; independent auditors and certification bodies issue any formal reports

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Agree the upgrade approach with your team, including how security releases and major version changes will be applied
Ask for the retainer scope, response expectations and exit terms in writing alongside the initial quote

AEM 6.5 end of core support: move to AEM as a Cloud Service or replace