WordPress verhuizen naar andere hosting zonder downtime: draaiboek

Verlaag eerst je TTL. Dat is de stap die de meeste mensen overslaan, en die maakt het verschil tussen een vlotte overstap en een halve dag onbereikbare site. Doe het 24 tot 48 uur voordat je gaat verhuizen.

WordPress verhuizen naar andere hosting zonder downtime klinkt als een ingewikkelde operatie. In de praktijk is het vooral een kwestie van volgorde. Wie de juiste stappen op het juiste moment doet, krijgt een vlotte overstap. Wie improviseert, krijgt een gat van een paar uur.

In dit artikel het complete draaiboek. Wat je vooraf voorbereidt, hoe je parallel draait, in welke volgorde je de DNS omzet en wat je achteraf controleert. Geschreven voor mensen die meekijken bij hun eigen migratie, of die willen weten wat ik doe als ik het uit handen genomen krijg.

WordPress verhuizen naar andere hosting zonder downtime: de oorzaken

Een WordPress-verhuizing zonder plan kent twee oorzaken voor downtime. De eerste is dat de site op de oude server al uit staat terwijl de nieuwe nog niet bereikbaar is. De tweede is dat de DNS-verandering te traag doorkomt, waardoor bezoekers tussen oud en nieuw heen pendelen.

Beide zijn vermijdbaar. De eerste door parallel te draaien: oud en nieuw beide live, op hetzelfde moment. De tweede door de TTL ruim van tevoren te verlagen, zodat de wereldwijde DNS-caches snel meelopen.

Het zijn geen exotische technieken. Het is gewoon goede planning. En het is precies wat agencies vaak overslaan omdat ze migraties als bijklus zien.

Wat je vooraf voorbereidt

Voordat je iets aanraakt, een paar dingen op orde brengen.

Toegang tot beide hosters. Tot de oude voor de backup en de export, tot de nieuwe voor de import. Zonder volledige toegang loop je vast bij stap drie.

Toegang tot de DNS. Vaak is dit een aparte partij (TransIP, Argeweb, Cloudflare, soms de oude hoster zelf). Check waar de nameservers staan en of je daar kunt inloggen.

Een lijst van wat er draait. Welke WordPress-versie, welke PHP-versie, welke plugins, welke thema's. Een actieve site met ACF Pro en WooCommerce vraagt om een andere check dan een statische bedrijfssite.

Een venster waarop bezoekers minder zijn. Niet voor de downtime (die is er niet), maar voor de zekerheid. Een dinsdagavond om 22:00 of een zaterdagochtend werkt voor de meeste sites prima.

Stap 1: TTL verlagen, 24 tot 48 uur vooraf

Dit is de stap die je niet kunt overslaan. TTL staat voor "time to live": hoe lang DNS-servers wereldwijd jouw record onthouden voordat ze opnieuw kijken.

Standaard staat TTL vaak op 3600 seconden (een uur) of zelfs 86400 (een hele dag). Dat betekent dat een verandering pas na maximaal die tijd overal is doorgekomen.

Verlaag de TTL van je A-record en je www-CNAME naar 300 seconden, het liefst zelfs 60. Doe dat 24 tot 48 uur voordat je de switch maakt. Dan hebben alle DNS-caches die de oude waarde nog hadden, ruim de tijd om de nieuwe lage TTL op te pikken.

Pas na de switch (een paar dagen later) zet je de TTL weer omhoog, naar 3600 of meer. Een lage TTL is prima voor migraties, maar belast je DNS-server onnodig als hij permanent zo staat.

Stap 2: Nieuwe omgeving klaarzetten

Op de nieuwe hoster zet je de site al volledig in de lucht. Niet morgen, nu.

Werkwijze die ik aanhoud:

