Ik heb meer dan een dozijn WordPress-sites naar Next.js in productie gemigreerd, en ik ga je iets vertellen dat je misschien verrast: de eigenlijke code migratie is niet het moeilijkste deel. Het is de omschakeling. Dat beangstigende moment waarop je de schakelaar omdraait en hoopt dat niets breekt. Het goede nieuws? Met het juiste playbook kun je dat moment saai maken. En in operations is saai precies wat je wilt.

Dit is het playbook dat we bij Social Animal gebruiken voor productie-omschakelingen. Het is niet theoretisch — het is gebaseerd op echte migraties waar echt inkomsten op het spel stonden. We hebben het over e-commerce sites die $50K/dag doen, content publishers met miljoenen maandelijkse paginaweergaven, en SaaS-marketingsites waar 5 minuten downtime betekent dat de CEO je mobiele telefoon belt.

Inhoudsopgave

Zero Downtime CMS Migration: WordPress to Next.js Cutover Playbook

Waarom zero downtime meer uitmaakt dan je denkt

Laten we hier enkele cijfers op plaatsen. Onderzoek van Google uit 2024 toont aan dat een vertraging van 1 seconde in paginalaadtijd ongeveer 7% van conversies kost. Stel je nu voor dat je site gewoon... weg is. Zelfs maar voor 5 minuten.

Dit is eigenlijk wat op het spel staat:

Downtimetijd Inkomstenverlies (voor $10K/dag site) SEO-impact Gebruikersverwachtingen impact
5 minuten ~$35 verloren Minimaal als geïsoleerd Laag
30 minuten ~$208 verloren Googlebot kan het opmerken Gemiddeld
2 uur ~$833 verloren Crawlfouten in GSC Hoog
24 uur $10.000+ verloren Deïndeceringrisico Ernstig

Maar het gaat niet alleen om inkomsten. Zoekmachines crawlen constant. Als Googlebot je site bereikt tijdens een migratie en krijgt 500-fouten, kunnen die URL's binnen uren uit de index verdwijnen. Ik heb sites gezien die 40% van hun organisch verkeer verloren omdat iemand een "snelle migratie" over de lunch deed.

Het doel is niet alleen zero downtime. Het is geen zichtbare verandering voor gebruikers en crawlers tijdens de overgang.

Architectuuroverzicht van de migratie

Voordat we de fasen ingaan, kijken we naar de architectuur waar we naar toe werken. Het fundamentele patroon is beide systemen parallel uitvoeren en vervolgens het verkeer atomair verschuiven.

                    ┌─────────────────┐
                    │   Cloudflare /   │
                    │   Load Balancer  │
                    └────────┬────────┘
                             │
                    ┌────────┴────────┐
                    │  Traffic Router  │
                    │  (weight-based)  │
                    └────┬───────┬────┘
                         │       │
              ┌──────────┴──┐ ┌──┴──────────┐
              │  WordPress  │ │   Next.js   │
              │  (Blue)     │ │   (Green)   │
              │  Origin     │ │   op Vercel │
              └──────────┬──┘ └──┬──────────┘
                         │       │
              ┌──────────┴──┐ ┌──┴──────────┐
              │  MySQL DB   │ │ Headless CMS │
              │             │ │ (Sanity/etc) │
              └─────────────┘ └─────────────┘

Het sleutelopsicht: je migreert niet alleen een frontend. Je migreert de content-laag, de rendering-laag, en de delivery-laag — en elk ervan kan onafhankelijk gemigreerd worden.

Fase 1: Content migratie en API-laag

Dit is waar de meeste teams het verkeerd doen. Ze proberen eerst het Next.js-frontend te bouwen en later uit te zoeken waar de content vandaan komt. Doe dit niet. Begin met de content.

Je headless CMS kiezen

Je WordPress-content heeft een nieuw thuis nodig. De keuze maakt veel uit voor migratiecomplexiteit:

CMS Migratiegemak van WP Real-time sync mogelijk Prijzen (2025) Beste voor
Sanity Hoog (gestructureerde content map goed) Ja, via webhooks Gratis tier, daarna $99/mnd Complexe content-modellen
Contentful Gemiddeld (veldtoewijzing vereist) Ja $300/mnd voor Team Bedrijfsteams
Strapi Hoog (vergelijkbaar databasegestuurde model) Ja Zelf gehost gratis, Cloud vanaf $29/mnd Volledige controle
WordPress REST API N/A (als headless bewaren) Reeds gesynchroniseerd Bestaande hosting-kosten Snelle winsten
Payload CMS Hoog Ja Zelf gehost gratis Developer-first teams

