Een klant belde me maandag op. Zijn webshop was na een servermigratie half leeg: producten weg, bestellingen weg, formulieren kapot. De hostingpartij had “alles overgezet”. Dat klopte technisch, maar niet volledig.
WordPress-migraties gaan vaker mis dan je denkt. Dit artikel legt uit waar het fout gaat en hoe je dat voorkomt.
Wat er eigenlijk bij een migratie hoort
Een WordPress-migratie is meer dan bestanden kopiëren. Je hebt drie onderdelen: de bestandsstructuur, de database en de configuratie. Ontbreekt er één, dan werkt de site niet of niet volledig.
De bestandsstructuur bevat je thema, plugins en uploads. De database bevat je content, instellingen en gebruikers. De configuratie zit in wp-config.php en bepaalt hoe WordPress de database vindt.
Veel hostingpartijen kopiëren de bestanden correct maar exporteren de database niet of niet volledig. Zeker bij grote databases met veel tabellen gaat dat mis.
De database: de meest vergeten stap
De database is het hart van elke WordPress-installatie. Alles wat je in het beheerpaneel invoert, staat daar. Posts, pagina’s, formulierinzendingen, WooCommerce-bestellingen, gebruikersrollen, plugin-instellingen.
Een veelgemaakte fout is exporteren via phpMyAdmin met de standaardinstellingen. Die exporteert soms niet alle tabellen, zeker als je veel plugins hebt die eigen tabellen aanmaken. Controleer altijd het aantal tabellen vóór en ná de export.
Gebruik je een migratietool zoals Duplicator of All-in-One WP Migration, dan pakt die tool de database en de bestanden samen in. Dat is betrouwbaarder dan handmatig exporteren, maar ook niet onfeilbaar bij databases boven de 512 MB.
URL’s en de wp-config aanpassen
Na de migratie draait de database nog met de oude URL. WordPress slaat de siteURL en homeURL op in de tabel wp_options. Pas je die niet aan, dan stuurt WordPress bezoekers door naar de oude domeinnaam.
De snelste correctie is via WP-CLI:
wp search-replace 'https://oudedomein.nl' 'https://nieuwedomein.nl' --all-tables
Dit vervangt de URL in alle tabellen, inclusief geserialiseerde data. Doe je dat handmatig via SQL, dan ga je gegarandeerd geserialiseerde arrays kapotmaken.
Vergeet daarna wp-config.php niet. Controleer de databasenaam, het gebruikersnaam en wachtwoord. Op een nieuwe server zijn die vaak anders. Eén typefout en WordPress geeft een witte pagina zonder foutmelding.
Formulieren, caches en plugin-instellingen
Formulieren zijn kwetsbaar bij migraties. Plugins zoals Gravity Forms of Contact Form 7 slaan instellingen op in de database, maar koppelen soms ook aan een licentie-URL. Na een domeinwissel werkt de licentie niet meer en valt het formulier terug op een foutmelding.
Hetzelfde geldt voor caching-plugins. W3 Total Cache en WP Super Cache slaan padverwijzingen op in configuratiebestanden. Op een nieuwe server kloppen die paden niet meer. Verwijder de cache volledig vóórdat je de site live zet.
Sommige plugins, zeker betaalde, registreren de licentie per domein. Deactiveer die licentie op de oude omgeving voordat je de nieuwe activeert. Doe je dat niet, dan werkt activering op de nieuwe server niet.
Voor grotere projecten waarbij meerdere partijen betrokken zijn, zoals een IT-manager, een externe ontwikkelaar en een hostingbedrijf, helpt het om van tevoren vast te leggen wie welke stap uitvoert. Soms zie je in dat soort trajecten ook een Governance Specialist inhuren om verantwoordelijkheden en beslissingsbevoegdheden te formaliseren, zodat niemand achteraf zegt dat hij dacht dat de ander de database had geëxporteerd.
Checklist vóór je de DNS omzet
Dit is het moment waarop de meeste fouten worden gemaakt. DNS omzetten is onomkeerbaar op korte termijn. Propagatie duurt tot 48 uur en je kunt niet zomaar terug.
Controleer deze punten vóór je de DNS aanpast:
- Siteadres en homeadres kloppen in
wp_options - Alle formulieren werken en sturen testberichten correct door
- SSL-certificaat is actief op de nieuwe server
- Caches zijn leeggemaakt en caching-plugins zijn opnieuw geconfigureerd
- Licenties van betaalde plugins zijn overgezet
- Een volledige back-up van de nieuwe omgeving is gemaakt
- De
wp-config.phpbevat de juiste databasegegevens - Redirects van de oude URL naar de nieuwe zijn ingesteld
- E-mailconfiguratie (SMTP of hosting-mail) is getest
Loop deze lijst letterlijk af. Niet uit je hoofd, maar op papier of in een gedeeld document. Bij migraties gaat het mis op het moment dat je denkt dat je het wel weet.
Back-up strategie rondom de migratie
Een back-up maken vóór de migratie is vanzelfsprekend. Maar de meeste mensen vergeten dat je ook ná de migratie een back-up nodig hebt, vóórdat je de DNS omzet.
Waarom? Omdat je op de nieuwe server aanpassingen hebt gedaan: URL’s vervangen, configuraties aangepast, licenties geactiveerd. Die staat is anders dan de originele back-up. Als er na de DNS-wissel iets misgaat, wil je terug naar die geconfigureerde staat, niet naar de ruwe export.
Maak dus drie back-ups:
- Volledige back-up van de oude omgeving vóór de migratie
- Volledige back-up van de nieuwe omgeving na configuratie, vóór DNS-wissel
- Volledige back-up van de nieuwe omgeving na de DNS-wissel en na de eerste week
Gebruik voor back-ups een plugin die zowel bestanden als database exporteert, en sla de bestanden op buiten de server zelf. Een back-up op dezelfde server als de site is geen back-up.
UpdraftPlus is voor de meeste mkb-sites voldoende. Stel in dat back-ups automatisch naar Google Drive, Dropbox of een externe FTP gaan. Controleer maandelijks of de back-ups ook daadwerkelijk worden aangemaakt en of je ze kunt terugzetten.
Veelgestelde vragen over WordPress-migraties
Kan ik een WordPress-site migreren zonder downtime?
Ja, dat kan. Je zet de nieuwe omgeving op terwijl de oude nog live staat. Via je hosts-bestand kun je de nieuwe site lokaal bekijken zonder dat bezoekers er last van hebben. Pas als alles klopt, zet je de DNS om. De enige downtime is de propagatietijd van de DNS, en die is voor bezoekers nauwelijks merkbaar als je de TTL van tevoren verlaagt naar 300 seconden.
Wat doe ik als de site na de migratie een witte pagina geeft?
Dat is bijna altijd een databaseprobleem of een fout in wp-config.php. Zet WP_DEBUG tijdelijk op true in wp-config.php om de foutmelding te zien. Controleer daarna de databasegegevens: naam, gebruiker, wachtwoord en host. Op veel servers is de host niet localhost maar een intern adres. Dat staat in de welkomstmail van je hostingpartij.
Hoe lang duurt een WordPress-migratie gemiddeld?
Voor een eenvoudige site zonder WooCommerce: een uur tot twee uur. Voor een webshop met veel bestellingen, maatwerk en betaalde plugins: reken op een halve dag. De technische overdracht zelf is snel. De tijd gaat zitten in testen, controleren en het oplossen van kleine problemen die je pas ziet als de site op de nieuwe server staat. Plan nooit een migratie op een vrijdagmiddag.