Sitecore to Contentful Migration: A Composite Case Study

Context

This is an illustrative composite. It does not describe any single organization; it blends the patterns we repeatedly see when a mid-market B2B software company — roughly 8,000 to 20,000 URLs, a marketing team of 15–30, and a decade of accumulated Sitecore content — moves to Contentful. Treat every number as a typical range, not one client's exact figure.

The starting point is familiar. The organization runs a mature Sitecore XP instance with heavy reliance on the Experience Editor, dozens of rendering variants, and personalization rules layered on over the years. Licensing and hosting costs have climbed, releases are slow because front-end and CMS are coupled, and the marketing team wants to ship a headless React front end backed by an API-first CMS. Contentful becomes the target for its clean content modeling, strong delivery API, and lower operational burden.

The business case is sound. The trouble is that most teams estimate the move as a content transfer project when it is really a content re-modeling and signal-preservation project. That gap is where the pain concentrates.

What broke

Redirects and URL structure

Sitecore item paths and the marketing URL structure had drifted apart over years of aliases, wildcards, and item-level redirect modules. When the team exported URLs, they found 15–25% more live, indexed paths than the sitemap suggested — old campaign landing pages, aliased duplicates, and trailing-slash variants all resolving with 200s.

On the Contentful side, URLs are generated by the front end from slug fields, so the historical path logic simply did not exist anymore. The first launch attempt shipped without a complete redirect map. The result was a wave of soft and hard 404s, orphaned deep links from external sites, and a two-to-three week ranking dip on long-tail terms that never fully recovered for the pages that were dropped silently.

Content model mismatches

Sitecore templates are permissive: a single template often accumulates 40–80 fields, many optional, many used inconsistently by different authors. Contentful content types are stricter and reward smaller, composable models. The naive mapping — one Sitecore template to one Contentful content type — produced bloated types full of nullable fields and encoded business rules that no longer applied.

The worst breakage came from rich text and embedded renderings. Sitecore stored markup with inline component placeholders and datasource references. Contentful's rich text is a structured JSON document with typed nodes and entry links. A straight HTML dump lost component boundaries, broke internal links, and stripped structured elements down to flat paragraphs. Roughly 30–40% of body content needed manual or scripted repair after the first automated pass.

Lost SEO and AEO signals

Metadata lived in several places in Sitecore: dedicated fields, a SEO module, and hardcoded rendering logic. During export, only the dedicated fields were captured. Canonical tags, hreflang pairings, structured data (FAQPage and Article schema), and Open Graph values that had been generated at render time silently vanished.

For answer-engine visibility (AEO), the loss of FAQ and How-To structured data was the quiet killer. Pages that had earned featured snippets and appeared in AI-generated answers dropped out of those surfaces because the machine-readable signals were gone, even though the visible copy looked identical. Nobody noticed for weeks because top-line traffic dashboards averaged over the whole site.

Taxonomy gaps

Sitecore's tree structure was the taxonomy — hierarchy, related-content logic, and navigation all derived from item position. Contentful is flat by design, so relationships must be modeled explicitly with reference fields and tags. The migration recreated the pages but not the relationships. Related-content modules went empty, faceted filters lost their source data, and breadcrumb logic had to be rebuilt from scratch. Around 20% of internal links that depended on tree proximity disappeared.

What worked

The recovery playbook, and the things worth repeating, were consistent:

• A full URL and signal inventory before any modeling. Crawling the live site (not just the sitemap) and cross-referencing server logs surfaced the real indexed footprint and the pages actually earning traffic and links.
• Content-type redesign rather than one-to-one mapping. Breaking fat templates into small, composable content types — hero, callout, FAQ block, author — made the model cleaner and made rich-text migration tractable.
• A scripted, validated rich-text transform. Converting Sitecore markup to Contentful's rich-text JSON with a mapping table for known components, then flagging anything unmapped for human review, caught the 30–40% of problem content before launch.
• Structured-data parity checks. Rebuilding schema in the front end and diffing rendered structured data against pre-migration snapshots restored AEO signals deliberately rather than hoping they carried over.
• Explicit taxonomy modeling with Contentful tags and reference fields mapped from the old tree, so related content and navigation could be regenerated.

Lessons

1. Migration is re-modeling, not copying. Budget the majority of effort for content architecture and transformation, not data transfer. The export is the easy 20%.
2. Crawl the live site, not the sitemap. The sitemap describes intent; the crawl and server logs describe reality. The delta is where redirects get missed.
3. Treat render-time signals as first-class content. Canonicals, hreflang, structured data, and meta tags that were generated by Sitecore renderings will not appear in a field export. Inventory them explicitly.
4. Rich text is structured data, not HTML. Plan a component-aware transform to Contentful's JSON format and expect manual cleanup on complex pages.
5. Hierarchy must become relationships. Anything the Sitecore tree gave you for free — navigation, related content, breadcrumbs, facets — has to be modeled deliberately in a flat headless system.
6. Measure at the page level, not the site level. Averaged dashboards hide the exact pages that lost snippets, links, or rankings.

Before you make this move

A short pre-migration checklist for teams eyeing this path:

• Full crawl + log-based URL inventory, with a 1:1 redirect map drafted before content modeling starts.
• An audit of every render-time SEO/AEO signal (canonical, hreflang, schema types, OG tags) and where each is generated.
• A content-type design proposal that decomposes fat Sitecore templates into composable Contentful types.
• A rich-text transform plan with a component mapping table and a manual-review queue.
• A taxonomy model that translates tree hierarchy into tags and reference fields.
• Baseline snapshots of rankings, snippet ownership, and structured data for your top 200–500 pages, so regressions are visible.
• A staged launch with monitoring on 404 rates, redirect hits, and per-template indexation.

The pages that quietly lose their machine-readable signals are the ones that hurt most, because they look fine to a human reviewer and disappear only from search and answer engines.

Mapping these risks up front is exactly the kind of pre-migration intelligence Replatform Radar produces for Sitecore-to-Contentful moves — a signal inventory and risk map before the first content type is created. However you get there, do the discovery before the migration, not after the traffic dips.