Je development team opent de WordPress admin en exporteert 847 berichten, 12 aangepaste berichttypen en 3.200 media-assets. De databasedump is 4,2GB. Iemand vraagt hoe lang deze migratie eigenlijk duurt—niet de gepolijste schatting uit het kickoff-deck, maar de tijdlijn die rekening houdt met kapotte shortcodes, ACF-veldverschillen en de redirect-map die van 200 rijen naar 1.800 groeit tegen week twee. Ik heb meer dan 40 CMS-migraties in vijf jaar geleid, de meeste van WordPress naar Next.js. Het antwoord hangt af van vier variabelen die de meeste bureaus pas noemen als je al getekend hebt. Hier is wat werkelijk bepaalt of je in 3 weken of 6 maanden shipt.

Het ding is—het echte antwoord is bijna altijd langer dan je wilt, maar korter dan je ergste angsten. Een kleine marketingsite? Je kijkt naar 3-6 weken. Een mid-size bedrijf met een blog, e-commerce en aangepaste integraties? Plan in voor 2-4 maanden. Een enterprise met 10.000+ pagina's, meerdere locales en legacy-systemen? Zet je schrap voor 4-8 maanden.

Maar die ranges zijn betekenisloos zonder context. Laat me exact uitleggen wat er in elke fase gebeurt, waar teams tijd verliezen, en hoe je voorkomt dat je migratie een van die horrorverhalen wordt dat een jaar duurt.

Inhoudsopgave

CMS Migration Timeline: WordPress to Next.js in 2026

Waarom migreren van WordPress naar Next.js in 2026?

Wees direct: niet elke WordPress-site moet migreren. Als je een persoonlijke blog of een kleine bedrijfssite hebt die goed draait, is WordPress nog steeds volkomen geschikt. Maar er zijn echte, meetbare redenen waarom teams in 2026 naar Next.js met een headless CMS overstappen:

  • Performance: Next.js-sites met statische generatie en edge rendering scoren consistent 90+ op Core Web Vitals. WordPress-sites halen gemiddeld 50-65 zonder significante optimalisatie.
  • Beveiliging: Het ontkoppelen van de frontend van het CMS elimineert de meest voorkomende WordPress-aanvalsvectoren. In 2025 rapporteerde Sucuri dat WordPress 96,2% van geïnfecteerde CMS-sites vertegenwoordigde.
  • Ontwikkelaarservaring: React-gebaseerde componentenarchitectuur betekent snellere iteratie en eenvoudiger werving. De WordPress PHP-talentpool krimpt—Stack Overflow's 2025-enquête toonde PHP op plaats 14 in taalpopulariteit.
  • Schaalbaarheid: Edge-deployed Next.js-sites op Vercel of Cloudflare verwerken verkeerspieken zonder de benadering "laten we nog meer servers erbij zetten".

Als je te maken hebt met prestatieproblemen, veiligheidskwesties of een development team dat bang is om je WordPress-codebase aan te raken, heeft migratie zin. We behandelen de technische benadering uitgebreid op onze Next.js-ontwikkelingscapaciteiten pagina.

Migratietijdlijn overzicht per sitetype

Hier is de eerlijke uitsplitsing. Deze tijdlijnen gaan uit van een dedicated team (niet mensen die tijd delen met andere projecten) en redelijk responsieve stakeholders.

Sitetype Pagina's Typische complexiteit Tijdlijn Teamgrootte
Klein (Marketing/Brochure) 5-50 Laag — weinig integraties, standaardcontent 3-6 weken 2-3 personen
Gemiddeld (Bedrijf) 50-500 Gemiddeld — blog, formulieren, enkele integraties, meerdere templates 8-16 weken 3-5 personen
Groot (Midden-markt) 500-5.000 Hoog — e-commerce, multi-auteur, complexe workflows 3-5 maanden 4-7 personen
Enterprise 5.000+ Zeer hoog — meerdere locales, legacy-integraties, naleving 4-8 maanden 6-12 personen