We behandelen selectie van headless CMS uitgebreid op onze pagina headless CMS-ontwikkelingscapaciteiten, maar de korte versie: voor de meeste WordPress-migraties geeft Sanity of Payload CMS je het beste migratiepad.

Content-synchronisatie instellen

Dit is het kritieke deel: tijdens de parallelle run-fase moet content in beide systemen bestaan. Je hebt twee strategieën:

Strategie A: Eenmalige migratie + bevriezen Migreer alle content naar de nieuwe CMS en bevries dan WordPress-bewerking. Dit werkt voor kleine sites maar breekt af wanneer editors moeten blijven publiceren.

Strategie B: Continue sync (aanbevolen) Stel een sync-pijplijn in die WordPress-wijzigingen in bijna-real-time naar je nieuwe CMS repliceert.

// Voorbeeld: WordPress webhook-handler die synchroniseert naar Sanity
// Dit draait als een serverless-functie (Vercel/AWS Lambda)

import { createClient } from '@sanity/client';

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

export async function POST(request) {
  const payload = await request.json();
  const { post_id, post_title, post_content, post_status } = payload;

  if (post_status !== 'publish') return new Response('Overgeslagen', { status: 200 });

  try {
    await sanity.createOrReplace({
      _id: `wp-${post_id}`,
      _type: 'post',
      title: post_title,
      body: convertGutenbergToPortableText(post_content),
      migratedFrom: 'wordpress',
      wpId: post_id,
      _updatedAt: new Date().toISOString(),
    });

    return new Response('Gesynchroniseerd', { status: 200 });
  } catch (error) {
    console.error('Sync mislukt:', error);
    return new Response('Sync-fout', { status: 500 });
  }
}

Je hebt ook de WordPress-kant nodig. We gebruiken een eenvoudige plugin die werkt op save_post:

// wp-content/plugins/headless-sync/headless-sync.php
add_action('save_post', function($post_id, $post) {
    if (wp_is_post_revision($post_id)) return;
    
    wp_remote_post(SYNC_ENDPOINT_URL, [
        'body' => json_encode([
            'post_id' => $post_id,
            'post_title' => $post->post_title,
            'post_content' => $post->post_content,
            'post_status' => $post->post_status,
        ]),
        'headers' => [
            'Content-Type' => 'application/json',
            'X-Sync-Secret' => SYNC_SECRET,
        ],
    ]);
}, 10, 2);

Laat deze sync minstens 2 weken voor de omschakeling draaien. Je wilt edge cases opvangen — vreemde shortcodes, custom post types, ACF-velden die niet schoon in kaart brengen.

Zero Downtime CMS Migration: WordPress to Next.js Cutover Playbook - architectuur

Fase 2: Het Next.js-applicatie bouwen

Ik ga je niet het hele Next.js-buildproces hier doorlopen — dat verdient zijn eigen artikel (en we hebben diepe expertise in Next.js-ontwikkeling). Maar er zijn migratiespecifieke zaken die van belang zijn voor zero downtime.

URL-pariteit is niet onderhandelbaar

Elke enkele URL die op je WordPress-site bestaat, moet dezelfde content op je Next.js-site omzetten. Elke. Enkele. Een.

Dit betekent:

  • /blog/mijn-post-slug/ moet werken (inclusief de trailing slash als WordPress die gebruikte)
  • /category/technology/ moet werken of omleiden
  • /wp-content/uploads/2024/03/image.jpg moet omleiden naar je nieuwe image-CDN
  • /feed/ moet nog steeds geldige RSS/Atom retourneren
  • Paginerings-URL's zoals /blog/page/2/ moeten werken

Bouw snel een URL-audit-script:

# Exporteer alle WordPress-URL's met WP-CLI
wp post list --post_type=post,page --post_status=publish \
  --fields=ID,post_name,post_type,guid --format=csv > urls.csv

# Grijp ook omleidingen van eventuele SEO-plugins
wp db query "SELECT * FROM wp_redirection_items" --format=csv > redirects.csv

Valideer ze vervolgens tegen je Next.js-build:

// validate-urls.mjs
import { readFileSync } from 'fs';
import { parse } from 'csv-parse/sync';

const urls = parse(readFileSync('./urls.csv'), { columns: true });
const NEXT_BASE = 'https://staging.yoursite.com';

