Je team geeft groen licht voor de Sanity switch. Je exporteert 80.000 WordPress posts, draait een Studio instance op, en ontdekt dat de helft van je metavelden drie verschillende schemas volgen — en niemand heeft de aangepaste taxonomielogica gedocumenteerd die je hele site navigatie aandreef. Ik heb in drie jaar 40+ migraties naar Sanity uitgevoerd. Sommige sloten in twee weken af. Anderen rekten uit tot drie maanden en deden me elk besluit heroverwegen dat me naar freelancing bracht. Het verschil kwam nooit neer op of je WordPress, Contentful of Drupal verlaat. Het kwam neer op drie dingen: hoe eerlijk je je content model vooraf bepaalde, of je veldmapping als architectuur of druk werk behandelde, en of iemand in je team toegaf niet te begrijpen hoe je oude CMS eigenlijk werkte. Dit playbook loopt je door elk besluit dat bepaalt of je migratie een schone sprint of langzaam uiteenvallen is — en toont je de exacte checklists, scripts en mentale modellen die beide scheiden.

Dit is de gids die ik had willen hebben toen ik CMS-migraties begon uit te voeren. Het behandelt het verplaatsen van WordPress, Contentful en Drupal naar de GROQ-aangestuurde wereld van Sanity. Ik zal eerlijk zijn over waar Sanity uitblinkt, waar het je zal frustreren, en hoe de echte tijdlijnen eruitzien.

Inhoudsopgave

Sanity Migratiehandleiding: verhuizen van WordPress, Contentful of Drupal

Waarom teams in 2026 naar Sanity verhuizen

Laten we de voor de hand liggende zaken uit de weg ruimen. Sanity's real-time collaboratief bewerken, aanpasbare Studio en structured content-aanpak zijn echt goed. Maar de reden waarom de meeste teams ons over migratie benaderen is niet omdat ze een blogpost over Sanity's functies hebben gelezen. Het is omdat iets kapot ging.

WordPress sites raken schaalwanden rond 50.000+ stukken content met complexe aangepaste post types. Contentful's prijsmodel begint te knellen bij enterprise-niveau — we hebben teams gezien met $3.500+/maand rekeningen voor wat eigenlijk een content API is. Drupal teams kunnen niet meer developers vinden, in ieder geval niet die met PHP-templating in 2026 willen werken.

Sanity's prijsmodel is echt voorspelbaarder voor de meeste teams. De gratis tier dekt tot 100K API-verzoeken/maand en 500K assets. Het Growth plan op $99/maand/project geeft je 2,5M API-verzoeken en 1M assets. Ter vergelijking, Contentful's Team plan kost $300/maand en Contentful's Premium tier kan makkelijk $2.000/maand overschrijden.

Maar hier is mijn eerlijke mening: als je huidige CMS prima werkt en je team is productief, migreer dan niet alleen omdat Sanity nieuwer of cooler is. Migraties kosten altijd meer dan je denkt.

Pre-migratieaudit: de stap die iedereen overslaat

Voordat je een enkele regel migrationcode schrijft, heb je een content audit nodig. Niet een snelle scan — een echte audit. Dit is wat dat eruitziet:

Content inventarisatie

Documenteer elk content type, elk veld, elke relatie. Ik gebruik een spreadsheet met deze kolommen:

  • Content type naam
  • Totale items
  • Velden (met types)
  • Relaties naar andere content types
  • Media bijlagen (aantal en totale grootte)
  • Aangepaste functionaliteit (shortcodes, widgets, embeds)
  • Laatst gewijzigd
  • Nog relevant? (Ja/Nee/Misschien)

Je zult geschokt zijn hoeveel content dood gewicht is. Bij één WordPress-migratie had een klant 12.000 posts. Na de audit waren slechts 4.200 nog relevant. Dat is 65% minder content om te migreren, testen en valideren.

Technische afhankelijkheidsmapping

Lijst elke plugin, module of integratie op die je huidige CMS gebruikt. Voor elk ervan bepaal:

  1. Kan Sanity dit native hanteren?
  2. Is er een Sanity plugin voor?
  3. Moeten we een aangepaste oplossing bouwen?
  4. Kunnen we dit geheel loslaten?