• Hosting account opzetten, PHP-versie matchen aan de oude (bij voorkeur 8.1 of hoger)
• WordPress installeren of een leeg bestandssysteem klaarzetten
• Database aanmaken met de juiste user en wachtwoorden noteren
• SSL-certificaat aanvragen voor het domein (de meeste hosters doen dit via Let's Encrypt)
• Een tijdelijk hostnaam-trucje regelen, zodat je de nieuwe site al kunt zien voor de DNS-switch

Dat laatste kan via een hostfile-aanpassing op je eigen computer, of via een tijdelijke testdomein-URL bij de nieuwe hoster. Je wilt namelijk testen dat de site op de nieuwe server werkt, voordat je echte bezoekers ernaartoe stuurt.

Stap 3: Files en database overzetten

Dit is het ambachtelijke deel. Er zijn migratieplugins (All-in-One WP Migration, Duplicator, Migrate Guru) die het werk grotendeels doen, en ze werken vaak prima voor kleinere sites.

Voor grotere sites of als ik de controle wil houden, doe ik het handmatig:

• Files via rsync of via een sFTP-sessie naar de nieuwe server
• Database via mysqldump op de oude, importeren via mysql op de nieuwe (of via phpMyAdmin)
• wp-config.php aanpassen aan de nieuwe database-credentials
• Search-replace van de oude site-URL naar de nieuwe via WP-CLI of een plugin

De wp search-replace van WP-CLI is hier essentieel. Hij vervangt geserialiseerde data correct, wat een gewone SQL-replace niet doet. Sla die stap niet over, anders breken er widgets en options.

Stap 4: Parallel draaien en testen

Nu komt het kritieke moment. Beide servers draaien. De oude is nog steeds de live site (DNS wijst er nog naartoe). De nieuwe is bereikbaar via je hosts-trucje of het testdomein.

Doorloop een korte testlijst:

• Homepage laadt
• Een paar diepe pagina's laden
• Admin-login werkt
• Contactformulier verstuurt een test-mail
• Webshop: een test-bestelling tot aan de betaling (niet doorklikken naar de bank)
• Beeld en CSS laden correct

Vind je iets dat niet werkt, los het op vóór de DNS-switch. Op dit moment zijn er nog geen echte bezoekers op de nieuwe omgeving, dus je hebt alle ruimte.

Stap 5: De DNS-switch

Nu de daadwerkelijke overstap. Pas het A-record van je domein aan naar het IP-adres van de nieuwe server. Doe hetzelfde met www, eventuele subdomeinen en je MX-records voor mail (als die niet apart staan).

Door de lage TTL die je 24-48 uur geleden hebt gezet, propageert dit nu binnen vijf tot tien minuten wereldwijd. Bezoekers gaan stilaan over van oud naar nieuw, zonder iets te merken.

Belangrijk: zet de oude server niet meteen uit. Laat hem nog 24 tot 48 uur draaien, omdat een enkele DNS-cache hardnekkig kan zijn. Bezoekers die nog het oude IP zien, krijgen de oude site, en dat is beter dan een witte pagina.

Meer achtergrond over hoe DNS-propagatie echt werkt staat in DNS-overstap bij website-migratie.

Stap 6: Monitoring na de switch

De eerste 24 uur na een migratie is wat ik actief monitor. Niet omdat ik fouten verwacht, maar omdat kleine ongemakken nu makkelijker op te lossen zijn dan over een week.

Wat ik in de gaten houd:

• Uptime-monitoring (UptimeRobot of vergelijkbaar) met checks per minuut
• Error log van de nieuwe server, in real time
• Google Search Console voor crawl-fouten
• E-mail: of er nog mail binnenkomt en uitgaat
• WooCommerce: of bestellingen normaal binnenkomen

Vind ik iets, dan los ik het direct op. Vaak gaat het om kleine permissions-issues, een ontbrekende cron-job of een cache die nog niet is leeggemaakt.

Na 48 tot 72 uur, als alles stabiel draait, zet ik de oude server uit. TTL gaat weer omhoog naar normale waarden. Backups op de nieuwe server worden ingesteld. De migratie is klaar.

Wanneer dit aanpak niet werkt

Eerlijk over de grenzen. Een migratie zonder downtime werkt voor de meeste sites. Maar er zijn uitzonderingen.

Een actieve webshop met veel verkeer. Een paar uur parallel draaien kan dubbele bestellingen veroorzaken (één bezoeker bestelt op oud, een ander op nieuw). Hier doe ik een korte gecontroleerde maintenance-window, of een meer geavanceerde sync.

Headless setups of complexe API-koppelingen. Hier raak ik aan een grens van wat ik aanneem; voor headless verwijs ik door.

Sites op een server die uitvalt voor de migratie. Als de oude hoster onbereikbaar is, kan ik geen parallelle setup maken. Dan wordt het herstel uit backup, geen migratie.

Bij twijfel: een gratis kennismaking en ik kijk naar je situatie.

Wat het kost

Een WordPress-migratie reken ik tegen 95 euro per uur. Dat is mijn migratie- en servertarief. Een typische migratie van een mkb-site (een dienstverlener, een lokale winkel) duurt 3 tot 6 uur, inclusief voorbereiding en monitoring.

Voor grotere sites of webshops loopt het op naar 6 tot 12 uur. Een vooraf afgesproken urenraming met bovengrens houdt het voorspelbaar.

Multi-stack: dezelfde aanpak werkt voor Joomla, Drupal, Shopify of een Laravel-applicatie. De stappen verschillen in details, het draaiboek blijft hetzelfde.

Verbeteren boven herbouwen: een migratie is een mooi moment om de site door te lichten op snelheid en beveiliging, maar dat is een aparte klus die je vooraf afspreekt.