Ik heb de afgelopen vijf jaar ongeveer 40 CMS-migraties geleid, en de vraag die ik vaker krijg dan welke andere ook is: "Hoe lang gaat dit werkelijk duren?" Niet de verkopersversie. Het echte antwoord.

Hier is het ding -- het echte antwoord is bijna altijd langer dan je wilt, maar korter dan je ergste nachtmerries. Een kleine marketingsite? Je kijkt tegen 3-6 weken aan. Een middelgroot bedrijf met een blog, e-commerce en custom integraties? Plan voor 2-4 maanden. Een onderneming met 10.000+ pagina's, meerdere lokalisaties en legacy-systemen? Zet je schrap voor 4-8 maanden.

Maar deze reeksen betekenen niets zonder context. Ik zal exact uitleggen wat er in elke fase gebeurt, waar teams tijd verliezen, en hoe je migratie je kunt voorkomen dat het een van die horrorgeschiedenissen wordt die zich over een jaar uitstrekt.

Inhoudsopgave

CMS-migratietijdlijn: WordPress naar Next.js in 2026

Waarom migreren van WordPress naar Next.js in 2026?

Laat me duidelijk zijn: niet elke WordPress-site hoeft te migreren. Als je een persoonlijk blog of een kleine bedrijfssite runt die goed presteert, is WordPress nog steeds volkomen geschikt. Maar er zijn werkelijke, meetbare redenen waarom teams in 2026 naar Next.js met een headless CMS overstappen:

  • Prestaties: Next.js-sites met statische generatie en edge-rendering scoren consistent 90+ op Core Web Vitals. WordPress-sites gemiddeld rond de 50-65 zonder aanzienlijk optimalisatiewerk.
  • Veiligheid: Het ontkoppelen van de frontend van het CMS elimineert de meest voorkomende WordPress-aanvalsvectoren. In 2025 rapporteerde Sucuri dat WordPress 96,2% van de besmette CMS-sites vertegenwoordigt.
  • Ontwikkelaars ervaring: Op React gebaseerde componentarchitectuur betekent snellere iteratie en makkelijker aanwerven. De WordPress PHP-talentpool krimpt -- Stack Overflow's 2025-enquête toonde PHP dalend naar 14e in taalpopulariteit.
  • Schaalbaarheid: Next.js-sites die aan de rand zijn geïmplementeerd op Vercel of Cloudflare verwerken verkeerspieken zonder de benadering 'laten we meer server toevoegen'.

Als je te maken hebt met prestatieproblemen, veiligheidsproblemen of een dev-team dat zich doodschrikt voor het aanraken van je WordPress-codebase, heeft migratie zin. We behandelen de technische benadering in detail op onze Next.js-ontwikkelingsmogelijkhedenpagina.

Migratietijdlijn overzicht op grootte van site

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

Sitegroootte Pagina's Typische complexiteit Tijdlijn Teamgrootte
Klein (Marketing/brochure) 5-50 Laag -- enkele integraties, standaardinhoud 3-6 weken 2-3 personen
Gemiddeld (Bedrijf) 50-500 Gemiddeld -- blog, formulieren, enkele integraties, meerdere sjablonen 8-16 weken 3-5 personen
Groot (mid-market) 500-5.000 Hoog -- e-commerce, meerdere auteurs, complexe workflows 3-5 maanden 4-7 personen
Bedrijfsbreed 5.000+ Zeer hoog -- meerdere lokalisaties, legacy-integraties, compliance 4-8 maanden 6-12 personen

Dit zijn buildtijdlijnen, geen kalendertijdlijnen. Kalendertijd is altijd langer vanwege stakeholder reviews, feedbacklussen, en de onvermijdelijke twee weken waarin de VP Marketing op vakantie is tijdens de designgoedkeuringsfase.

Fase 1: Ontdekking en audit

Duur: 1-3 weken

Dit is waar de meeste bureaus haast maken en de meeste migraties mis gaan. Ontdekking is niet alleen "kijk naar de WordPress-site en maak een lijst". Het is forensisch werk.