Deze mapping alleen bespaart je al weken verrassingen.

Gereedheidsbeoordelingsteam

Sanity Studio is op basis van React. Je content editors hebben training nodig. Je developers moeten GROQ leren (of GraphQL gebruiken, hoewel GROQ waar Sanity echt goed in is). Budget 1-2 weken voor team onboarding — niet als nice-to-have, maar als regelitem.

WordPress naar Sanity-migratie

WordPress is de meest voorkomende bron CMS waarvan we migreren. Het is ook het lastigste, omdat WordPress niet alleen een CMS is — het is een volledig applicationplatform waarop mensen alles hebben vastgeplakt.

Wat overdraagt schoon

  • Posts en pagina's (basis content)
  • Categorieën en tags
  • Uitgelichte afbeeldingen
  • Auteurgegevens
  • Basis aangepaste velden (ACF, Meta Box)

Wat wordt ingewikkelder

  • Gutenberg blokken: Elk bloktype moet een overeenkomstig Sanity Portable Text aangepast blok of objecttype hebben. Als je 15+ aangepaste Gutenberg blokken hebt, budget aanzienlijke tijd.
  • Shortcodes: Deze moeten geparseerd, geïnterpreteerd en omgezet naar Portable Text annotaties of aangepaste blokken. WPBakery en Elementor shortcodes zijn bijzonder pijnlijk.
  • Plugin-gegenereerde content: WooCommerce producten, Yoast SEO data, ACF repeater velden — elk vereist aangepaste migratielogica.
  • Mediabibliotheek: WordPress slaat meerdere afbeeldingsgrootten op. Sanity verwerkt afbeeldingstransformaties on-the-fly, dus je hebt alleen de originals nodig. Maar het vinden van originals in een rommelige wp-uploads folder? Leuk.

Migratiescraptbenadering

Ik gebruik meestal een Node.js script dat het WordPress REST API raakt en naar Sanity's mutation API schrijft:

import { createClient } from '@sanity/client'
import fetch from 'node-fetch'

const sanity = createClient({
  projectId: 'your-project-id',
  dataset: 'production',
  token: process.env.SANITY_WRITE_TOKEN,
  apiVersion: '2025-01-01',
  useCdn: false,
})

const WP_API = 'https://yoursite.com/wp-json/wp/v2'

async function migratePosts(page = 1) {
  const res = await fetch(`${WP_API}/posts?per_page=100&page=${page}`)
  const posts = await res.json()
  const totalPages = res.headers.get('x-wp-totalpages')

  const transaction = sanity.transaction()

  for (const post of posts) {
    transaction.createOrReplace({
      _id: `wp-post-${post.id}`,
      _type: 'post',
      title: post.title.rendered,
      slug: { current: post.slug },
      publishedAt: post.date,
      // Body vereist HTML-naar-Portable-Text omzetting
      body: await convertToPortableText(post.content.rendered),
    })
  }

  await transaction.commit()
  console.log(`Migrated page ${page} of ${totalPages}`)

  if (page < totalPages) {
    await migratePosts(page + 1)
  }
}

De convertToPortableText functie is waar 80% van de complexiteit zit. Ik gebruik het @sanity/block-tools package gecombineerd met jsdom voor HTML parsing. Het verwerkt basis HTML goed, maar aangepaste elementen en shortcodes hebben individuele handlers nodig.

Realistische tijdlijn

Voor een typische WordPress site met 500-2.000 posts, standaard aangepaste velden en een handvol aangepaste post types: 4-8 weken inclusief content modellering, migratiesript, validatie en editor training.

Sanity Migratiehandleiding: verhuizen van WordPress, Contentful of Drupal - architectuur

Contentful naar Sanity-migratie

Contentful-naar-Sanity is eigenlijk het soepelste migratiepad van de drie. Waarom? Omdat beide structured content platforms zijn met gelijkaardige mentale modellen. Je content zit al in een headless CMS met gedefinieerde content types en velden.

Belangrijke verschillen om rekening mee te houden