for (const row of urls) {
  const res = await fetch(`${NEXT_BASE}/${row.post_name}/`, {
    redirect: 'manual'
  });
  
  if (res.status >= 400) {
    console.error(`BROKEN: /${row.post_name}/ → ${res.status}`);
  }
}

Prestatielijn

Voordat je omschakelt, moet je Next.js-site minstens even snel zijn als WordPress. Klinkt voor de hand liggend, maar ik heb teams gezien die zo enthousiast waren over de nieuwe stack dat ze vergaten te benchmarken.

Noteer Core Web Vitals van je WordPress-site met behulp van CrUX-gegevens of Lighthouse CI, en match of beat ze. Als je WordPress-site een LCP van 2,1s heeft en je Next.js-site zit op 3,4s, ben je niet klaar.

Fase 3: Parallelle implementatieinstelling

Nu komen we bij de infrastructuur die zero downtime mogelijk maakt.

De parallelle uitvoering

Beide systemen draaien tegelijk en serveren echt verkeer. Maar slechts één is op elk moment "primair".

Voor Next.js op Vercel (ons meest voorkomende setup), deploy je je Next.js-app naar een aangepast domein zoals next.yoursite.com of gebruik je Vercel's preview-URL. Je WordPress-site blijft draaien op yoursite.com.

# Als je Nginx gebruikt als omgekeerde proxy
# Dit is de parallelle run-configuratie

upstream wordpress {
    server wordpress-origin.internal:80;
}

upstream nextjs {
    server next-yoursite.vercel.app:443;
}

server {
    listen 443 ssl;
    server_name yoursite.com;

    # Tijdens parallelle uitvoering: mirrorverkeer naar beide,
    # maar serveer reacties van WordPress
    location / {
        mirror /mirror;
        proxy_pass http://wordpress;
    }

    location = /mirror {
        internal;
        proxy_pass https://nextjs$request_uri;
    }
}

Deze mirror-configuratie stuurt elk verzoek naar beide backends, maar retourneert alleen het WordPress-antwoord. Je krijgt echt verkeer dat je Next.js-app raakt zonder dat gebruikers het zien. Controleer je Next.js-logs op fouten, 404's en trage reacties.

Synthetische monitoring

Stel monitoring in die continu valideert dat beide systemen gelijkwaardige content retourneren:

// canary-check.mjs — draait elke 5 minuten via cron
const CRITICAL_URLS = [
  '/',
  '/blog/',
  '/about/',
  '/contact/',
  '/blog/most-popular-post/',
];

for (const path of CRITICAL_URLS) {
  const [wpRes, nextRes] = await Promise.all([
    fetch(`https://yoursite.com${path}`),
    fetch(`https://next.yoursite.com${path}`),
  ]);

  if (wpRes.status !== nextRes.status) {
    alert(`Statusverschil op ${path}: WP=${wpRes.status} Next=${nextRes.status}`);
  }

  // Vergelijk titeltags als content-pariteitscontrole
  const wpTitle = (await wpRes.text()).match(/<title>(.*?)<\/title>/)?.[1];
  const nextTitle = (await nextRes.text()).match(/<title>(.*?)<\/title>/)?.[1];

  if (wpTitle !== nextTitle) {
    alert(`Titelverschil op ${path}`);
  }
}

Laat dit minstens 1 week draaien met nul waarschuwingen voordat je doorgaat naar de omschakeling.

Fase 4: Blue-Green-implementatieconfiguratie

Blue-green implementatie betekent twee identieke productieomgevingen — blauw (huidige WordPress) en groen (nieuwe Next.js) — en atomair tussen hen schakelen.

Cloudflare Workers gebruiken voor verkeersrouting

Dit is onze voorkeursbenadering omdat het je directe, wereldwijd verkeersschakelen geeft zonder DNS-propagatievertraging.

// Cloudflare Worker voor blue-green routing
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    
    // Lees de actieve omgeving uit KV store
    const activeEnv = await env.CONFIG.get('active_environment') || 'blue';
    
    // Optioneel: percentage-gebaseerde canary-routing
    const canaryPercent = parseInt(await env.CONFIG.get('canary_percent') || '0');
    const useGreen = activeEnv === 'green' || 
                     (canaryPercent > 0 && Math.random() * 100 < canaryPercent);
    
    const origin = useGreen
      ? 'https://next-yoursite.vercel.app'
      : 'https://wp-origin.yoursite.com';
    
    const originUrl = new URL(url.pathname + url.search, origin);
    
    const response = await fetch(originUrl, {
      method: request.method,
      headers: {
        ...Object.fromEntries(request.headers),
        'Host': new URL(origin).hostname,
        'X-Forwarded-Host': url.hostname,
      },
      body: request.method !== 'GET' ? request.body : undefined,
    });
    
    const newResponse = new Response(response.body, response);
    newResponse.headers.set('X-Served-By', useGreen ? 'green-nextjs' : 'blue-wordpress');
    
    return newResponse;
  }
};

