Before we start: this company doesn't exist. It's a composite, stitched together from the same patterns we watch play out on enterprise replatforming projects over and over (the names change, the pain doesn't). No single organization is being described here. The numbers are typical ranges, the kind you'd nod along to, not one company's actual figures pulled from an actual spreadsheet.
Somewhere in a manufacturer's quarterly review, someone reads the Adobe Experience Manager line item out loud, and the room goes quiet in the particular way rooms go quiet when a number turns out to be bigger than anyone remembers agreeing to. Authoring licenses, an infrastructure team on permanent standby, a release cadence that made every campaign feel like a small capital expense. That's usually where these migrations actually start: not with a grand vision of an API-first future, but with a cost that quietly stopped being worth it.
And here's the thing nobody warns you about. You'd assume two content management systems have enough in common that moving between them is mostly copying content from one to the other. They don't, and it isn't. AEM and Contentful agree on almost nothing below the surface, which is exactly why I wanted to walk through one of these end to end: to show you where the money and the traffic actually go missing, and which of those losses you can see coming.
Context
Picture a global manufacturer with a marketing estate on Adobe Experience Manager — several regional sites, tens of thousands of pages and DAM assets, and a component library that had grown for the better part of a decade. AEM had done its job, but total cost of ownership was the problem: authoring licenses, an infrastructure team to keep environments healthy, and a release cadence that made every campaign feel expensive. Leadership wanted a leaner, API-first stack a smaller team could run, and a front end their developers actually enjoyed. Contentful paired with a Next.js front end was the target.
On paper the appeal is obvious: no servers to patch, content delivered as clean JSON, and a modern component model. In practice, AEM and Contentful share almost nothing at the architecture level — the Java Content Repository and HTL rendering on one side, typed content models and a headless delivery API on the other. Nothing lifts and shifts, and the projects that go badly are the ones that assume it will.
What broke
The failure modes clustered in four places. None were exotic; all were predictable with earlier discovery.
Content Fragments to content types
Years of loosely-structured authoring in the JCR had produced deeply nested, inconsistent content. AEM tolerates that; Contentful’s typed content models do not. The first instinct — recreate every component one-to-one — produced dozens of near-duplicate content types and a modeling mess. The work that mattered was consolidation: collapsing variants, extracting genuinely reusable blocks, and deciding what not to bring at all.
DAM assets and in-body links
AEM’s dynamic-media renditions, smart crops, and asset URLs have no equivalent in Contentful. Only originals and their metadata should move; renditions are regenerated. The trap is embedded links: every image reference and download URL inside rich text pointed at old AEM paths, and without a rewrite pass those became broken images the moment the old environment went dark.
Redirects and URL structure
AEM’s /content/site/… paths and vanity URLs mapped to a completely different route structure under Next.js. The redirect map — thousands of URLs across regions — was badly underestimated, and the team nearly shipped without a complete one. A late audit caught it; had it not, the organic-traffic loss would have taken quarters to recover.
Personalization and authoring experience
Targeting and the in-context authoring editors had no drop-in replacement. Marketers used to editing on a live-looking page found themselves filling in fields in an entry editor. That gap — more than any technical hurdle — is what threatened adoption, and it had to be closed with preview environments and training, not code.
What worked
The move succeeded because the team treated it as a rebuild with a content migration, not a port. They modeled content types first, on paper, before touching either system. They scripted the actual transfer through AEM’s Assets/JCR APIs into Contentful’s Management API, so it was repeatable and testable rather than a one-shot manual effort. And they stood up a Contentful preview integration early, so editors could see pages render long before launch — which turned the adoption risk into a non-event.
Lessons
- Model before you migrate. The expensive mistake is recreating the old component tree. Consolidate content types up front; you will move far less content than you expect.
- Migrate originals, regenerate the rest. Move DAM originals and metadata only, and rewrite every in-body asset link to the new paths.
- The redirect map is the SEO project. Build a complete old-to-new 301 map per region before cutover, not after traffic drops.
- Editor experience decides adoption. A headless editor with no sense of the live page sinks adoption faster than any bug — invest in preview and training early.
- Rebuild personalization deliberately. Targeting logic does not port; plan it as new work on the new stack.
Before you make this move
A short pre-migration checklist that would have de-risked this project from day one:
- Inventory every page, template, Content Fragment model, and DAM asset — and decide what is being retired, not just moved.
- Draft the target content model and validate it against your messiest real content, not your cleanest.
- Produce a complete redirect map covering vanity URLs and every locale.
- Identify all personalization, forms, and third-party integrations that need rebuilding rather than migrating.
- Stand up a preview experience for editors before launch, and pilot it with real authors.
So here's where I land, plainly: this move is worth making, but only if you stop pretending it's a copy job and treat it as a rebuild that happens to carry content along. The order is what saves you. Model your content types first, on paper, against your messiest real pages and not your cleanest. Build the full old-to-new redirect map, every locale, before cutover rather than after the graph sags. And stand up a preview environment early, so your marketers open a page that looks like a page instead of a wall of empty fields. Do those three things and the cutover gets boring, which is the nicest thing a cutover can be. Replatform Radar exists to surface that debt before you commit, and I'd run that scan before signing off on anything.
Skip the discovery, though, and you don't escape the uncomfortable finance review that started all this. You just trade it for a worse one a few months later, where the number you're explaining out loud to a very quiet room is quarters of lost organic traffic, and nobody in the room saw it coming because nobody went looking.