Functie Contentful Sanity
Rich text Rich Text (JSON-based) Portable Text (JSON-based)
Content modellering Web UI Code-gedefinieerde schemas
Query taal GraphQL / REST GROQ (+ GraphQL)
Lokalisatie Built-in veld-niveau Plugin of aangepast
Referenties Links (Entry/Asset) Referenties met types
Webhooks Ja Ja
Asset handling Built-in CDN Sanity CDN + hotspot/crop
Prijsstelling (mid-tier) ~$300/mnd (Team) $99/mnd (Growth)

Rich Text omzetting

Contentful's Rich Text en Sanity's Portable Text zijn beide JSON-gebaseerd, wat geweldig is. Maar ze hebben verschillende structuren. Je zult een transformer moeten schrijven:

function contentfulRichTextToPortableText(richTextField) {
  return richTextField.content.map(node => {
    switch (node.nodeType) {
      case 'paragraph':
        return {
          _type: 'block',
          style: 'normal',
          children: node.content.map(mapInlineContent),
        }
      case 'heading-2':
        return {
          _type: 'block',
          style: 'h2',
          children: node.content.map(mapInlineContent),
        }
      case 'embedded-entry-block':
        // Map naar je aangepaste Portable Text type
        return mapEmbeddedEntry(node)
      // ... handle all node types
    }
  }).filter(Boolean)
}

Content Type naar Schema mapping

Contentful content types mappen vrij direct naar Sanity document en object types. De grootste verschuiving is dat Sanity schemas in code zijn gedefinieerd (JavaScript/TypeScript), niet in een web UI. Dit is eigenlijk een enorm voordeel — je content model zit in versiebeheer.

Gebruik de Contentful Management API om je content model te exporteren, schrijf dan een script dat Sanity schema files genereert:

contentful space export --space-id YOUR_SPACE_ID --export-dir ./export

Realistische tijdlijn

Voor een Contentful space met 10-20 content types en 5.000-10.000 entries: 3-5 weken. Het is sneller omdat je al in structured content denkt.

Drupal naar Sanity-migratie

Drupal migraties zijn degene die me een tweede koffie doen inschenken. Niet omdat Drupal slecht is — het is een krachtig systeem. Maar Drupal sites zijn meestal oud, volledig aangepast, en draaien op infrastructuur die niemand volledig begrijpt.

De Drupal-specifieke uitdagingen

  • Content types met 50+ velden: Drupal maakt het makkelijk om velden toe te voegen. Te makkelijk. Ik heb content types gezien met 80 velden, de helft waarvan ongebruikt is.
  • Taxonomy term referenties: Drupal's taxonomiesysteem is flexibel maar kan diep geneste hiërarchieën creëren die voor Sanity moeten worden afgevlakt.
  • Paragraphs module: Als de site Drupal Paragraphs gebruikt (en de meeste moderne Drupal sites doen dat), wordt elk paragraph type een Portable Text bloktype of Sanity object. Dit is de grootste enkele taak.
  • Media entities: Drupal 9/10's mediasysteem is complexer dan WordPress's. Meerdere mediatypes, herbruikbare media entities en file field configuraties moeten allemaal worden gemapt.
  • Meertalige content: Drupal's vertalingssysteem is geavanceerd. Sanity heeft geen ingebouwde lokalisatie op hetzelfde niveau — je hebt de @sanity/document-internationalization plugin nodig of een veld-niveau aanpak.

Migratieaanpak

Ik geef de voorkeur aan het gebruik van Drupal's JSON:API module (inbegrepen in Drupal core sinds 9.x) als de extractielaag:

async function fetchDrupalContent(type, page = 0) {
  const limit = 50
  const offset = page * limit
  const url = `${DRUPAL_URL}/jsonapi/node/${type}?page[limit]=${limit}&page[offset]=${offset}&include=field_image,field_paragraphs`

  const res = await fetch(url, {
    headers: { Authorization: `Basic ${DRUPAL_AUTH}` },
  })
  return res.json()
}

Voor oudere Drupal 7 sites zonder JSON:API, moet je mogelijk rechtstreeks de database bevragen. Drupal 7's databaseschema is... een ervaring. De field_data_* tabellen zullen je dromen achtervolgen.