Het mooie van deze benadering: schakelen van WordPress naar Next.js is een enkele KV store-schrijf. Geen DNS-wijzigingen. Geen propagatie. Instant.

# Schakel naar groen (Next.js)
curl -X PUT "https://api.cloudflare.com/client/v4/accounts/{account_id}/storage/kv/namespaces/{namespace_id}/values/active_environment" \
  -H "Authorization: Bearer ${CF_TOKEN}" \
  --data "green"

# Terugdraaien naar blauw (WordPress) als er iets misgaat
curl -X PUT "https://api.cloudflare.com/client/v4/accounts/{account_id}/storage/kv/namespaces/{namespace_id}/values/active_environment" \
  -H "Authorization: Bearer ${CF_TOKEN}" \
  --data "blue"

Canary-routing

Schakel niet ineens 100% van het verkeer. Start met een canary:

  1. 1% verkeer naar Next.js — Controleer 1 uur op fouten
  2. 10% verkeer — Controleer 2 uur
  3. 50% verkeer — Controleer 4 uur
  4. 100% verkeer — Controleer 24 uur
  5. WordPress buiten bedrijf stellen — Na 1 week op 100%

Fase 5: DNS-omschakelstrategie

Als je geen Cloudflare Workers kunt gebruiken (of een vergelijkbare edge routing-oplossing), moet je de omschakeling op DNS-niveau afhandelen. Dit is lastiger vanwege TTL-propagatie.

DNS-voorbereiding vóór omschakeling

Minstens 48 uur voor omschakeling:

  1. Verlaag je DNS-TTL naar 60 seconden (van de typische 3600 of 86400)
  2. Wacht tot de oude TTL verloopt
  3. Verifieer dat de lage TTL actief is: dig yoursite.com +short moet TTL ~60 tonen
# Controleer huidige TTL
dig yoursite.com A +noall +answer
# Moet iets als dit tonen:
# yoursite.com.  60  IN  A  76.76.21.21

De DNS-switch

