Services

Contentful to Sanity Migration for Next.js Websites

This is not a content export dressed up as a migration. The Sanity schema, migration scripts, preview flow, validation rules, redirects, and Next.js data layer need planning before the Contentful model is copied into a new CMS.

Move a Contentful‑backed Gatsby or Next.js site to Sanity without losing content meaning, references, rich text, assets, slugs, locales, metadata, preview, or editorial control.

Short Answer

A Contentful‑to‑Sanity migration succeeds when the new Sanity model fits the site and editorial workflow, not when every Contentful content type is mirrored one‑to‑one. The risk sits in references, rich text, assets, slugs, locales, metadata, validation, preview, publishing workflow, and the front‑end data layer. Sanity is not automatically the better move for every team, so the first decision is whether the migration solves the real editorial and platform constraint.

Where This Usually Shows up

  • Contentful has become expensive, awkward, or too rigid for the way the editorial team now works.
  • Content types, references, locales, rich text, and assets have grown around old templates rather than the current site model.
  • Editors need better preview, validation, structured content, or publishing workflows than the current setup provides.
  • A Gatsby or Next.js migration is already planned, and the CMS model has become the next constraint.
  • The team wants Sanity, but is worried about references, rich text, slugs, SEO fields, locales, preview, and launch risk.

What Tends to Be Going Wrong

  • Contentful models were built around the original implementation rather than the current editorial model.
  • Rich text, references, assets, locales, metadata, slugs, and page composition are too tightly coupled to legacy templates.
  • The team is treating the CMS migration as a data transfer rather than a content‑model, workflow, validation, and front‑end integration project.
  • Preview, draft, publishing, and rollback behaviour has not been treated as part of the migration contract.

What I Look at First

  • Current Contentful content types, entries, assets, references, rich text, locales, slugs, metadata, and preview behaviour.
  • The target Sanity schema, document structure, validation rules, Studio workflow, preview setup, and front end query layer.
  • Routes, templates, redirects, canonicals, sitemaps, internal links, and structured data that must survive the migration, checked against the Headless CMS SEO Controls Matrix and Structured Data Implementation Matrix.
  • Existing Gatsby or Next.js data‑fetching assumptions that could break when the CMS changes.

How I Help Fix This

  • Audit the existing Contentful model before Sanity schema decisions are made.
  • Decide what should be preserved, simplified, split, or rebuilt in Sanity rather than blindly reproducing old Contentful models.
  • Use the Headless CMS SEO Controls Matrix to map references, rich text, media, slugs, metadata, redirects, preview, validation, draft behaviour, and publishing workflows explicitly.
  • Use the Structured Data Implementation Matrix where schema needs to survive the CMS and front‑end migration without drifting from visible page content.
  • Update the Gatsby or Next.js front end data layer, rendering behaviour, cache behaviour, sitemap output, structured data, and SEO metadata around the new CMS contract.
  • Run at least one full test migration before the final migration and cutover pass.

What Needs Proving Before Delivery Starts

  • Before schema, preview, validation, and publishing decisions harden around a hurried export and import plan.
  • When a Gatsby to Next.js migration is also the moment to decide whether the old Contentful model should survive at all.
  • On Contentful‑heavy work such as IMG Licensing, this mattered because editorial workflow continuity and search‑critical routes needed to survive front‑end change rather than being treated as secondary details.

What Gets Resolved

  • Contentful content types are mapped to a Sanity schema that fits the site, not just the export.
  • Entries, references, rich text, assets, slugs, and metadata have a controlled migration path.
  • Preview, draft, publishing, and validation behaviour are rebuilt around the editorial workflow.
  • Front end data fetching, rendering, and cache behaviour are updated for Sanity.
  • SEO‑critical routes, metadata, schema, internal links, redirects, and sitemap output are checked before launch.

How This Usually Works

  1. Technical Diagnostic

    A focused review of affected routes, templates, deployment behaviour, crawl signals, CMS behaviour, performance bottlenecks, or code paths, followed by a prioritised fix plan the team can take into delivery.

  2. Embedded Delivery Support

    Senior hands‑on support inside an existing team where architecture, implementation, review, and delivery judgement all matter, especially when the work cannot be handed over as isolated tickets.

  3. Fractional Technical Leadership

    Ongoing senior technical cover for architecture, roadmap, supplier review, delivery risk, hiring shape, and platform‑ownership decisions when the team is not ready to hire permanently.

Common Questions

Is this just a Contentful export and Sanity import?
No. Export and import is only the data movement. The migration needs content model audit work, schema decisions, reference and rich text mapping, preview behaviour, validation, routes, redirects, metadata, and editorial workflow checks before launch.
Can this happen during a Gatsby to Next.js migration?
Yes. That is often the right time to do it, provided the CMS migration is treated as its own contract rather than hidden inside the front end rebuild.
Should Sanity always replace Contentful?
No. Sanity is useful when its modelling, workflow, and developer experience solve the current constraint. If the real problem is preview speed, front‑end caching, or model hygiene, that should be proven before moving CMS.

Talk to me about your migration

A short description of the current platform, target Next.js setup, and main migration risk is enough. I'll read it and suggest the next step.

Get in touch

Related Case Studies and Project Work

  1. Screenshot of the Wreel Agency website; part of John Kavanagh's selected project work.

    A Design‑Led, Highly‑Animated Agency Website

    On Wreel, the migration judgement applied to a smaller content platform where simpler delivery and maintainable templates were the real win.

    View case study
  2. Screenshot of the Red Central website; part of John Kavanagh's selected project work.

    A Bold, Media‑Led Gatsby and Contentful Studio Website

    Red Central headless CMS delivery kept preview, content structure, and front‑end templates practical.

    View case study
  3. Screenshot of the IMG Licensing website; part of John Kavanagh's selected project work.

    An All‑New Identity and Website for IMG Licensing

    IMG Licensing's rebuild made publishing structure, page generation, and long‑term maintainability simpler rather than heavier.

    View case study

More Specific Service Pages

Related Services

All Services

Related Technical Articles