Dit zijn bouwstijdlijnen, geen kalender-tijdlijnen. Kalender-tijd is altijd langer vanwege stakeholder-reviews, feedback-loops en de onvermijdelijke twee weken waarbij de VP of Marketing op vakantie is tijdens de design-goedkeuringsfase.

Fase 1: Discovery en audit

Duur: 1-3 weken

Hier haasten de meeste bureaus zich en gaan de meeste migraties fout. Discovery is niet zomaar "kijk naar de WordPress-site en maak een lijst." Het is forensisch werk.

Wat gebeurt er werkelijk

  • Content-inventaris: Catalogiseer elk inhoudstype, taxonomie, aangepast veld en media-asset. Ik gebruik Screaming Frog om de bestaande site te crawlen en een volledige URL-map te exporteren. Voor een site met 2.000 pagina's kost dit alleen al een hele dag om goed in te richten.
  • Plugin-audit: Documenteer elke actieve plugin en wat deze doet. De gemiddelde WordPress-site heeft 20-30 plugins. Elk vertegenwoordigt functionaliteit die je moet repliceren, vervangen door een SaaS-tool of opzettelijk moet loslaten.
  • Integratiekaart: Formulieren naar HubSpot? Betalingsverwerking via WooCommerce? Analytics via Google Tag Manager met aangepaste events? Teken het volledige plaatje.
  • SEO-baseline: Exporteer alle meta-titels, -beschrijvingen, canonieke URLs, gestructureerde gegevens en interne linkpatronen. Je kunt geen SEO-equity verliezen tijdens de migratie.
  • Gespreken met stakeholders: Praat met de mensen die het CMS dagelijks werkelijk gebruiken. Content editors, marketers, wie dan ook die de blog beheert. Hun workflows zijn belangrijker dan de technische architectuur.

Discovery-deliverables

  • Content model-document
  • Integratieafhankelijkheidskaart
  • SEO-migratieplan
  • Risicoregister (dingen die de tijdlijn kunnen verpesten)
  • Voorlopige architectuuraanbeveling

Discovery overslaan of haasten is de nummer één oorzaak van tijdlijnoverschrijdingen. Ik heb gezien dat een "snelle 6-wekse migratie" zich uitstrekte tot 5 maanden omdat niemand had gedocumenteerd dat de WordPress-site 47 aangepaste Gravity Forms had met conditionele logica die gegevens naar drie verschillende CRM's pijpte.

CMS Migration Timeline: WordPress to Next.js in 2026 - architecture

Fase 2: Architectuur en planning

Duur: 1-2 weken

Met discovery-gegevens in hand maak je de grote beslissingen.

Je headless CMS kiezen

Next.js is je frontend-framework, maar je hebt nog steeds een content management-backend nodig. De top-opties in 2026:

CMS Beste voor Prijs (2026) Leercurve
Sanity Complexe content-modellen, realtime samenwerking Gratis tier, daarna $99-$949/maand Gemiddeld
Contentful Enterprise-teams, sterke governance $300/maand en hoger Gemiddeld
Storyblok Visueel bewerken, marketing-teams Gratis tier, daarna €106-€399/maand Laag
Payload CMS Developer-first, zelf-gehost beheer Gratis (open source), Cloud vanaf €50/maand Hoger
WordPress (Headless) Teams die WordPress admin willen behouden Bestaande hosting-kosten Laag (vertrouwd)

Ja, je kunt WordPress als headless CMS gebruiken met WPGraphQL of de REST API. Sommige teams doen dit om hun content editors in een vertrouwde omgeving te houden terwijl ze Next.js op de frontend krijgen. Het is een geldige benadering, hoewel je wat WordPress-onderhoudslast erft.

We helpen teams deze opties te evalueren als onderdeel van ons headless CMS-ontwikkelings werk. De juiste keuze hangt sterk af van het technische comfort van je redactionele team.

