In an Adobe Experience Manager to headless migration, your structured content and metadata usually move cleanly, your templates and personalization and rendered pages have to be rebuilt from scratch, and your rankings leak wherever AEM was quietly generating HTML that nobody on your team actually wrote. That last part is the one that bites, so let's spend most of our time there.
Here's the thing that provoked this whole piece. A team I talked to costed their AEM exit by counting Content Fragments. Clean, tidy, a spreadsheet with a number at the bottom. They shipped roughly what they planned. Six weeks later organic traffic was down and nobody could point at a single deleted page. Nothing was missing. Everything was slower, thinner, and invisible to crawlers in ways the spreadsheet never had a column for.
You weren't renting a CMS. You were leasing a full-service tower.
Picture AEM as a floor in one of those enormous corporate buildings. You paid a fortune for it, sure, but the building did an astonishing amount of work you never noticed. There was a mailroom sorting your metadata. Security at the door checking every request. Climate control (the Dispatcher cache) keeping everything fast without you lifting a finger. Concierge staff rendering your pages into clean HTML the moment a visitor walked in.
A headless CMS is a warehouse. Great warehouse! High ceilings, cheap rent, you can put anything anywhere. But it is empty. There is a loading dock and a light switch. The mailroom, the security desk, the concierge, the climate control? Those didn't come with the lease. You are now those things, or you're hiring a front end to be them.
Most migration plans budget for moving the boxes. Almost nobody budgets for rebuilding the building.
What actually maps cleanly
The boxes move fine. Content Fragments in AEM are already structured, field by field, so they port into a headless content model with mostly mechanical mapping. Your DAM assets, your taxonomy, your metadata fields, your author-facing structured data: all of that is labeled and stackable. If you've kept your fragments disciplined, this is the honest, low-drama part of the job. (If you haven't, that's a different article about the attic.)
What you rebuild whether you budgeted for it or not
Experience Fragments are furniture bolted into the walls. They mix content with layout and presentation, and headless deliberately refuses to carry presentation. So every Experience Fragment becomes a rebuild decision, not a copy.
Templates and the whole component-rendering layer? Gone. AEM's components emitted your markup. Now a separate front end owns that. Personalization from Adobe Target, form handling, the Dispatcher's caching and URL rewriting, and any server-side logic living in your rendering tier all get rebuilt in the new stack. None of it is in the Content Fragment spreadsheet, and all of it was doing real work.
| Thing in AEM | What happens in a headless move |
|---|---|
| Content Fragments, DAM, taxonomy | Maps cleanly with field-level mapping |
| Experience Fragments | Rebuild: content and layout must be separated |
| Templates and components | Rebuild in the new front end |
| Dispatcher caching and URL rewrites | Rebuild in CDN plus front end |
| Adobe Target personalization | Rebuild or replace |
| Server-rendered HTML, meta, sitemaps | Rebuild, and this is where rankings leak |
Where the rankings actually leak
Here's the uncomfortable part. AEM was your concierge, and the concierge was rendering fully-formed HTML on the server, meta tags and canonicals and Open Graph and all, before a single pixel reached the visitor. Google's crawler and the AI answer engines walked up and got a complete page instantly.
Swap in a naive headless front end and, by default, a lot of frameworks ship the page as a nearly empty shell that fills itself in with JavaScript after load. Humans on fast phones barely notice. Crawlers on a budget do. If your content, your internal links, and your metadata only exist after the JavaScript runs, you have quietly told machines the page is thin. That's not a penalty. It's worse. It's an absence.
The specific leaks I see over and over: metadata that AEM templated automatically now missing because nobody rebuilt that logic; structured data (JSON-LD) that lived in a component and got left behind; canonical tags that no longer point anywhere sane once URLs change; XML sitemaps that the platform used to generate and now don't exist; and URL structures that shift because the Dispatcher's rewrite rules didn't survive the move. Every one of those was a thing the building did for free.
So the rule is blunt. Render your content server-side or statically so a crawler gets a complete page with no JavaScript. Reproduce every meta tag, canonical, and JSON-LD block your old templates emitted. Keep your URLs identical, or map every single change with a 301. If a URL has to change, it changes on purpose and it changes with a redirect behind it.
What I'd actually do
I'd stop costing an AEM exit by counting Content Fragments, because that number describes the boxes and ignores the building. Before I touched the new platform, I'd crawl the live AEM site and inventory what it's silently emitting: the rendered HTML, the meta and canonical tags, the structured data, the actual URL list, the assets nothing links to anymore. That inventory is the real scope, and it's the diff you check the new site against on launch day. (Building that pre-migration picture is exactly the job we built Replatform Radar to do, and there's a walkthrough for this specific move at /migrate/aem-to-headless.)
Headless is genuinely a better warehouse. Cheaper, more flexible, faster to build on, and you finally own your front end instead of fighting a template dialog. I'd make the move. I'd just remember that on the last day in the old building, nobody hands you the mailroom staff on the way out. You have to hire them before the movers arrive, or the mail keeps getting delivered to an address you no longer live at.