Realistische tijdlijn

Drupal migraties variëren sterk. Een eenvoudige Drupal 10 site met 5-10 content types: 5-8 weken. Een legacy Drupal 7 site met 30+ content types, Paragraphs en meertalige content: 8-16 weken. Ik overdrijf niet.

Content modellering: je schemas goed krijgen

Hier is wat de meeste migratiegidsen je niet zullen vertellen: replicate je oude content model niet één-op-één in Sanity. Dit is je kans om jaren opgelopen content schulden op te ruimen.

Veel gemaakte modelleringsfouten

  1. Een 1:1 veldmapping creëren: Alleen omdat WordPress een "subtitle" aangepast veld had, wil dat niet zeggen dat Sanity er één nodig heeft. Misschien zou het deel moeten zijn van een gestructureerd "hero" object.
  2. Objects te diep nesten: Sanity laat je objects diep nesten. Weersta de drang. Flat-ish schemas zijn makkelijker om met GROQ te bevragen en makkelijker voor editors om mee te werken.
  3. Portable Text's kracht negeren: Dump HTML niet zomaar in een enkel tekstveld. Ontwerp aangepaste bloktypen die je content patronen passen. Een "callout" blok, een "code snippet" blok, een "image met caption" blok — deze maken editors het leven beter.

Schemaontwerp proces

Ik volg deze volgorde:

  1. Controleer bestaande content (gedaan in pre-migratie)
  2. Identificeer de werkelijke content patronen (niet wat de CMS oplegde)
  3. Ontwerp schemas op papier/whiteboard eerst
  4. Bouw schemas in code
  5. Importeer een kleine test batch (50-100 items)
  6. Laat editors de Studio ervaring testen
  7. Herhaal schemas voordat je volledig gaat migreren

Stappen 5-7 zijn kritiek en worden vaak overgeslagen. We hebben meer geschreven over content modelleringsbenaderingen in ons headless CMS development werk.

Data migratiestrategieën en tooling

Essentiële tools

  • @sanity/client: De officiele JavaScript client voor het lezen/schrijven van Sanity data
  • @sanity/block-tools: Zet HTML om in Portable Text
  • sanity dataset import/export: CLI tools voor volledige dataset operaties
  • ndjson: Sanity gebruikt newline-delimited JSON voor imports — zorg dat je ermee vertrouwd bent
  • jsdom of htmlparser2: Voor HTML parsing tijdens rich text omzetting

Migratiearchitectuur

Ik structureer elke migratie als een pijplijn met vier fasen:

Extract → Transform → Load → Validate

Elke fase is een apart script. Dit is belangrijk omdat je de migratie meerdere keren zult uitvoeren — meestal 5-10 keer voordat de uiteindelijke productie run. Met afzonderlijke fasen kun je alleen de delen opnieuw uitvoeren die moeten worden opgelost.

# Extract
node scripts/extract-wordpress.js > data/raw-posts.ndjson

# Transform
node scripts/transform-posts.js < data/raw-posts.ndjson > data/sanity-posts.ndjson

# Load
sanity dataset import data/sanity-posts.ndjson production --replace

# Validate
node scripts/validate-migration.js

Assets verwerken

Afbeeldingen en bestanden zijn altijd het langzaamste deel. Sanity's asset pipeline is goed, maar het uploaden van 10.000 afbeeldingen kost tijd. Tips:

  • Upload assets eerst, behoud een mapping van oude URLs naar nieuwe Sanity asset ID's
  • Gebruik gelijktijdige uploads (maar respecteer snelheidslimieten — 25 req/sec voor het Growth plan)
  • Verifieer afbeeldingsdimensies en formaten voor upload
  • Migreer geen thumbnailgrootten — Sanity genereert deze on-the-fly via zijn afbeeldings CDN

De verborgen kosten waarover niemand spreekt

Laat me eerlijk met je zijn over kosten die niet in de typische migratieofferte voorkomen.

URL-omleidingen

