Adobe has published the dates, and they are closer than most roadmaps assume. AEM 6.5 support for Adobe Managed Services customers ends on August 31, 2026. Core support for on-premise deployments ends in February 2027, with the 6.5 LTS branch positioned as the bridge for teams that need more runway. If your organization runs on 6.5, you are no longer deciding whether to move. You are deciding where to move, and the engineering path you choose will define your delivery capacity for the next five years.
In my experience leading platform engineering teams through migrations at scale, the AEM conversation almost always starts in the wrong place: the vendor's upgrade matrix. Version numbers and support windows matter, but they are inputs, not the decision. The decision is an engineering problem with three candidate architectures, and it deserves the same rigor you would apply to any system you expect to operate for a decade.
Three Paths
AEM 6.5 LTS is a runway, not a destination. It brings the 6.5 code base onto Java 17 and 21, removes legacy libraries, and keeps your existing infrastructure model intact. That is precisely its limitation. Every OSGi customization, every workflow, every dispatcher rule, and every operational burden you carry today survives the upgrade. You buy time, and you carry the debt forward with interest.
AEM as a Cloud Service is a re-architecture wearing an upgrade's name badge. The immutable repository changes how code deploys. Asset processing moves to compute microservices. Deprecated APIs force refactoring across any codebase with real history. Gartner benchmarks complex 6.5 to Cloud Service migrations at $500K to $5M, and having scoped several, I consider those numbers honest.
Leaving for a structured content platform is also a rebuild. Nobody should pretend otherwise. Content models get redesigned, frontends get rewritten, and integrations get rewired. The difference is what you are rebuilding toward: a platform where content is structured data served through APIs, where the frontend is a modern framework your team can hire for, and where the license line item drops by an order of magnitude.
Two of your three paths are rebuilds. Once you accept that, the question stops being how to avoid a migration and becomes which rebuild produces the platform you actually want to operate in 2030. I made the broader case in Alternatives to Adobe Experience Manager, and Marla Quinn has covered the economics in AEM vs. Sanity: What Are You Actually Paying For? This post is about execution.
What Migrates and What Gets Rebuilt
Here is the distinction that makes AEM migration estimates go wrong: your JCR is not your content model. It is a rendering tree. Pages in AEM are compositions of components, and components carry both content and presentation decisions. When you export a page, you are exporting layout choices made by an author five years ago, interleaved with the words and images that actually matter.
The content migrates. The composition does not. Concretely:
- Migrates cleanly: page content, asset binaries and metadata, taxonomy and tags, URL structures, publish states, and anything already modeled as Content Fragments.
- Gets rebuilt: HTL templates and components, OSGi services, Sling models, workflows, dispatcher and CDN configuration, and every integration touching the author or publish tiers.
If your teams adopted Content Fragments and Experience Fragments seriously, celebrate. Fragments are the closest thing AEM has to structured content, and they map to a headless content model with minimal transformation. If your estate is classic page components all the way down, plan for a modeling phase before an extraction phase.
Step One: Inventory the Repository Before You Trust Any Estimate
Every AEM estate I have audited shows the same distribution: a long tail. A handful of templates carry the overwhelming majority of pages, and dozens of components exist that render on fewer than ten pages each. You cannot scope a migration until you know your distribution, and AEM gives you the tools to find it.
QueryBuilder and JCR SQL2 queries against the author instance will tell you pages per template, component usage frequency, asset counts by MIME type and size, and last-modified dates that reveal how much of the repository is actually alive. In a recent audit, 62 percent of pages had not been touched in over three years. That is not migration scope. That is an archiving decision.
Run this inventory before you accept any estimate, from us or anyone else. It converts the migration from a fear into a bill of materials.
Step Two: Model the Content, Not the Components
The most common failure pattern in CMS migrations is one-to-one component mapping: recreating every AEM component as an equivalent block in the target platform. It feels safe, and it produces a content model shaped like your 2019 design system rather than your content.
Model the domain instead. A hospital system does not have 47 component types. It has locations, providers, services, articles, and policies. When we design target schemas, we work from the content inventory to a compact set of document types with clear relationships, then map the long tail of components into structured fields or portable rich text. The result is a model your editors understand and your next redesign will not break.
Step Three: Extraction Is the Easy Part
Engineers new to AEM migrations expect extraction to be the hard part. It rarely is. AEM exposes several reliable paths out: Sling's JSON rendering gives you any resource as JSON with a URL suffix, QueryBuilder returns result sets in JSON, content packages give you filtered subtree exports, and the Assets HTTP API hands you binaries with renditions and metadata.
The real work is the transform layer: mapping extracted component JSON into your target model, normalizing rich text, resolving internal links into references, and preserving publish metadata. We build these as repeatable pipelines with validation on both ends, because you will run them dozens of times before cutover, not once.
Throttle against the author tier, checkpoint your progress, and log every skipped node. Boring engineering. It is also the difference between a migration you can rehearse and one you attempt.
The DAM Question Deserves Its Own Decision
More organizations are anchored to AEM by Assets than by Sites. If your DAM holds hundreds of thousands of governed assets with rights management and approval workflows, treat it as a separate architectural decision. You have three defensible options: keep Assets as a standalone DAM feeding your new platform through its API, move to a dedicated DAM, or migrate web-resolution assets into your content platform and archive the rest.
What you should not do is let 40 terabytes of archival imagery hold your content delivery architecture hostage. Separate the asset governance problem from the content delivery problem, and both get simpler.
Sequencing the Cutover
Phased cutovers beat big-bang cutovers, and the routing layer is what makes them possible. Put a CDN or reverse proxy in front of both platforms and move traffic section by section: start with the content-heavy, integration-light areas, and finish with the pages that touch identity or transactions.
- Generate the redirect map from JCR paths programmatically, and validate it against live analytics data before launch.
- Hold SEO parity checks as release gates: titles, canonicals, structured data, and sitemap coverage on every migrated section.
- Keep content freeze windows to days per section, not weeks, by re-running your extraction pipeline as a delta sync just before each switch.
- Decommission on a schedule. An AEM license that lingers six months past cutover erases a meaningful slice of the savings.
What This Actually Costs
For content-driven marketing estates, the numbers usually surprise people in a good direction. The rebuild is a fixed cost on two of your three paths, but only one of those paths also carries Adobe's license and infrastructure profile forward. When the target is a structured content platform with a modern frontend, the implementation is typically comparable to or smaller than the Cloud Service re-architecture, and the run rate drops sharply from year one.
Complex estates change the calculus. Deep Adobe stack integration, heavy DAM workflows, and regulated personalization may justify staying, and an honest assessment will say so. The point is to price both rebuilds with real inventory data instead of defaulting to the vendor path because it feels like less of a decision.
Practical Takeaways
- Run the repository inventory this week. Pages per template, component frequency, asset volumes, and last-modified distribution turn fear into scope.
- Treat 6.5 LTS as a bridge with a written exit date, not a strategy.
- Decide the DAM question separately from the CMS question.
- Model your content domain. Never map components one to one.
- Build extraction as a rehearsable pipeline and cut over in phases behind a routing layer.
The deadlines Adobe published are fixed. Your architecture is not. Whichever direction you choose, choose it from an inventory and a model, not from a renewal notice. If you want a second set of eyes on your repository data, that is exactly the kind of engineering conversation we like having.
