This is an illustrative composite scenario. It does not describe any single real organization; it generalizes patterns we see repeatedly across enterprise replatforming projects. Figures are typical ranges, not one company’s exact numbers.
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.
A pre-migration scan makes this concrete: the AEM-to-Contentful path is where content-model debt and redirect scale hide, and seeing them before you start is the difference between a clean cutover and a quarter of lost traffic. Replatform Radar maps that surface for your own site before the project begins.