Wat er werkelijk gebeurt

  • Content-inventaris: Catalogiseer elk inhoudstype, taxonomie, custom field en media-asset. Ik gebruik Screaming Frog om de bestaande site te crawlen en een volledige URL-kaart te exporteren. Voor een site met 2.000 pagina's kost dit alleen al minstens een volledige dag om goed in te ordenen.
  • Plugin-audit: Documenteer elke actieve plugin en wat deze doet. De gemiddelde WordPress-site heeft 20-30 plugins. Elk ervan vertegenwoordigt functionaliteit die je moet repliceren, vervangen door een SaaS-tool, of bewust moet laten vallen.
  • Integratiemapping: Formulieren gaan naar HubSpot? Betalingsverwerking via WooCommerce? Analyses via Google Tag Manager met custom events? Teken het volledige plaatje.
  • SEO-baseline: Exporteer alle metatitels, beschrijvingen, canonieke URL's, gestructureerde data en interne linkpatronen. Je kunt het niet permitteren SEO-waarde tijdens migratie kwijt te raken.
  • Stakeholder-interviews: Praat met de mensen die dagelijks het CMS gebruiken. Content editors, marketeers, wie dan ook die de blog beheert. Hun workflows zijn belangrijker dan de technische architectuur.

Leverables voor ontdekking

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

Het overslaan of haastig behandelen van ontdekking is de nummer één oorzaak van tijdlijnblokkering. Ik heb gezien dat een "snelle 6-weeksmigratie" een 5-maandse nachtmerrie werd omdat niemand had gedocumenteerd dat de WordPress-site 47 custom Gravity Forms had met conditionele logica die gegevens naar drie verschillende CRM's pipete.

CMS-migratietijdlijn: WordPress naar Next.js in 2026 - architectuur

Fase 2: Architectuur en planning

Duur: 1-2 weken

Met ontdekkingsgegevens in hand maak je de grote beslissingen.

Je headless CMS kiezen

Next.js is je frontendframework, maar je hebt nog steeds een content management backend nodig. De topkeuzes in 2026:

CMS Ideaal voor Prijzen (2026) Leercurve
Sanity Complexe content models, real-time samenwerking Gratis tier, daarna €99-€949/mnd Gemiddeld
Contentful Enterprise teams, sterke governance €300/mnd en hoger Gemiddeld
Storyblok Visuele editing, marketing teams Gratis tier, daarna €106-€399/mnd Laag
Payload CMS Developer-first, self-hosted controle Gratis (open source), Cloud vanaf €50/mnd Hoger
WordPress (Headless) Teams die WordPress admin willen behouden Bestaande hosting kosten Laag (bekend)

Ja, je kunt WordPress gebruiken als headless CMS 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 erfde WordPress-onderhoudslast.

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

Architectuurbeslissingen

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

Fase 3: Content modellering en CMS-instelling

Duur: 1-3 weken

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

Content model design

WordPress neigt naar het aanmoedigen van een platte content model: posts, pagina's en een puinhoop van custom fields via ACF of Meta Box. Een headless CMS laat je in gestructureerde content denken.

// 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 alleen een HTML-blob is. Het is gestructureerde blokken die je frontend naar wens kan renderen -- web, mobiele app, e-mailnieuwsbrief, wat dan ook.

CMS-configuratie

  • Rollen en machtigingen instellen
  • Voorbeeldfunctionaliteit configureren (live preview in Next.js is essentieel voor editor-adoptie)
  • Aangepaste invoercomponenten of validatieregels bouwen
  • Webhooks instellen voor het activeren van herstellingen bij contentveranderingen

Fase 4: Frontend-build

Duur: 2-8 weken (de grootste variabele)

Dit is waar het meeste van de kalendertijd heen gaat. De Next.js frontend bouwen omvat:

Ontwerp en componentensysteem

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

// Component-driven architecture voorbeeld
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 eerst een componentenbibliotheek te bouwen, vervolgens pagina's in te stellen. Het voelt aanvankelijk langzamer, maar betaalt zich massaal uit als je je 15de paginasjabloon bouwt.