Als je je frontend wijzigt (wat je waarschijnlijk doet als je naar een headless CMS gaat), heb je URL-omleiding nodig. Elke. Enkele. URL. Voor SEO is dit niet onderhandelbaar. Een site met 5.000 pagina's heeft 5.000 omleidingsregels nodig. Tools zoals next.config.js omleidingen of Vercel's _redirects bestand kunnen dit aan, maar iemand moet de mapping bouwen.

SEO metadata migratie

Yoast SEO data van WordPress. Metatag module data van Drupal. Contentful's SEO velden. Dit alles moet worden overgebracht. Aangepaste meta titels, beschrijvingen, Open Graph afbeeldingen, canonieke URLs, structured data — het is een project binnen het project.

Editor training en documentatie

Budget 2-4 dagen minimum. Sanity Studio is intuïtief, maar het verschilt van wat je editors kennen. We maken meestal aangepaste Studio documentatie met screenshots en nemen 3-5 walkthrough video's op.

Frontend development

Dit is de olifant in de kamer. Content naar Sanity migreren is slechts de helft van het project. Je hebt ook een frontend nodig die de content gebruikt. Of je Next.js, Astro of ander framework gebruikt, de frontend build is vaak 50-70% van de totale projectkosten. Bekijk ons werk met Next.js en Astro als je frontend opties evalueert.

Tijdlijn en budgetvergelijking

Gebaseerd op projecten die we recent hebben voltooid:

Migratiepad Content volume Complexiteit Tijdlijn Budgetbereik
WordPress → Sanity < 1.000 pagina's Laag 3-5 weken €7K-€13K
WordPress → Sanity 1.000-10.000 pagina's Gemiddeld 6-10 weken €13K-€31K
WordPress → Sanity 10.000+ pagina's Hoog 10-16 weken €31K-€66K
Contentful → Sanity < 5.000 entries Laag-Gemiddeld 3-5 weken €6K-€16K
Contentful → Sanity 5.000-20.000 entries Gemiddeld 5-8 weken €16K-€35K
Drupal → Sanity < 2.000 nodes Gemiddeld 5-8 weken €10K-€22K
Drupal → Sanity 2.000-15.000 nodes Hoog 8-14 weken €22K-€53K
Drupal 7 → Sanity Elke Zeer hoog 10-20 weken €31K-€79K

Opmerking: Deze bereiken betreffen alleen content migratie. Frontend development is extra. Neem contact met ons op via /pricing voor projectspecifieke schattingen.

Deze getallen omvatten content modellering, migratiesript, data validatie en basis editor training. Ze omvatten geen frontend development, design of doorlopend onderhoud.

Post-migratiechecklist

Hier is de checklist die ik op elke migratie gebruik:

  • Alle content types gemigreerd en geverifieerd
  • Alle referenties/relaties intact
  • Alle afbeeldingen en bestanden geüpload en correct gekoppeld
  • Rich text content rendert correct (controleer op beschadigde opmaak)
  • URL-omleidingen op hun plaats en getest
  • SEO metadata gemigreerd (titels, beschrijvingen, OG data)
  • XML sitemap opnieuw gegenereerd
  • Search console bijgewerkt met nieuwe sitemap
  • Analytics tracking behouden
  • Editor accounts aangemaakt en permissies ingesteld
  • Editor training voltooid
  • Content preview (draft mode) werkend
  • Webhooks geconfigureerd voor build triggers
  • Backup van bron CMS data gearchiveerd
  • DNS wijzigingen gepland (indien van toepassing)
  • Prestatie baseline gemeten
  • 404 monitoring ingesteld voor eerste 30 dagen

Dat laatste punt is belangrijk. Hoe grondig je omleidingsmapping ook is, sommige URL's zullen erdoor glippen. Monitor je 404's agressief in de eerste maand.

Veelgestelde vragen

Hoe lang duurt een typische WordPress naar Sanity migratie? Voor een standaard WordPress site met onder de 2.000 posts en straightforward aangepaste velden, verwacht 4-8 weken. Dit omvat content modellering, migratiesript, data validatie en editor training. Sites met complexe Gutenberg blokken, WooCommerce of meertalige content kunnen 10-16 weken duren. Het content volume doet er minder toe dan de complexiteit van je content types.