Architectuurbeslissingen

  • Renderingstrategie: Static Site Generation (SSG), Incremental Static Regeneration (ISR) of Server-Side Rendering (SSR)? De meeste sites in 2026 gebruiken een hybride benadering — ISR voor content-pagina's, SSR voor gepersonaliseerde of real-time pagina's.
  • Hosting: Vercel is standaard voor Next.js, maar Netlify, Cloudflare Pages en AWS Amplify zijn allemaal haalbaar. Vercel's Pro-plan op $20/gebruiker/maand dekt de meeste teams.
  • API-architectuur: Gebruik je de native API van het CMS, bouw je een middleware-laag, of ga je met iets als tRPC voor type-veilige API-calls?
  • Authenticatie: Als je gated content of lidmaatschapsgebieden hebt, plan dit vroeg. NextAuth.js (nu Auth.js v5) handelt de meeste patronen af.

Fase 3: Content modeling en CMS-instellingen

Duur: 1-3 weken

Dit is waar je je content-structuur in het nieuwe CMS bouwt. Repliceer niet zomaar je WordPress-structuur — dit is je kans om jaren opgehoopte content-schuld op te lossen.

Content-modelontwerp

WordPress stimuleert een platte content-model: berichten, pagina's en een brij van aangepaste velden via ACF of Meta Box. Een headless CMS laat je nadenken in gestructureerde content.

// Voorbeeld: Blog Post content-model in Sanity
export default defineType({
  name: 'blogPost',
  title: 'Blog Post',
  type: 'document',
  fields: [
    defineField({
      name: 'title',
      type: 'string',
      validation: (Rule) => Rule.required().max(70),
    }),
    defineField({
      name: 'slug',
      type: 'slug',
      options: { source: 'title' },
    }),
    defineField({
      name: 'author',
      type: 'reference',
      to: [{ type: 'author' }],
    }),
    defineField({
      name: 'body',
      type: 'portableText', // Rich structured content
    }),
    defineField({
      name: 'seo',
      type: 'seoFields', // Reusable SEO object
    }),
  ],
})

Gestructureerde content betekent dat je blog post-body niet zomaar een HTMLblob is. Het zijn gestructureerde blokken die je frontend op elke gewenste manier kan renderen — web, mobiele app, e-mail newsletter, wat dan ook.

CMS-configuratie

  • Rollen en machtigingen instellen
  • Preview-functionaliteit configureren (live preview in Next.js is essentieel voor editor-adoptie)
  • Aangepaste input-componenten of validatieregels bouwen
  • Webhooks instellen voor herbygging bij content-wijzigingen

Fase 4: Frontend-opbouw

Duur: 2-8 weken (de grootste variabele)

Hier gaat het grootste deel van de kalender-tijd naar toe. De Next.js-frontend bouwen omvat:

Design en componentensysteem

Als je het ontwerp tijdens de migratie verandert (wat ongeveer 70% van onze klanten doet), voeg je 2-4 weken toe. Als je het bestaande ontwerp repliceert, kan je sneller gaan.

// Component-gestuurde architectuurvoorbeeld
export default function BlogPost({ post }: { post: BlogPostType }) {
  return (
    <article>
      <PageHeader title={post.title} date={post.publishedAt} />
      <AuthorCard author={post.author} />
      <PortableText 
        value={post.body} 
        components={customComponents} 
      />
      <RelatedPosts posts={post.related} />
      <NewsletterSignup />
    </article>
  )
}

Ik raad sterk aan om eerst een component-bibliotheek te bouwen, dan pagina's samen te stellen. Het voelt aanvankelijk langzamer, maar betaalt zich massaal uit als je je 15e pagina-template bouwt.

