Een hostingmigratie zonder downtime klinkt als een belofte die alleen grote cloudproviders waar kunnen maken. Toch is het met de juiste voorbereiding voor vrijwel elke website haalbaar, of je nu een blog verhuist, een webshop of een complete SaaS-applicatie. De sleutel zit niet in magische software, maar in een doordachte volgorde van stappen.
In deze gids loop je door het volledige proces: van de eerste inventarisatie tot de laatste DNS-switch. Je leest welke valkuilen de meeste downtime veroorzaken en hoe je ze voorkomt met een korte TTL, een slimme database-sync en een helder rollback-plan.
Waarom zero downtime steeds belangrijker wordt
Bezoekers zijn ongeduldig. Een foutmelding of witte pagina is vaak genoeg om ze naar de concurrent te sturen. Voor webshops vertaalt elke minuut downtime zich direct in gemiste omzet, en Google houdt rekening met beschikbaarheid bij het bepalen van rankings.
Daarnaast draaien veel moderne sites op API-integraties, betaalkoppelingen of webhooks die geen storing verdragen. Een paar minuten offline kan betekenen dat bestellingen vastlopen of synchronisaties met externe systemen corrupt raken.
Een migratie zonder downtime is daarom niet langer een luxe, maar een operationele standaard. Het vraagt wel meer planning dan een "kopieer en knip"-verhuizing.
De voorbereidingsfase: weten wat je migreert
Voordat je ook maar één bestand verplaatst, wil je precies weten wat er op de oude server draait. Een volledige inventarisatie voorkomt verrassingen achteraf.
Inventariseer alles wat draait
Maak een checklist van:
- Websites, subdomeinen en bijbehorende documentroots
- Databases, gebruikers en rechten
- Cronjobs en achtergrondprocessen
- Mailaccounts, forwarders en DKIM/SPF-records
- SSL-certificaten en hun vervaldatums
- Custom configuratie in Apache, NGINX of PHP-FPM
- Externe integraties en IP-whitelists
Vergeet ook zaken als cPanel of Plesk-specifieke instellingen niet. Sommige control panels exporteren alles in één account-backup, maar lang niet alle features zijn cross-compatibel.
Controleer de nieuwe omgeving
De nieuwe server moet minstens gelijkwaardig zijn aan de oude. Controleer PHP-versie, database-engine, Node-versie en beschikbare extensies. Als je migreert naar een VPS, lees dan ook onze introductie tot VPS hosting voor een overzicht van wat je zelf moet configureren.
Plan een testomgeving op de nieuwe server met een alternatief domein of een hosts-file override. Zo kun je alles testen voordat er één bezoeker op terechtkomt.
DNS voorbereiden: de TTL verlagen
De meest onderschatte stap in een zero-downtime migratie is DNS. Zonder voorbereiding kan een DNS-wijziging tot 48 uur rondreizen over het internet. Met voorbereiding is dat binnen 5 minuten geregeld.
Verlaag de TTL ruim op tijd
Ga naar je DNS-provider en zet de TTL van je A- en AAAA-records minstens 24 tot 48 uur vóór de migratie op een lage waarde, bijvoorbeeld 300 seconden (5 minuten). Resolvers wereldwijd hanteren dan vanaf de migratiedag dezelfde korte cache.
Wacht je hier niet mee: een TTL verlagen op het moment van de switch heeft geen effect, want resolvers gebruiken nog de oude (hogere) waarde uit hun cache.
Bereid de nieuwe records voor
Zet de nieuwe IP-adressen alvast klaar in een tekstbestand of ticket. Zorg dat je zowel IPv4 als IPv6 hebt. Draait je nieuwe host op IPv6 hosting, dan moet ook het AAAA-record kloppen. Voor een dieper begrip van hoe DNS werkt, zie onze uitleg over DNS voor developers.
Files synchroniseren: rsync is je beste vriend
De bestanden zelf verplaatsen is technisch het minst spannende onderdeel, zolang je het in de juiste volgorde doet.
Eerste synchronisatie
Een paar dagen voor de migratie start je een eerste volledige rsync van de oude naar de nieuwe server:
rsync -avz --delete /var/www/ user@nieuwe-server:/var/www/
Dit kan uren duren bij grote sites, maar de site blijft gewoon online. Daarna draai je incrementele sync-rondes. Elke ronde pakt alleen de wijzigingen sinds de vorige.
De delta-sync vlak voor de switch
Op het moment van de switch draai je nog één laatste delta-sync. Omdat de meeste data al synchroon is, duurt dit meestal seconden. Voor sites met veel user-uploads (denk aan webshops met productafbeeldingen) is dit verschil cruciaal.
Vergeet niet rechten en eigenaren mee te nemen met de juiste vlaggen, anders kan PHP-FPM straks niet naar logs of cache schrijven.
De database: de lastigste schakel
Files zijn te rsyncen terwijl de site draait. Bij databases ligt dat anders, een inconsistente dump levert corrupte data op.
Optie 1: replicatie opzetten
Voor MySQL of MariaDB is master-slave replicatie de elegantste oplossing. Je zet de nieuwe server op als read-only replica van de oude. Alle schrijfacties worden automatisch gerepliceerd. Op het moment van de switch promoveer je de replica naar master en herstart je de applicatie tegen de nieuwe host.
Deze aanpak geeft je een datakloof van hooguit enkele seconden, en soms zelfs nul.
Optie 2: read-only window
Is replicatie technisch niet haalbaar? Plan dan een kort read-only venster. Zet de site in maintenance-mode (of beter: in read-only modus voor formulieren en checkouts), dump de database, importeer op de nieuwe server, en switch DNS.
Bij een goed voorbereide migratie duurt dit window 2 tot 10 minuten. Plan het strategisch buiten piekuren, kijk eerst in je analytics wanneer je daluren vallen.
Optie 3: dubbelschrijven via de applicatie
Voor grote platformen is er nog een derde route: de applicatie schrijft tijdelijk naar beide databases tegelijk. Pas als data honderd procent synchroon is, switch je reads over. Dit is complex om te bouwen, maar voor missiekritische systemen het enige echte zero-downtime pad.
De switch: DNS omzetten op het juiste moment
Nu alles klaarstaat, komt het moment van waarheid.
De volgorde tijdens de knip
- Laatste rsync-delta draaien
- Database-sync afronden (replicatie promoveren of dump/import)
- Applicatie op de nieuwe server starten en valideren via hosts-file test
- SSL-certificaat verifiëren op de nieuwe server
- DNS-records wijzigen naar de nieuwe IP-adressen
- Oude server in read-only laten draaien als fallback
Dankzij de lage TTL is het verkeer binnen 5 minuten grotendeels overgegaan. Kijk in de access logs van beide servers om te volgen hoe het verkeer verschuift.
Houd de oude server minimaal een week actief
Ook als het verkeer lijkt te zijn overgeschakeld, blijft er soms nog een lange tijd verkeer binnenkomen op de oude server. Dit komt door resolvers die zich niet aan de TTL houden, hardcoded IP-adressen in externe systemen of corporate DNS-caches.
Laat de oude omgeving daarom minstens 7 tot 14 dagen draaien. Zet logging aan zodat je ziet of er nog requests binnenkomen. Pas als het echt stil is, kun je opzeggen.
SSL, mail en de randgevallen
Twee dingen worden tijdens hostingmigraties vaak vergeten: certificaten en e-mail.
SSL-certificaten
Installeer het SSL-certificaat op de nieuwe server voordat je DNS omzet. Anders krijgen bezoekers een browser-waarschuwing op het moment van de switch. Gebruik je Let's Encrypt, dan kun je een certificaat op beide servers tegelijk actief hebben. Meer over certificaten lees je in onze gids over SSL certificaten en HTTPS.
Een handige tool om te testen is SSL Labs, draai hem zowel voor als na de switch.
E-mail en MX-records
Verhuis je ook mail, dan is de volgorde anders. MX-records laat je pas verhuizen als álle mail uit de oude mailbox is overgezet. Een mismatch tussen A-records en MX-records is onhandig maar zelden catastrofaal.
Cruciaal: update je SPF, DKIM en DMARC-records. Vergeet je deze, dan belandt je mail na de switch massaal in de spamfolder.
Rollback-plan: hopen op het beste, klaar voor het slechtste
Zelfs bij de beste voorbereiding kan er iets misgaan. Een productiebug die pas onder echte load opduikt, een database-index die niet mee is gekopieerd, of een cronjob die dubbel draait op beide servers.
Zorg daarom voor:
- Een verse backup vlak voor de switch, opgeslagen buiten beide servers
- Duidelijke afspraken wie de knop omdraait bij problemen
- Een procedure om DNS terug te zetten (vergeet de TTL niet)
- Een communicatielijn richting eventuele klanten of collega's
Voor webshops is het extra belangrijk dat bestellingen tijdens de switch niet verloren gaan. Combineer de migratie idealiter met een korte checkout-freeze. Een goed backup-regime is sowieso een must, migratie of niet.
Na de migratie: valideren en opruimen
De eerste 24 uur na de switch zijn kritiek. Monitor actief:
- Response times en error rates via bijvoorbeeld een APM-tool
- Database-queries: duren ze niet opeens langer?
- Mailstromen: komen verzonden mails nog aan?
- Externe integraties: werken webhooks nog?
- SEO-indicatoren: kijk in Search Console of er opeens crawlerrors zijn
Deze fase bepaalt of je migratie echt succesvol is. Een site die draait maar traag is geworden, heeft alsnog impact op SEO en conversie. Zie ook waarom snelle hosting je SEO beïnvloedt.
Is alles stabiel, dan kun je na een week de oude omgeving afbouwen. Maak een laatste backup, zeg het account op en update je interne documentatie met de nieuwe servergegevens.
Wanneer je beter niet zelf migreert
Hoewel dit stappenplan technisch haalbaar is, zijn er situaties waarin je beter hulp inschakelt:
- Je hebt meer dan 50GB data of een database groter dan 10GB
- Je site draait op een complex cluster met load balancers of caches
- Je hebt strikte compliance-eisen (AVG, PCI-DSS, ISO)
- De downtime-kosten liggen hoger dan de migratiekosten
In die gevallen werkt de managed hosting-route vaak sneller én veiliger. Providers als Hostbit verhuizen dagelijks sites en kennen de valkuilen van binnenuit. Voor een gefundeerde keuze over je nieuwe host, check onze gids hoe kies je de juiste hosting provider.
Conclusie: planning verslaat paniek
Een hostingmigratie zonder downtime is geen kwestie van geluk, maar van planning. Door de TTL vooraf te verlagen, files incrementeel te syncen, de database slim te kopiëren en een rollback-plan klaar te hebben, reduceer je de switch tot een handeling van enkele minuten.
De meeste mislukte migraties stranden niet op techniek, maar op onderschatte details: een vergeten cronjob, een DNS-record dat niet is meegenomen, een SSL-certificaat dat pas na de switch wordt geregeld. Werk daarom met een checklist, test op een staging-omgeving en houd de oude server langer actief dan je denkt nodig te hebben.
Doe je het goed, dan merkt geen enkele bezoeker dat je site is verhuisd. En dat is precies het doel.
Veelgestelde vragen
Hoe lang duurt een hostingmigratie zonder downtime?
De voorbereiding kost meestal 1 tot 3 dagen, de eigenlijke switch is vaak binnen enkele minuten gedaan. Dynamische websites met databases en veel gebruikers vragen meer tijd dan statische sites.
Wat is de grootste oorzaak van downtime bij een migratie?
DNS-propagatie die te laat wordt ingepland en een database die tijdens de knip nog schrijft op de oude server. Met een lage TTL en een korte read-only window voorkom je beide problemen.
Moet ik mijn bezoekers waarschuwen voor de migratie?
Bij een echte zero-downtime migratie is dat niet nodig. Plan de switch wel buiten piekuren en communiceer proactief met klanten die afhankelijk zijn van je uptime, bijvoorbeeld via een statuspagina.
Kan ik zelf migreren of heb ik mijn hostingprovider nodig?
Eenvoudige sites kun je zelf verhuizen met rsync en een database-dump. Voor complexe setups met mail, cronjobs en custom configuraties werk je beter samen met je nieuwe hostingprovider.
Wat doe ik als er tijdens de migratie iets misgaat?
Houd een rollback-plan klaar. Laat de oude omgeving minimaal 7 dagen actief na de switch en bewaar een verse backup buiten beide servers. Zo kun je bij problemen binnen minuten terug.