Belangrijkste buildtaken

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

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

Fase 5: Content-migratie

Duur: 1-4 weken

Content-migratie is ofwel triviaal eenvoudig ofwel een nachtmerrie. Er is geen grijze zone.

Geautomatiseerde migratie

Voor gestructureerde content (blog posts, producten, teamleden), schrijf migratierscripts:

// Vereenvoudigd WordPress naar Sanity migratierscript
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 zaken ingewikkelder worden. WordPress-content zit vol met shortcodes, inline styles en plugin-specifieke markup die niet schoon toewijzen aan gestructureerde content. Begroting tijd voor opschoning.

Handmatig contentwerk

Sommige content verdient gewoon menselijke aandacht:

  • Pagina's met complexe layouts gebouwd in Elementor, Divi, of WPBakery
  • Content met embedded shortcodes van gedeactiveerde plugins
  • Media die opnieuw moet worden geoptimaliseerd of alternatieve tekst nodig heeft
  • Interne links die moeten worden bijgewerkt

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

Fase 6: QA en testen

Duur: 1-3 weken

Offroad geen QA. Ik heb launches gezien die maanden werden vertraagd omdat QA als een achteraf werd behandeld.

QA-checklist

  • Functionaal testen: Elk formulier, elk interactief element, elke dynamische functie
  • Cross-browser 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 willekeurig minstens 20% van gemigreerde content op opmaakproblemen
  • SEO audit: Vergelijk oude metatags met nieuwe. Controleer gestructureerde data. Test alle redirects.
  • Prestatietesten: 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 enkel-toetsenbordnavigatie testen.
  • Analytics-verificatie: Zorg ervoor dat tracking op alle evenementen correct afvuurt

Redirect-testen

Dit verdient eigen callout. Exporteer elke URL van de oude site. Koppel elk naar zijn nieuwe URL. Test elke redirect. Voor enterprise sites met duizenden URL's, gebruik geautomatiseerd testen:

# Test redirects met 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 de launch

Duur: 1-2 weken

Launchdag

Ik geef de voorkeur aan starten op een dinsdag of woensdagochtend. Nooit vrijdag (je wilt niet debuggen in een weekend) en nooit maandag (mensen halen nog steeds het weekend in).

Launch-checklist:

  • DNS-wijzigingen (TTL moet 48 uur voor worden verlaagd)
  • SSL-certificaatverificatie
  • CDN-cache warming
  • Foutpercentages de eerste 4 uur bewaken
  • Verificatie van Google Search Console voor crawlfouten
  • Check alle integraties van derden werken

Na de launch (2 weken)

  • Bewaak Core Web Vitals in Google Search Console
  • Kijk naar 404-fouten en voeg ontbrekende redirects toe
  • Volg dagelijks organische zoekprestaties de eerste maand
  • Verzamel feedback van content editors over de nieuwe CMS
  • Adresseer alle randgevallen die door QA glippen

Een tijdelijk verkeersdalingen 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 correct zijn afgehandeld. Zo niet, dan is er iets fout met de redirect-mapping of content-pariteit.

Veelvoorkomende vertragingen en hoe deze te vermijden

Na tientallen migraties zijn hier de echte tijdlijnmoordenaars:

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

Beschikbaarheid stakeholders: Designreviews die twee weken in iemands inbox zitten. Budget kalendertijd dienovereenkomstig in en stel duidelijke SLA's voor feedbackrondes in.

Functionaliteitsgaten plugins: Die obscure WordPress-plugin die iets kritisch doet dat niemand heeft gedocumenteerd. Ontdekking zou dit moeten opvangen, maar soms glippen dingen weg.

Content editor training: Als je team het nieuwe CMS niet kan gebruiken, heb je de migratie niet voltooid. Budget 1-2 dagen voor training en documentatie.

Perfectie op content-migratie: Sommige content verdient geen migratie. Blogposts van 2014 met nul verkeer? Laat ze gaan. Stel een redirect naar de blog-index in en ga verder.

Kostenexpectaties voor 2026

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

Sitegroootte 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
Bedrijfsbreed 4-8 maanden €150.000-€500.000+ Zelden passend