Met een 60-seconden TTL betekent het bijwerken van je DNS A/CNAME-record wereldwijde propagatie in ongeveer 5-10 minuten (sommige resolvers negeren lage TTL's, maar de meeste respecteren ze in 2025).

# Als je naar Vercel gaat
# Werk CNAME bij om naar cname.vercel-dns.com te wijzen
# Of werk A-records bij naar Vercel's IP-adressen: 76.76.21.21

De gotcha: SSL-certificaattiming

Hier is iets dat mensen betrapt. Wanneer je DNS naar Vercel (of een ander nieuw host) schakelt, moet het SSL-certificaat voor je domein voor de switch op de nieuwe host worden ingericht. Anders krijg je een venster waar HTTPS niet werkt.

Op Vercel voegt je aangepaste domein toe in de projectinstellingen voor de DNS-switch. Vercel zal proberen het cert in te richten via HTTP-01 of DNS-01 uitdaging. Als je Cloudflare proxy DNS gebruikt, moet je mogelijk de proxy tijdelijk uitschakelen (oranje wolk → grijze wolk) voor cert-inrichting om te werken.

Fase 6: De omschakelingscontrolelijst

Dit is de controlelijst die we op omschakelingsdag gebruiken. Druk het af. Vink elk vakje aan.

Voor omschakeling (T-24 uur)

  • Alle content gesynchroniseerd en geverifieerd in nieuwe CMS
  • URL-pariteitsvalidatie slaagt 100%
  • SSL-certificaat ingericht op nieuwe host
  • DNS-TTL bevestigd op 60 seconden
  • Terugtrekprocedure gedocumenteerd en getest
  • Alle omleidingen van WordPress SEO-plugin gemigreerd naar next.config.js of edge middleware
  • robots.txt en sitemap.xml genereren correct op Next.js
  • Analyticsverfolgingsgegevenscorrectie geverifieerd op Next.js (GA4, GTM, etc.)
  • Formulierindieningen getest end-to-end
  • RSS-feed gevalideerd
  • OpenGraph-tags geverifieerd op belangrijke pagina's
  • 404-pagina getest

Omschakeling (T-0)

  • Informeer belanghebbenden: "Migratie gestart"
  • Zet canary op 1% → controleer 30 min
  • Verhoog naar 10% → controleer 1 uur
  • Controleer Google Search Console op crawlfouten
  • Verhoog naar 50% → controleer 2 uur
  • Verhoog naar 100%
  • Dien bijgewerkte sitemap in bij Google Search Console
  • Verifieer dat Googlebot alle kritieke pagina's kan openen (gebruik URL Inspection tool)
  • Test alle formulieren, e-commerce flows, auth flows

Na omschakeling (T+24 uur)

  • Controleer Core Web Vitals in CrUX-dashboard
  • Controleer Google Search Console op dekkingsproblemen
  • Verifieer dat alle analysegegevens correct stromen
  • WordPress-origin blijft draaien (bewaar minstens 2 weken)
  • Voer volledige site-crawl uit met Screaming Frog tegen nieuwe site

Fase 7: Monitoring na omschakeling en terugdraaien

Wat controleren

Stel dashboards in in je monitoring-tool (we gebruiken een combinatie van Vercel Analytics, Datadog, en Google Search Console) tracking:

  • Foutpercentages: Eventuele 5xx-reacties? Stijging van 4xx?
  • Reactietijden: P50, P95, P99 latentie
  • Core Web Vitals: LCP, FID/INP, CLS
  • Search Console: Crawlstats, dekkingsrapport, indexeringsstatus
  • Bedrijfsmetriek: Conversiepercentage, bounce rate, pagina's/sessie

Het terugtrekplan

Je terugtrekking moet een enkel commando zijn. Niet een 15-staps proces. Eén commando.

Met de Cloudflare Worker-benadering:

# Één commando terugdraaien
wrangler kv:key put --namespace-id=$NS_ID "active_environment" "blue"

Met DNS-gebaseerde schakeling:

# Pre-gescript DNS-terugtrekking via Cloudflare API
curl -X PATCH "https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_records/{record_id}" \
  -H "Authorization: Bearer ${CF_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"content": "old-wordpress-ip-address"}'

Houd WordPress draaiende voor minstens 2 weken na omschakeling. Wees geen held. Het moment waarop je WordPress afsluit is het moment waarop je een pagina ontdekt die je bent vergeten te migreren.

Veelvoorkomende faalwijzen en hoe deze voorkomen

Na dit dozijnen keren te hebben gedaan, hier zijn de fouten die ik het meest zie:

1. Vergeten WordPress-plugins met frontend-routes Die contactformulier-plugin maakt /wp-json/contact-form-7/ endpoints. Die WooCommerce-installatie heeft /my-account/ en /cart/. Map elk endpoint-voetafdruk van plugins.

2. Hardgecodeerde wp-content URL's in content Afbeeldingen in je content verwijzen naar /wp-content/uploads/. Je hebt omleidingen of een herschrijfregel nodig die deze naar je nieuwe asset-CDN wijzen.

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/wp-content/uploads/:path*',
        destination: 'https://cdn.yoursite.com/uploads/:path*',
        permanent: true,
      },
    ];
  },
};

3. Sitemap XML's vergeten Google Search Console wijst naar /sitemap.xml. Je Next.js-app moet een genereren. Gebruik next-sitemap of bouw het in je app's route handlers.

4. Verificatie- en sessieproblemen Als je WordPress-site ingelogde gebruikers heeft, werken hun cookies niet op de nieuwe stack. Plan de gebruikermigratie apart.

5. CDN-cachevergiftiging tijdens overgang Als Cloudflare reacties cacht, serveer je mogelijk verouderde WordPress-pagina's na schakelen naar Next.js. Zuiver de CDN-cache onmiddellijk na schakelen.

# Zuiver volledige Cloudflare-cache na schakelen
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache" \
  -H "Authorization: Bearer ${CF_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"purge_everything": true}'

Als je een migratie plant en experts wilt die de zware last opnemen, controleer onze prijzingspagina of neem rechtstreeks contact op. We hebben dit vaak genoeg gedaan dat onze playbooks op alle juiste manieren strijd-gehavend zijn.