Kan ik van Contentful naar Sanity migreren zonder data te verliezen? Ja, en het is eigenlijk het schoonste migratiepad van de drie die ik hier behandel. Beide platforms gebruiken gestructureerde, JSON-gebaseerde content dus de mapping is relatief direct. Rich text moet van Contentful's formaat naar Portable Text worden omgezet, en referenties moeten opnieuw worden gemapt, maar je mag geen data verliezen. Ik raad aan de migratie eerst tegen een staging dataset uit te voeren en een grondige content vergelijking te doen voordat je overschakelt.

Wat gebeurt er met mijn SEO-rankings tijdens een CMS-migratie? Dit is de vraag die marketing directors 's nachts wakker houdt. Als je omleidingen goed afhandelt, je URL-structuur waar mogelijk behoudt en alle SEO metadata migreert, zou je minimale impact moeten zien. Google's eigen documentatie zegt dat goed omgeleide migraties een tijdelijke daling van 2-4 weken kunnen zien voordat ze herstellen. Het sleutelwoord is "goed". Sla de omleidingsmapping over en je zult je rankings tanken. We hebben het zien gebeuren.

Is Sanity goedkoper dan Contentful voor enterprise gebruik? In de meeste gevallen ja — soms aanzienlijk. Sanity's Growth plan op €88/maand dekt wat je Contentful's €267/maand Team plan nodig zou hebben. Op enterprise schaal wordt het verschil groter. Contentful's Premium prijzen zijn niet openbaar, maar bedragen meestal €1.787-€3.574+/maand. Sanity Enterprise prijzen zijn ook aangepast, maar zijn over het algemeen lager voor gelijk gebruik. Het werkelijke kostenverschil zit in API-oproepen — Sanity's inbegrepen limieten zijn royaler.

Zou ik mijn Drupal 7 site naar Sanity moeten migreren of eerst upgraden naar Drupal 10? Ga rechtstreeks naar Sanity. Van Drupal 7 naar Drupal 10 migreren is bijna zoveel werk als migreren naar een ander CMS — de architectuur veranderde dat dramatisch tussen versies. Als je al in een grote migratie belegt, je net zo goed naar het platform kunnen gaan dat je op lange termijn wilt zijn. De ene uitzondering: als je team diep in het Drupal ecosysteem belegt is en alleen wil moderniseren, is Drupal 10 met een headless frontend een geldig pad.

Moet ik mijn frontend herbouwen bij migratie naar Sanity? Als je van een monolithische CMS zoals WordPress of Drupal komt, ja — je hebt een nieuwe frontend nodig omdat Sanity headless is. Dit is meestal het grotere deel van het project. Als je van Contentful komt, kun je je bestaande frontend vaak hergebruiken met gewijzigde API-oproepen, vooral als je al Next.js of soortgelijk framework gebruikt. We handelen zowel de CMS migratie als frontend builds als geïntegreerde projecten af.

Kan ik mijn oude CMS en Sanity parallel uitvoeren tijdens migratie? Absoluut, en ik raad het aan. Voer beide systemen 2-4 weken na je initiële migratie uit. Editors kunnen in het oude systeem blijven werken terwijl je data in Sanity valideert. Zorg ervoor dat je content in het oude systeem bevrijest voordat je uiteindelijke migratierun — je wilt geen bewegend doel achtervolgen. Sommige teams stellen een "content freeze" datum 48 uur voor de uiteindelijke cutover in.

Wat is de grootste fout die teams maken tijdens een Sanity migratie? Proberen hun oude CMS structuur exact in Sanity na te bootsen. Ik zie dit constant. Teams komen van WordPress en proberen WordPress-vormige schemas in Sanity te bouwen — generieke "page" types met flexibele layouts in plaats van doel-gebouwde content types. Sanity's kracht is gestructureerde content. Gebruik de migratie als een kans om je content goed te modelleren. Besteed een extra week aan content modellering. Het bespaart je maanden pijn later. Als je begeleiding hierover wilt, neem contact met ons op — content modellering is een van de dingen waar we het meeste tijd aan besteden in migratieprojecten.