Belangrijkste bouwtaken

  • Paginatemplates voor elk inhoudstype
  • Dynamische routering en catch-all-routes
  • Navigatie (inclusief mega menu's, indien van toepassing)
  • Zoekfunctionaliteit (Algolia, Meilisearch of Next.js built-in)
  • Formulierimplementaties (ter vervanging van Gravity Forms, Contact Form 7, enz.)
  • Integraties van derden (analytics, chatwidgets, CRM-verbindingen)
  • Afbeeldingenoptimalisatie (Next.js Image component met je CMS's afbeeldings-CDN)
  • Sitemap-generatie
  • RSS-feeds
  • 301-redirect-mapping

De redirect-mapping alleen kan al dagen duren op een grote site. Elke URL die verandert heeft een redirect nodig, anders gooi je SEO-equity weg.

Fase 5: Content-migratie

Duur: 1-4 weken

Content-migratie is ofwel triviaal eenvoudig ofwel nachtmerrieachtig complex. Er is geen middenweg.

Geautomatiseerde migratie

Voor gestructureerde content (blogberichten, producten, teamleden) schrijf je migratiescrips:

// Vereenvoudigd WordPress naar Sanity-migratiescript
import { createClient } from '@sanity/client'
import { wpClient } from './wordpress-api'

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

async function migratePosts() {
  const wpPosts = await wpClient.posts().perPage(100).get()
  
  for (const post of wpPosts) {
    await sanity.create({
      _type: 'blogPost',
      title: post.title.rendered,
      slug: { current: post.slug },
      // Transform WordPress HTML to Portable Text
      body: htmlToPortableText(post.content.rendered),
      publishedAt: post.date,
    })
  }
}

De htmlToPortableText-stap is waar het harig wordt. WordPress-content zit vol shortcodes, inline-stijlen en plugin-specifieke markup die niet schoon naar gestructureerde content mappt. Plan tijd in voor opschoning.

Handmatig content-werk

Sommige content heeft gewoon menselijke aandacht nodig:

  • Pagina's met complexe layouts gebouwd in Elementor, Divi of WPBakery
  • Content met ingebedde shortcodes van gedeactiveerde plugins
  • Media die heropgeoptimaliseerd moet worden of alt-tekst nodig heeft
  • Interne links die moeten worden bijgewerkt

Voor een site met 500 pagina's plan je in voor 40-80 uur handmatig contentwerk. Ja, echt.

Fase 6: QA en testen

Duur: 1-3 weken

Beperk jezelf niet hier. Ik heb lanceringen zien vertragen met maanden omdat QA als een nagedachte werd behandeld.

QA-checklist

  • Functioneel testen: Elk formulier, elk interactief element, elke dynamische functie
  • Browsers-testen: Chrome, Firefox, Safari, Edge. Safari heeft altijd iets raars.
  • Mobiel testen: Echte apparaten, niet alleen Chrome DevTools. Test op echte iPhones en Android-apparaten.
  • Content-verificatie: Controleer op fouten in opmaak voor minstens 20% van gemigreerde content
  • SEO-audit: Vergelijk oude meta-tags met nieuwe. Controleer gestructureerde gegevens. Test alle redirects.
  • Performance-testen: Lighthouse-scores, Core Web Vitals in het veld, load-testen met tools als k6
  • Toegankelijkheid: WCAG 2.2 AA-naleving. Voer axe-core uit, maar doe ook keyboard-only navigatie-tests.
  • Analytics-verificatie: Zorg dat tracking correct afvuurt op alle events

Redirect-testen

Dit verdient zijn eigen aanpak. Exporteer elke URL van de oude site. Map elk naar zijn nieuwe URL. Test elke redirect. Voor enterprise-sites met duizenden URLs, gebruik geautomatiseerd testen:

# Test redirects with curl
while IFS=, read -r old_url new_url; do
  status=$(curl -o /dev/null -s -w "%{http_code}" -L "$old_url")
  final=$(curl -o /dev/null -s -w "%{url_effective}" -L "$old_url")
  echo "$old_url -> $final (Status: $status)"
done < redirects.csv

Fase 7: Launch en na-launch

Duur: 1-2 weken

Lanceringdag

Ik vind het fijn om op dinsdag of woensdag ochtend te lanceren. Nooit vrijdag (je wilt niet debuggen in het weekend) en nooit maandag (mensen halen nog steeds het weekend in).

Lancering-checklist:

  • DNS-wijzigingen (TTL moet 48 uur eerder worden verlaagd)
  • SSL-certificaatverificatie
  • CDN-cache opwarmen
  • Foutpercentages bewaken voor de eerste 4 uur
  • Google Search Console verifiëren voor crawlfouten
  • Controleer dat alle integraties van derden werken

Na-launch (2 weken)

  • Core Web Vitals bewaken in Google Search Console
  • 404-fouten controleren en ontbrekende redirects toevoegen
  • Organische zoekprestaties de eerste maand dagelijks volgen
  • Feedback van content editors verzamelen over het nieuwe CMS
  • Alle edge cases aanpakken die QA niet hebben opgepikt

Een tijdelijke traffic dip van 5-15% in organisch zoeken is normaal na een grote migratie. Het moet zich binnen 2-4 weken herstellen als je redirects en SEO goed zijn afgehandeld. Als het niet herstelt, is er iets fout gegaan met de redirect-mapping of content-pariteit.

Veelvoorkomende vertragingen en hoe ze te voorkomen

Na dozijnen migraties hier zijn de echte tijdlijnmoordenaars:

Scope creep tijdens opbouw: "Terwijl we toch bezig zijn, kunnen we ook een klantportal toevoegen?" Ja, maar dat is een apart project. Scope creep voegt gemiddeld 3-6 weken toe aan migraties.

Beschikbaarheid stakeholder: Design reviews die twee weken in iemands inbox zitten. Plan kalender-tijd in en stel duidelijke SLA's voor feedback-rondes.

Plugin-functionaliteitsgaten: Die obscure WordPress-plugin die iets kritiek doet dat niemand had gedocumenteerd. Discovery zou dit moeten opvangen, maar soms glipt het door.

Content editor-training: Als je team het nieuwe CMS niet kan gebruiken, ben je niet klaar met migratie. Plan 1-2 dagen in voor training en documentatie.

Perfectionism op content-migratie: Sommige content is niet waard om te migreren. Blogberichten van 2014 met nul traffic? Laat ze gaan. Zet een redirect naar de blog-index en ga verder.

Kostenexpectaties voor 2026

Laat me je eerlijke nummers geven. Bureautariefen voor dit werk in 2026:

Sitetype Tijdlijn Geschatte kosten (Bureau) Geschatte kosten (Freelancer)
Klein 3-6 weken $15.000-$35.000 $8.000-$18.000
Gemiddeld 8-16 weken $40.000-$90.000 $25.000-$55.000
Groot 3-5 maanden $80.000-$200.000 $50.000-$120.000
Enterprise 4-8 maanden $150.000-$500.000+ Zelden passend

Deze ranges weerspiegelen wat we op de markt hebben gezien. De variantie is enorm omdat "gemiddelde site" heel verschillende dingen kan betekenen. Een 200-pagina-site met een eenvoudige blog en contactformulier is heel anders dan een 200-pagina-site met meertalige content, e-commerce en een lidmaatschapsportaal.

Als je je specifieke situatie wilt bespreken, schetst onze prijspagina onze engagement-modellen, of je kunt direct contact opnemen voor een scoped offerte.

Veelgestelde vragen

Hoe lang duurt een eenvoudige WordPress naar Next.js-migratie? Een kleine marketingsite (onder de 50 pagina's) met standaard content-types en minimale integraties duurt meestal 3-6 weken van start tot lancering. Dit gaat ervan uit dat een team van 2-3 developers zonder grote designwijzigingen werkt. Als je ook herontwerpt, voeg je 2-3 weken toe voor de design-fase.

Kan ik WordPress naar Next.js migreren zonder SEO-rankings kwijt te raken? Absoluut, maar het vereist zorgvuldige planning. De kritieke elementen zijn: URL-structuren waar mogelijk behouden, 301-redirects implementeren voor gewijzigde URL's, alle meta-tags en gestructureerde gegevens behouden, en zorgen dat de nieuwe site content-pariteit heeft met de oude. Een tijdelijke dip van 5-15% in organisch traffic is normaal en moet zich binnen 2-4 weken herstellen. De grootste risicofactor is ontbrekende redirects — een verprutste redirect-mapping kan een sectie van je site's traffic omgooien.

Moet ik WordPress als headless CMS met Next.js gebruiken of volledig naar een ander CMS overstappen? Het hangt af van je team. Als je content editors diep vertrouwd zijn met WordPress en weerstand tegen verandering tonen, is headless WordPress met WPGraphQL een redelijk middelpunt. Je krijgt de Next.js frontend-voordelen terwijl je de vertrouwde admin-interface behoudt. Echter, je draagt nog steeds WordPress's onderhoudslast (updates, beveiligingspatches, hosting). Als je open voor verandering bent, purpose-built headless CMS'en als Sanity, Contentful of Storyblok bieden betere gestructureerde content, realtime samenwerking en minder operationele overhead.

Wat zijn de grootste risico's tijdens een CMS-migratie? De top drie zijn: SEO-regressie door slechte redirect-mapping (oplosbaar maar duur in verloren traffic), tijdlijnoverschrijding door inadequate discovery (meestal omdat verborgen complexiteit halverwege de opbouw naar boven komt), en editor-adoptie mislukking (je team weigert het nieuwe CMS te gebruiken omdat het te anders is of niet met hun workflows is gebouwd). Alle drie zijn voorkoombaar met goede planning.

Hoeveel kost het om van WordPress naar Next.js in 2026 te migreren? Bureaukosten variëren van $15.000 voor een kleine brochuresite tot $500.000+ voor grote enterprise-migraties met complexe integraties. De mediaanprijs voor mid-size bedrijven is ongeveer $50.000-$90.000 bij een gespecialiseerd bureau. Freelancer-tarieven zijn meestal 40-60% lager maar komen met hoger risico rond beschikbaarheid en projectmanagement. De kosten worden primair aangestuurd door het aantal unieke templates, integratie-complexiteit en het volume content dat handmatige aandacht nodig heeft.

Moet ik al mijn content tegelijk migreren? Nee, en eigenlijk is een gefaseerde migratie vaak lager risico. Sommige teams verplaatsen eerst hun marketingpagina's naar Next.js terwijl de blog op WordPress blijft, migreren dan de blog in een tweede fase. Je kan reverse proxy-regels gebruiken om verschillende secties van verschillende oorsprongen onder dezelfde domein te serveren. Deze benadering voegt wat architecturale complexiteit toe maar laat je sneller lanceren en valideert de benadering voordat je all-in gaat.

Wat is het verschil tussen een replatform en een herontwerp? Een replatform verplaatst het ontwerp en de content van je bestaande site naar nieuwe technologie (WordPress naar Next.js) met minimale visuele wijzigingen. Een herontwerp verandert het uiterlijk, gevoel en mogelijk de informatieachitectuur. Het combineren van beide in één project is gewoon, maar voegt 30-50% aan de tijdlijn toe. Als budget of tijdlijn krap is, raad ik aan eerst te replatformen, dan iteratief herontwerpen zodra je op de nieuwe stack zit.

Kan ik in plaats van Next.js Astro gebruiken voor mijn migratie? Ja, en voor content-zware sites met minimale interactiviteit kan Astro een uitstekende keuze zijn. Astro verstuurt standaard nul JavaScript en ondersteunt partiële hydratatie ("islands architecture"), wat betekent dat je content-pagina's ongelooflijk snel laden. Next.js is beter als je zware client-side interactiviteit, authenticatie of real-time functies nodig hebt. We hebben migraties naar beide frameworks gedaan, en de juiste keuze hangt geheel af van je site-vereisten.