Voor sites gebouwd met andere frameworks, doen we ook Astro-gebaseerde migraties die nog sneller kunnen zijn voor content-zware sites die niet veel interactiviteit nodig hebben.

Veelgestelde vragen

Hoe lang duurt een WordPress naar Next.js migratie typisch? Voor een site met gemiddelde complexiteit (100-500 pagina's, custom post types, wat dynamische functionaliteit), plan 8-12 weken end-to-end. De content-migratie en parallelle run-fase duurt alleen al 3-4 weken. De eigenlijke omschakeling, als je het voorbereidingswerk hebt gedaan, duurt ongeveer 4 uur actief werk. Laat niemand je vertellen dat dit in een weekend kan.

Kan ik WordPress als headless CMS gebruiken in plaats van content migreren? Absoluut, en voor sommige teams is dit de juiste keuze. Je behoudt WordPress als je CMS, gebruikt de REST API of WPGraphQL om content naar Next.js te voeden, en migreert alleen de frontend. Dit verkort de migratietijdlijn aanzienlijk omdat je de content-migratiefase overslaat. De afweging is dat je nog steeds een WordPress-installatie onderhoudt met al zijn update- en veiligheidsoverhead.

Wat gebeurt er met mijn SEO-rankings tijdens een migratie? Met een juiste zero-downtime migratie moeten je rankings stabiel blijven. Googles John Mueller heeft bevestigd dat het wijzigen van je CMS geen invloed op rankings moet hebben als de content, URL's, en technische SEO-elementen gelijkwaardig blijven. De grootste risico's zijn verbroken URL's (die 404's veroorzaken), gewijzigde interne linkstructuren, en verminderde paginasnelheid. Ons playbook behandelt specifiek alle drie.

Hoe ga ik met WordPress-formulieren in Next.js om? Je hebt verschillende opties: gebruik een formulierservice zoals Formspree of Basin, bouw API-routes in Next.js die indieningen rechtstreeks afhandelen, of gebruik de formulierfuncties van je headless CMS (Sanity heeft geen native formulieren, maar Payload CMS wel). Voor complexe formulieren met voorwaardelijke logica, bouwen we meestal custom API-routes en gebruiken React Hook Form op de frontend.

Moet ik Vercel, Netlify, of zelf-hosten voor de Next.js-implementatie? Voor de meeste teams is Vercel het pad van minste weerstand voor Next.js. Het is gebouwd door hetzelfde team, en functies zoals ISR, middleware, en imageoptimalisatie werken daar het beste. Vercel's Pro-plan op $20/gebruiker/maand dekt meeste productiebehoeften. Als je specifieke nalevingsvereisten hebt of op AWS moet blijven, kun je zelf-hosten met de standalone output-modus. Netlify werkt ook maar is historisch achtergebleven op Next.js-functieondersteuning.

Wat is het verschil tussen blue-green implementatie en canary-implementatie? Blue-green is binair: al het verkeer gaat naar ofwel het oude systeem (blauw) ofwel het nieuwe (groen). Canary-implementatie verschuift geleidelijk een percentage van het verkeer van oud naar nieuw. In de praktijk combineren we beide. We stellen blue-green infrastructuur in (twee volledige omgevingen) maar gebruiken canary-stijl percentage-gebaseerde routing tijdens de eigenlijke omschakeling. Dit geeft je de veiligheid van geleidelijke rollout met de eenvoud van slechts twee omgevingen om te beheren.

Hoe migreer ik WordPress-omleidingen naar Next.js? Exporteer je omleidingen van je WordPress-plugin (Redirection, Yoast, RankMath). Converteer ze naar Next.js-omleiding-formaat in next.config.js. Voor sites met honderden omleidingen, gebruik middleware in plaats daarvan — het is performanter en kan patroonmatching afhandelen. Wees ervan bewust dat next.config.js omleidingen een praktische limiet van ongeveer 1.000 items op Vercel hebben voordat build-tijden lijden.

Kan ik na omschakeling terugkeren naar WordPress als iets misgaat? Ja, en dit is niet onderhandelbaar. Houd je WordPress-instantie minstens 2 weken na omschakeling draaiende. Met de Cloudflare Worker-benadering beschreven in dit artikel, terugdraaien is een enkel API-aanroep dat wereldwijd binnen seconden van kracht wordt. Met DNS-gebaseerde schakeling duurt terugdraaien 1-10 minuten afhankelijk van TTL-propagatie. Deactiveer het oude systeem nooit totdat je zeker bent dat het nieuwe stabiel is.