De kern: een WordPress-migratie veroorzaakt downtime wanneer de stappen in de verkeerde volgorde gebeuren — DNS wordt omgezet voordat de nieuwe site is geverifieerd, of inhoud verandert op de oude site nadat de database al is geëxporteerd. Het werk parallel uitvoeren op de nieuwe omgeving, deze volledig testen vóór de overgang, en de DNS-TTL van tevoren verlagen is wat de overgang onzichtbaar maakt voor bezoekers.
Waarom migraties meestal downtime veroorzaken
De standaard, ongeplande manier om een WordPress-site te verplaatsen — database exporteren, bestanden kopiëren, DNS naar de nieuwe server laten wijzen, en dan beginnen te repareren wat kapot is — creëert een venster waarin de site ofwel volledig plat ligt, ofwel een half gemigreerde, kapotte versie serveert. Elke stap in die volgorde gebeurt direct op de live site zelf, dus elke fout is meteen zichtbaar voor bezoekers.
Migratie zonder downtime lost dit op door de volgorde om te draaien: bouw en verifieer de nieuwe omgeving volledig terwijl de oude ongemoeid verkeer blijft bedienen, en wissel pas over zodra alles bevestigd werkt. De live site bevindt zich nooit in een tussentijdse, kapotte staat omdat het migratiewerk er nooit direct op plaatsvindt.
Checklist vóór de migratie
- Maak een volledige back-up van de bestanden en database van de huidige site, opgeslagen ergens buiten het huidige hostingaccount.
- Verlaag de DNS-TTL op het A-record van het domein naar 300 seconden (5 minuten) minstens 24-48 uur vóór de geplande overgang — zie het technische detail hieronder over waarom dit vooraf timen belangrijk is.
- Inventariseer actieve plugins en thema's, noteer versies, aangezien de nieuwe omgeving moet overeenkomen met de PHP-versie en extensievereisten.
- Bevestig dat de nieuwe host volledig is ingesteld — WordPress geïnstalleerd, klaar om de gemigreerde bestanden en database te ontvangen, maar nog niet publiekelijk gekoppeld aan het domein.
Stap 1: Verlaag de DNS-TTL voordat je begint
DNS-TTL (time to live) bepaalt hoe lang resolvers overal op internet het huidige IP-adres van een domein cachen voordat ze opnieuw controleren. Een typische standaard-TTL van meerdere uren (soms 24 of meer) betekent dat zelfs nadat DNS is bijgewerkt om naar de nieuwe server te wijzen, een aanzienlijk deel van de bezoekers de oude blijft bereiken totdat de gecachete kopie van hun resolver verloopt. Cloudflare's eigen uitleg over DNS-TTL behandelt dit mechanisme in meer technische diepte.
De TTL een dag of twee vóór de daadwerkelijke overgang naar 300 seconden verlagen betekent dat tegen de tijd dat DNS wordt omgezet, de propagatievertraging minuten in plaats van uren bedraagt — de meest impactvolle individuele voorbereidingsstap voor een echt downtime-arme overgang.
Stap 2: Bouw de nieuwe omgeving parallel op
Stel WordPress volledig onafhankelijk van de live site op de nieuwe host in — dezelfde PHP-versie, dezelfde vereiste extensies, klaar om content te ontvangen maar nog niet op een publiekelijk zichtbare manier gekoppeld aan het live domein. Dit is de stap die "zonder downtime" mogelijk maakt: al het installatiewerk gebeurt op infrastructuur die nog niemand bezoekt.
Stap 3: Migreer bestanden en database
Tools zoals Duplicator of de All-in-One WP Migration-plugin verpakken de bestanden en database van de site in één overdraagbaar archief en handelen de technische details van een schone database-export en -import af. Voor bureaus die vaak migraties uitvoeren, handelt een host-naar-host-migratietool die ingebouwd is in beheerde hostingplatforms (Kinsta, WP Engine en andere bieden dit) het proces vaak af met minder handmatig werk.
Een specifieke technische valkuil om hier te vermijden: voer geen simpele zoek-en-vervang uit op de database om het domein van de oude URL naar de nieuwe bij te werken. WordPress slaat geserialiseerde PHP-gegevens op — gebruikt door veel widgets, sommige plugin-instellingen en thema-opties — als strings met een ingebed tekenlengte-voorvoegsel. Een naïeve tekstvervanging verandert de lengte van de string zonder dat voorvoegsel bij te werken, waardoor de gegevens stilletjes corrumperen. Het search-replace-commando van WP-CLI is specifiek gebouwd om geserialiseerde gegevens correct af te handelen en is de standaardtool voor precies deze stap.
Stap 4: Test de nieuwe site met je eigen hosts-bestand
Voordat je het publieke DNS aanraakt, bewerk je het lokale hosts-bestand van je eigen computer zodat het domein naar het IP-adres van de nieuwe server wijst — dit beïnvloedt alleen jouw machine en laat je door de nieuwe site bladeren met de echte domeinnaam (inloggen, afrekenen, contactformulieren en al het andere testen dat afhankelijk is van het overeenkomende domein), zonder dat een andere bezoeker wordt beïnvloed. Dit is de stap die migratieproblemen opvangt voordat ze publiek worden.
Stap 5: Verzoen inhoudswijzigingen die tijdens het migratievenster zijn gemaakt
Als de live site na het exporteren van de database bleef reacties, bestellingen of formulierinzendingen ontvangen, bestaat die inhoud op de oude site maar niet op de nieuwe. Voor de meeste brochuresites is dit venster klein genoeg om te negeren; voor alles transactioneels (e-commerce, lidmaatschapsinhoud) exporteer je alleen de nieuwe records die tijdens het migratievenster zijn aangemaakt en importeer je ze vóór de overgang in de nieuwe database.
Stap 6: Zet DNS om
Zodra de nieuwe site volledig is getest via de hosts-bestandmethode en eventuele inhoudsverschillen zijn verzoend, werk je het A-record van het domein bij zodat het naar de nieuwe server wijst. Omdat de TTL van tevoren is verlaagd, lossen de meeste bezoekers binnen enkele minuten in plaats van uren op naar de nieuwe server.
Stap 7: Verifieer en monitor na de overgang
- Bevestig dat SSL actief is op de nieuwe server voor het domein, aangezien een ontbrekend of verkeerd geconfigureerd certificaat de HTTPS-toegang direct breekt.
- Controleer op gemengde-inhoudswaarschuwingen veroorzaakt door hardgecodeerde http://-URL's die zijn achtergebleven in de database of themabestanden.
- Verifieer dat omleidingen nog werken als de migratie een wijziging in URL-structuur omvatte, en controleer Google Search Console de volgende dagen op een piek in crawlfouten.
- Houd serverlogs in de gaten voor 404's op eerder werkende URL's, wat meestal wijst op een gemist bestand of een onvolledige zoek-en-vervang.
Migratietijdlijn in één oogopslag
| Fase | Timing | Belangrijkste acties |
|---|---|---|
| Vóór migratie | 24-48 uur van tevoren | DNS-TTL verlagen, back-up maken, bevestigen dat nieuwe host klaar is |
| Parallelle opbouw | Vóór de overgang | Nieuwe omgeving opzetten, bestanden/database migreren met een geschikte tool |
| Verificatie | Vóór de overgang | Testen via lokaal hosts-bestand met het echte domein |
| Overgang | Migratiedag | Eventuele inhoudsverschillen verzoenen, DNS omzetten |
| Na migratie | Eerste 48-72 uur | SSL verifiëren, controleren op gemengde inhoud, logs en Search Console monitoren |
Veelgemaakte migratiefouten
- De stap van het verlagen van de DNS-TTL overslaan, waardoor de propagatie van de overgang overgelaten wordt aan wat de oude TTL toevallig was ingesteld.
- Een simpele zoek-en-vervang uitvoeren op de database in plaats van een serialisatiebewuste tool zoals de search-replace van WP-CLI, waardoor widget- en thema-instellingen stilletjes corrumperen.
- DNS omzetten voordat de nieuwe site is getest, waarbij een kapotte plugin of ontbrekend bestand pas wordt ontdekt nadat bezoekers er al op terechtkomen.
- Content vergeten die tijdens het migratievenster is aangemaakt, waarbij reacties, bestellingen of inzendingen verloren gaan die na de export op de oude site terechtkwamen.
- SSL op de nieuwe server niet bevestigen vóór de overgang, wat op het moment dat DNS wisselt een zichtbare certificaatwaarschuwing veroorzaakt.
Wanneer hulp inschakelen om voortgang aan een klant te tonen
Bureaus die de site van een klant migreren, moeten vaak de parallelle nieuwe omgeving tonen voor goedkeuring vóór de daadwerkelijke overgang — zonder hostinginloggegevens over te dragen of een verwarrende hosts-bestand-workaround waar een niet-technische klant achteraan moet. Een tool zoals Erdo Client Preview of Erdo Draft Links geeft een klant een eenvoudige link om de nieuwe site rechtstreeks te bekijken, wat van nature aansluit bij de testgewoontes uit onze WordPress staging-gids en onze bredere WordPress snelheid- en hostinggids voor het evalueren van de bestemmingshost zelf.
Tot slot
Kortom, een WordPress-migratie zonder downtime komt neer op volgorde: verlaag de DNS-TTL ruim van tevoren, bouw en test de nieuwe omgeving volledig parallel op met je eigen hosts-bestand in plaats van publiek DNS, gebruik een serialisatiebewuste tool voor elke URL-update, en zet DNS pas om zodra alles bevestigd werkt. Volg die volgorde en de live site bevindt zich nooit in een tussentijdse, kapotte staat — bezoekers lossen simpelweg op naar de nieuwe server zodra deze al bevestigd klaar is.