Je hebt besloten om te migreren. De strategie is bepaald, de provider gekozen. Nu komt het erop aan. Want het verschil tussen een migratie die soepel verloopt en een die eindigt in een weekend vol paniek zit niet in de technologie. Het zit in de voorbereiding.
Dit artikel is een praktische gids. Geen abstracte frameworks, maar concrete stappen. Wat doe je eerst, wat doe je daarna, en waar gaat het mis als je stappen overslaat.
Stap 1: Inventariseer wat je hebt
Voordat je iets verplaatst, maak je een complete inventaris. Dat klinkt als vanzelfsprekend, en toch is het de stap die het vaakst wordt overgeslagen. Het gevolg: halverwege de migratie ontdek je een database die je vergeten was, een cronjob die niemand meer kent, of een integratie met een extern systeem die niet gedocumenteerd is.
Wat je in kaart brengt:
Applicaties en diensten. Welke websites, applicaties, API's en achtergrondprocessen draaien er? Op welke servers? Met welke versies van welke software? Documenteer ook de webserver (Apache, Nginx, IIS), de programmeertaal en het framework, de databaseserver en -versie, en eventuele caching-lagen (Redis, Memcached, Varnish).
Data. Hoeveel data heb je? Waar staat het? Databases, bestanden, media, back-ups, logs. Wat is de totale omvang, en wat is de dagelijkse groei? Dit bepaalt hoe lang een datamigratie duurt en welke methode je gebruikt.
Afhankelijkheden. Welke systemen praten met welke andere systemen? Externe API's, betaalproviders, e-mailservers, DNS, CDN, monitoring. Teken het uit. Je wilt geen verrassingen op het moment dat je de DNS omschakelt.
Configuratie. Serverinstellingen, environment variables, SSL-certificaten, firewall-regels, scheduled tasks. Alles wat niet in je code of database zit maar wel nodig is om je applicatie te laten werken.
Stap 2: Bereid de doelomgeving voor
Richt je nieuwe omgeving in voordat je data gaat verplaatsen. Installeer de juiste softwareversies. Configureer de webserver. Zet firewall-regels op. Maak databaseservers aan. Configureer SSL-certificaten.
Test de doelomgeving met een minimale versie van je applicatie. Draait de software? Kloppen de permissies? Kan de applicatie verbinding maken met de database? Werkt de e-mailfunctionaliteit? Los problemen op voordat je aan de datamigratie begint. Elke minuut die je nu besteedt aan het goed inrichten van de doelomgeving bespaar je drievoudig tijdens de migratie zelf.
Een punt dat vaak vergeten wordt: tijdsinstellingen. Controleer of de tijdzone van je nieuwe server overeenkomt met wat je applicatie verwacht. Een verschil van een uur kan cronjobs op het verkeerde moment starten en timestamps in je database verkeerd weergeven.
Stap 3: Back-up alles
Maak een volledige back-up van je huidige omgeving. Niet alleen de database, niet alleen de bestanden, maar alles. Database-dumps, applicatiebestanden, media-uploads, configuratiebestanden, SSL-certificaten, cronjob-definities, firewall-regels.
Bewaar deze back-up op een locatie die onafhankelijk is van zowel je oude als je nieuwe omgeving. Een externe opslagdienst, een lokale schijf, een tweede server. Als zowel de migratie als de rollback misgaat, is deze back-up je laatste redmiddel.
Verifieer je back-up. Een back-up die je niet hebt getest is geen back-up, het is een aanname. Restore de database-dump naar een testomgeving. Controleer of bestanden compleet zijn. Check de integriteit met checksums.
Stap 4: Verlaag je DNS TTL
Dit is een stap die je minimaal 24 tot 48 uur voor de daadwerkelijke migratie moet zetten. DNS-records hebben een TTL (time to live): de tijd die DNS-resolvers het record cachen voordat ze het opnieuw opvragen. Een standaard TTL is vaak 3600 seconden (een uur) of langer. Sommige domeinen staan op 86400 seconden (24 uur).
Verlaag de TTL naar het minimum dat je provider toestaat. Bij Cloudflare is dat 120 seconden. Bij de meeste registrars is 300 seconden (5 minuten) haalbaar. Doe dit ruim van tevoren, want de oude TTL moet eerst verlopen voordat de nieuwe waarde effect heeft.
Waarom dit ertoe doet: op het moment dat je de DNS wijzigt naar je nieuwe server, wil je dat alle bezoekers zo snel mogelijk de nieuwe server bereiken. Met een TTL van 24 uur kunnen bezoekers tot een dag na de overschakeling nog op je oude server uitkomen. Met een TTL van 5 minuten is dat venster vijf minuten.
Migratie in 8 stappen
Stappen 1-4 = voorbereiding (doe ze ruim van tevoren). Stappen 5-8 = uitvoering (plan ze in een migratievenster).
Stap 5: Migreer je data
Nu begint de daadwerkelijke verhuizing. De methode hangt af van de hoeveelheid data en het type applicatie.
Bestanden. Voor websites en applicaties met bestandsopslag (media-uploads, documenten, configuratie) is rsync de standaard. Het kopieert alleen gewijzigde bestanden, wat herhaalde synchronisatie snel maakt. Je kunt rsync al draaien voordat de daadwerkelijke migratie plaatsvindt: een eerste sync kopieert alles, en vlak voor de DNS-switch draai je een laatste sync om recente wijzigingen mee te nemen.
Databases. Voor MySQL en MariaDB is mysqldump de meest gebruikte methode. Bij grote databases (tientallen gigabytes) is mysqldump traag. Overweeg dan mydumper voor parallelle dump en restore, of gebruik fysieke back-upmethoden als de databaseversie op bron en doel identiek is. PostgreSQL-gebruikers hebben pg_dump en pg_restore.
Bij applicaties met actieve gebruikers is het synchronisatiemoment kritiek. Tussen je laatste database-export en de DNS-switch mogen geen schrijfacties plaatsvinden op de oude database. De schoonste aanpak: zet de oude applicatie tijdelijk in maintenance-mode, exporteer de database, importeer op de nieuwe server, test, en schakel dan pas de DNS om.
Stap 6: Test op de nieuwe omgeving
Je data staat op de nieuwe server. De applicatie draait. Maar de DNS wijst nog naar de oude server. Dat is precies wat je wilt: je kunt nu testen zonder dat bezoekers de nieuwe omgeving zien.
De makkelijkste manier om te testen is via je lokale hosts-bestand. Voeg een regel toe die je domeinnaam naar het IP-adres van de nieuwe server wijst. Op macOS en Linux staat dat bestand op /etc/hosts, op Windows op C:\Windows\System32\drivers\etc\hosts. Nu bereik je via je browser de nieuwe server terwijl de rest van de wereld nog naar de oude gaat.
Wat test je:
- Laadt de website correct?
- Werken alle pagina's?
- Zijn afbeeldingen en bestanden beschikbaar?
- Werkt het contactformulier?
- Worden e-mails verstuurd?
- Werkt de betaalmodule?
- Kloppen de database-gegevens?
- Zijn scheduled tasks ingericht?
- Werkt het SSL-certificaat?
- Wordt HTTP correct doorgestuurd naar HTTPS?
Test ook de prestaties. Vergelijk laadtijden met de oude omgeving. Als de nieuwe server in een ander datacenter staat, verandert de latency naar externe diensten. Database-queries die lokaal snel waren kunnen trager worden als de afstand groter is.
Stap 7: DNS omschakelen
Alles is getest. De nieuwe omgeving werkt. Nu het moment van de waarheid: de DNS-switch.
Wijzig het A-record (of AAAA-record voor IPv6) van je domein naar het IP-adres van de nieuwe server. Als je de TTL in stap 4 hebt verlaagd, zouden de meeste bezoekers binnen vijf tot tien minuten op de nieuwe server uitkomen.
Schakel de oude server niet direct uit. Houd hem minimaal 48 tot 72 uur draaiend. DNS-propagatie is niet instant en niet uniform. Sommige ISP's negeren TTL-waarden en cachen langer. Zolang er een kans is dat bezoekers de oude server bereiken, moet die server nog een bruikbare versie van je site tonen. Zet desnoods een maintenance-pagina neer met een link naar het nieuwe adres.
Bij websites met actieve schrijfoperaties (webshops, forums, CMS met meerdere redacteuren) is het verstandig om na de DNS-switch de oude applicatie in read-only mode te zetten. Dat voorkomt dat data wordt geschreven naar de oude database die niet meer wordt gesynchroniseerd.
Stap 8: Monitor en ruim op
De eerste 72 uur na de migratie zijn de belangrijkste. Monitor actief op fouten: 500-errors in je serverlog, langzame queries in je database, mislukte cronjobs, bouncing e-mails. Zet alerts in voor downtime.
Controleer je zoekmachineverkeer. Een migratie kan tijdelijk effect hebben op je SEO als URL-structuren zijn veranderd of als de server trager reageert. Monitor Google Search Console op crawlfouten.
Als alles stabiel draait na 72 uur:
Herstel je DNS TTL naar de normale waarde (meestal 3600 seconden). Schakel de oude server uit. Bewaar je pre-migratie back-up nog minimaal 30 dagen. Documenteer de migratie: wat heb je gedaan, welke problemen kwamen je tegen, wat zou je de volgende keer anders doen.
Downtime voorkomen: risico's en maatregelen
De meeste downtime ontstaat niet door technische fouten, maar door overgeslagen voorbereiding.
Specifieke scenario's
WordPress migreren
WordPress is veruit het meest gemigreerde platform. De kern: exporteer de database (wp_options bevat je site-URL, die moet je aanpassen), kopieer wp-content (je themes, plugins en uploads), en zorg dat de PHP-versie en extensies overeenkomen. Plugins als Duplicator of All-in-One WP Migration kunnen het proces vereenvoudigen, maar bij grote sites (meer dan een paar gigabyte media) loop je tegen uploadlimieten aan en is handmatige migratie betrouwbaarder.
Let specifiek op: wp-config.php (databaseverbinding en salts), .htaccess (rewrite rules), en eventuele server-level caching configuratie. Na de migratie: permalinks opnieuw opslaan (lost de meeste 404-fouten op) en alle cache legen.
Webshop migreren
Webshops hebben een extra complicatie: lopende bestellingen en betalingen. Plan de migratie buiten piekuren (dinsdagnacht of woensdagnacht zijn doorgaans het rustigst). Zet de shop in maintenance-mode voordat je de laatste database-sync doet. Controleer na de migratie dat de betaalprovider correct is geconfigureerd op de nieuwe omgeving: webhook-URL's moeten naar het nieuwe IP wijzen, en sommige betaalproviders (Mollie, Stripe, Adyen) valideren het SSL-certificaat van de webhook-URL.
Meerdere sites op een server
Als je meerdere websites op een server hebt staan, migreer dan niet alles tegelijk. Verplaats eerst de minst kritieke site. Leer van de ervaring. Pas je proces aan. En verplaats dan de volgende. Het is verleidelijk om alles in een keer te doen, maar het risico vermenigvuldigt zich met elke site die je toevoegt aan het migratievenster.
De kern
Een migratie is geen technisch huzarenstukje. Het is een gestructureerd proces van acht stappen, waarvan de helft voorbereiding is. Wie de voorbereiding serieus neemt komt uit op een migratie met minimale downtime, geen dataverlies en geen verrassingen op maandagochtend.
De technische stappen zijn gedocumenteerd en bewezen. Wat ze laat slagen is niet technische genialiteit maar discipline: inventariseren wat je hebt, testen voordat je schakelt, monitoren nadat je schakelt, en altijd een rollback-plan hebben.