Services

Contentful to Sanity Migration for Next.js Websites

Plan the Sanity schema, migration scripts, preview flow, redirects, and Next.js data layer before the Contentful export becomes launch risk.

Move a Contentful‑backed Gatsby or Next.js site to Sanity while preserving entry relationships, rich text, preview, metadata, redirects, and editorial workflow.

Short Answer

A Contentful to Sanity migration is not just an export and import exercise. The risk sits in content models, references, rich text, preview, publishing workflow, redirects, metadata, and the Next.js data layer. Each part needs a mapped contract before entries are moved and editors are asked to trust the new CMS.

Where This Usually Shows up

  • Contentful has become expensive, awkward, or too rigid for the way the team now works.
  • The team has outgrown Contentful's lower tier, so asset limits and plan pricing now make normal publishing feel restrictive without moving into spend measured in thousands.
  • Content models have grown around old templates and no longer match the current front end architecture.
  • Editors need better preview, validation, structured content, or publishing workflows.
  • A front end migration is already planned, and the CMS has become the next constraint.
  • The team wants to move to Sanity but is worried about references, rich text, slugs, SEO fields, 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, media, localisation, metadata, 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, and front end integration project.
  • Preview, draft, and publishing 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.
  • 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.
  • Map references, rich text, media, slugs, metadata, redirects, preview, validation, draft behaviour, and publishing workflows explicitly.
  • 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, and publishing decisions harden around a hurried export and import plan.
  • When a Gatsby to Next.js migration is also the moment to stop carrying an old Contentful model into the next platform.
  • 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.

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