Deze bereiken weerspiegelen wat we over de markt hebben gezien. De variantie is enorm omdat "middelgrote site" zeer verschillende dingen kan betekenen. Een 200-pagina-site met een eenvoudige blog en contactformulier verschilt sterk van een 200-pagina-site met meertalige content, e-commerce en een ledenportaal.

Als je je specifieke situatie wilt bespreken, schetsen onze prijspagina onze engagement modellen, of je kunt rechtstreeks contact opnemen voor een scoped estimate.

Veelgestelde vragen

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

Kan ik WordPress naar Next.js migreren zonder SEO-rankings kwijt te raken? Absoluut, maar het vereist zorgvuldige planning. De kritieke elementen zijn: behoud van URL-structuren waar mogelijk, implementatie van 301 redirects voor URL's die veranderen, behoud van alle metatags en gestructureerde data, en ervoor zorgen dat de nieuwe site content parity met de oude heeft. Een tijdelijke dip van 5-15% in organisch verkeer is normaal en moet zich binnen 2-4 weken herstellen. De grootste risicofactor is gemiste redirects -- één verpeste redirect-mapping kan een sectie van je site's verkeer omvergooid.

Moet ik WordPress als headless CMS met Next.js gebruiken of volledig overstappen naar een ander CMS? Het hangt van je team af. Als je content editors diepgaand bekend zijn met WordPress en tegen verandering verzetten, is headless WordPress met WPGraphQL een redelijk middenpad. Je krijgt voordelen van de Next.js frontend terwijl je de vertrouwde admin-interface behoudt. Echter, je draagt nog steeds WordPress's onderhoudslast (updates, beveiligingspatches, hosting). Als je open staat voor verandering, bieden doelgerichte headless CMS-en als Sanity, Contentful, of Storyblok betere gestructureerde content, real-time 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 (herstelbaar maar kostbaar in verloren verkeer), tijdlijnblokkering door ontoereikende ontdekking (meestal omdat verborgen complexiteit halverwege build oppervlakt), en editor-adoptie falen (je team weigert het nieuwe CMS te gebruiken omdat het te anders is of niet met hun workflows werd 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 mediaan voor middelgrote businessites is ongeveer €50.000-€90.000 bij een gespecialiseerd bureau. Freelancertarieven zijn meestal 40-60% lager maar brengen hoger risico rond beschikbaarheid en projectmanagement. De kosten worden primair aangestuurd door het aantal unieke sjablonen, integratie complexiteit en volume content die handmatige aandacht nodig heeft.

Moet ik al mijn content in één keer migreren? Nee, en in feite vermindert een gefaseerde migratie vaak risico. Sommige teams beginnen met het verplaatsen van hun marketingpagina's naar Next.js terwijl de blog op WordPress blijft, en migreren de blog vervolgens in een tweede fase. Je kunt reverse proxy-regels gebruiken om verschillende secties vanaf verschillende oorsprongen onder dezelfde domein te serveren. Deze benadering voegt enige architecturische complexiteit toe, maar laat je sneller starten en de benadering valideren voordat je helemaal gaat.

Wat is het verschil tussen een replatform en een redesign? Een replatform verplaatst het ontwerp en de content van je bestaande site naar nieuwe technologie (WordPress naar Next.js) met minimale visuele veranderingen. Een redesign wijzigt het uiterlijk, gevoel en mogelijk de informatiestructuur. Het combineren van beide in één project is gangbaar maar voegt 30-50% toe aan de tijdlijn. Heeft budget of tijdlijn beperkingen, dan raad ik aan eerst replatform, daarna iteratief redesign zodra je op de nieuwe stack bent.

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 shipped nul JavaScript standaard en ondersteunt gedeeltelijke hydratatie ("islands architecture"), wat betekent dat je content pagina's ongelooflijk snel laden. Next.js is beter wanneer je zware client-side interactiviteit, authenticatie, of real-time functies nodig hebt. We hebben migraties naar beide frameworks uitgevoerd, en de juiste keuze hangt volledig af van je site's requirements.