Een website verhuizen zonder downtime is geen kwestie van geluk, maar van volgorde — het geheim is overlap: je laat de oude en de nieuwe hostingomgeving een paar dagen naast elkaar draaien. Je kopieert alles naar de nieuwe server terwijl de oude gewoon live blijft, test de kopie grondig, en pas als alles op de nieuwe kant bewezen werkt "knip" je met een DNS-wijziging. Bezoekers merken er dan niets van, en je mail blijft gewoon binnenkomen; in dit artikel loop ik stap voor stap door hoe dat werkt.
Waarom verhuizingen misgaan (en hoe het wél moet)
De meeste mislukte verhuizingen die ik voorbij zie komen hebben dezelfde oorzaak: er is geen overlap. Iemand zegt het oude pakket op, zet daarna pas de site over, en komt er middenin achter dat er iets mist — een database, de mailboxen, een SSL-certificaat. Op dat moment is de oude omgeving al weg en sta je met lege handen.
Ik migreer wekelijks websites en werk daarbij met een vaste checklist. De klassieke fout die ik bij "zelf verhuisde" sites rechtzet is precies dit: een te vroeg opgezegd oud pakket, waardoor site én mail tegelijk verdwenen. Dat is bijna altijd te voorkomen door één simpele regel: de oude omgeving gaat pas uit als de nieuwe bewezen werkt. Alles in dit artikel volgt uit die regel.
Stap 1: inventariseer wat er allemaal verhuist
Voordat je iets kopieert, breng je in kaart wát er eigenlijk draait. Meer dan je denkt, meestal:
- De websitebestanden. Bij WordPress: de hele installatie inclusief thema's, plugins en uploads.
- De database. Vrijwel elke moderne site heeft er een; een webshop soms meerdere.
- Mailboxen. Welke e-mailadressen bestaan er, hoeveel mail zit erin, en gebruiken mensen IMAP (mail staat op de server) of POP3 (mail staat lokaal)?
- DNS-records. Maak een export of screenshot van de complete zone: A-records, MX, SPF/DKIM/DMARC, subdomeinen, verificatierecords van bijvoorbeeld Google of Microsoft. Records die je vergeet over te nemen, breken pas dagen later — en dan weet niemand meer waarom.
- SSL-certificaat. Gratis (Let's Encrypt) of betaald? Een betaald certificaat wil je meenemen of opnieuw installeren op de nieuwe server.
- Cronjobs en koppelingen. Geplande taken, back-upscripts, API-koppelingen met bijvoorbeeld een boekhoudpakket of betaalprovider. Die staan nergens "in de site" en worden daarom het vaakst vergeten.
Deze inventaris is je verhuislijst. Alles wat erop staat moet straks op de nieuwe server terugkomen — of bewust afgevoerd worden.
Stap 2: verlaag alvast de TTL van je DNS-records
Dit is een kleine stap met groot effect, en je doet hem het liefst een paar dagen van tevoren.
Elk DNS-record heeft een TTL (time to live): de tijd die internetproviders het antwoord mogen onthouden. Staat je TTL op 24 uur, dan kan het na een wijziging tot een dag duren voordat iedereen de nieuwe server ziet. Verlaag je de TTL vooraf naar bijvoorbeeld 300 seconden (5 minuten), dan is de uiteindelijke wissel bijna direct overal door.
Let op de volgorde: de verlaging zelf moet ook eerst "uitgetikt" zijn. Verlaag je de TTL vandaag terwijl hij op 24 uur stond, dan werkt de korte TTL pas morgen echt. Doe dit dus minimaal één oude-TTL-periode vóór de geplande wissel.
Stap 3: kopieer alles naar de nieuwe server — de oude blijft live
Nu zet je de complete site over naar de nieuwe hosting: bestanden, database, configuratie. Het belangrijkste hierbij is wat je niet doet: je verandert nog niets aan de oude omgeving. Geen DNS-wijziging, geen opzegging, geen "site tijdelijk offline"-pagina. De oude server bedient gewoon alle bezoekers, alsof er niets aan de hand is.
Bij een site die veel verandert — een webshop met bestellingen, een site met een druk gebruikt formulier — plan je vlak voor de definitieve wissel een tweede, korte synchronisatie. Zo neem je de bestellingen en aanmeldingen mee die binnenkwamen tussen de eerste kopie en het moment van omzetten. Bij een rustige bedrijfssite is één kopie meestal genoeg.
Stap 4: test op de nieuwe server vóór de DNS-wissel
Dit is de stap die downtime voorkomt, en tegelijk de stap die het vaakst wordt overgeslagen. Je wilt de site op de nieuwe server volledig kunnen bekijken en testen, terwijl de rest van de wereld nog de oude ziet. Daar zijn twee manieren voor.
De hosts-bestand-truc, uitgelegd voor een leek
Je computer vraagt normaal aan het DNS-systeem: "welk IP-adres hoort bij mijnbedrijf.nl?" Maar er is een bestand op je eigen computer dat vóór die vraag gaat: het hosts-bestand. Zet je daar een regel in als:
203.0.113.45 mijnbedrijf.nl www.mijnbedrijf.nl
…dan gaat alleen jouw computer voortaan naar dat IP-adres (het adres van je nieuwe server), terwijl al je bezoekers gewoon nog op de oude site zitten. Je surft dus naar je eigen domeinnaam, maar kijkt naar de nieuwe server. Perfect om te testen.
Op Windows vind je het bestand in C:\Windows\System32\drivers\etc\hosts (openen als administrator), op een Mac in /etc/hosts (via de Terminal, met sudo). Regel toevoegen, opslaan, browser herstarten — en niet vergeten hem er na de verhuizing weer uit te halen.
Of: een tijdelijke test-URL
Vind je het hosts-bestand te technisch, dan werkt een tijdelijke test-URL ook: veel hosters kunnen de site bereikbaar maken op iets als test.mijnbedrijf.nl of een preview-adres van het hostingpaneel. Nadeel: sommige sites (zeker WordPress) zijn gevoelig voor het draaien onder een andere URL, dus de hosts-truc geeft het eerlijkste beeld.
Wat test je?
Loop in elk geval na: laden alle pagina's (ook diepere pagina's, niet alleen de homepage)? Werken afbeeldingen en downloads? Kun je inloggen in het beheer? Komen contactformulieren écht aan in je mailbox? Werkt bij een webshop een testbestelling van begin tot eind? Alles wat hier hapert, los je nú op — met de oude site nog gewoon live is er geen enkele haast.
Stap 5: zet SSL klaar vóór de wissel
Een valkuil die vaak voor het enige zichtbare "downtime-moment" zorgt: de DNS wijst al naar de nieuwe server, maar daar staat nog geen geldig SSL-certificaat. Bezoekers krijgen dan een schreeuwende beveiligingswaarschuwing — voor hen voelt dat als een kapotte site.
Regel het certificaat daarom vóóraf. Een betaald certificaat kun je meestal exporteren en op de nieuwe server importeren. Een gratis Let's Encrypt-certificaat kan lastiger zijn zolang de DNS nog naar de oude server wijst, maar er zijn oplossingen: uitgifte via een DNS-validatie, of het bestaande certificaat tijdelijk meenemen. Hoe dan ook: op het moment van de wissel moet HTTPS op de nieuwe server gewoon werken.
Stap 6: plan de mail apart
Website en e-mail lijken één geheel, maar technisch zijn het twee losse verhuizingen. De site hangt aan de A-records van je domein, de mail aan de MX-records (zie DNS-records uitgelegd als deze termen nieuw voor je zijn). Je hoeft ze dus niet tegelijk om te zetten — en meestal is dat ook onverstandig.
De veilige volgorde voor mail:
- Maak alle mailboxen aan op de nieuwe server, met dezelfde adressen.
- Kopieer de inhoud van de oude mailboxen naar de nieuwe, via een IMAP-synchronisatie. Bij grote mailboxen kan dat uren duren — geen probleem, de oude omgeving draait gewoon door.
- Zet de MX-records pas om als de nieuwe mailomgeving compleet is: mailboxen gevuld, SPF/DKIM/DMARC-records aangepast, verzenden en ontvangen getest.
- Draai een nasynchronisatie voor mail die tijdens de overgang nog op de oude server binnenkwam.
Goed om te weten: mailservers zijn vergevingsgezind. Kan een mail even niet afgeleverd worden, dan probeert de verzendende server het dagen achtereen opnieuw. Mail gaat bij een nette verhuizing dus niet verloren — hij komt hooguit een paar minuten later binnen.
Wil je het jezelf makkelijk maken: verhuis eerst de website, laat de mail een week op de oude plek staan, en pak de mailverhuizing daarna op als apart klusje.
Stap 7: de DNS-wissel zelf
Als de nieuwe site getest is, SSL klaarstaat en de TTL laag is, is de eigenlijke "verhuizing" verrassend klein: je past een paar DNS-records aan.
- Het A-record van je domein (en van
www) zet je op het IP-adres van de nieuwe server. Vanaf dat moment komen bezoekers op de nieuwe site uit. - De MX-records zet je om zodra de mailomgeving klaar is — dat mag dus op een ander moment.
- Soms wissel je in plaats daarvan de nameservers van het hele domein. Dat kan, maar neem dan wél eerst álle bestaande records over in de nieuwe DNS-zone, anders breek je alsnog mail of subdomeinen.
Hoe lang duurt het naijlen? Met een vooraf verlaagde TTL van 5 minuten zien de meeste bezoekers de nieuwe server binnen enkele minuten; vrijwel iedereen binnen een uur. Heb je de TTL niet verlaagd, reken dan op enkele uren tot 24 uur waarin een deel van de bezoekers nog op de oude server uitkomt. En dat is precies waarom de overlap zo belangrijk is: in die overgangsperiode draaien beide servers dezelfde werkende site, dus niemand merkt iets. Er is geen moment waarop het "even plat ligt".
Kies voor de wissel een rustig moment — een doordeweekse avond bijvoorbeeld — niet omdat er downtime is, maar omdat je dan rustig kunt controleren en er weinig bestellingen of formulieren "tussen wal en schip" kunnen belanden.
Stap 8: nazorg — en het oude pakket pas láter opzeggen
Na de wissel ben je nog niet klaar. De belangrijkste nazorgpunten:
- Laat de oude omgeving nog één à twee weken draaien. Hij vangt achterblijvers op (bezoekers met oude DNS-cache, mailservers met oude MX-informatie) en dient als vangnet als er toch iets mis blijkt.
- Test opnieuw op de live nieuwe omgeving: formulieren, inloggen, en bij een webshop een echte testbestelling inclusief betaling. Betaalproviders werken soms met IP-whitelisting of callback-URL's die na een serverwissel bijgewerkt moeten worden.
- Controleer de cronjobs. Draaien de geplande taken (back-ups, importscripts, WordPress-cron) op de nieuwe server? Dit valt niet op tot het misgaat.
- Zet de TTL weer terug naar een normale waarde (bijvoorbeeld een uur of langer).
- Haal de hosts-regel weg op je testcomputer, anders kijk je zelf voor eeuwig naar de "verkeerde" server zodra er ooit weer iets wijzigt.
- Zeg het oude pakket pas op als alles bewezen werkt. Nooit vooraf, nooit "alvast om dubbele kosten te besparen". Die ene of twee weken dubbele hosting kosten een paar euro; een verdwenen site met mailboxen kost dagen herstelwerk — als herstel überhaupt nog kan. Dit is met afstand de duurste fout die ik in de praktijk tegenkom.
Checklist: website verhuizen zonder downtime
- Inventariseer: bestanden, database, mailboxen, complete DNS-zone, SSL, cronjobs en koppelingen.
- Verlaag de TTL van je DNS-records naar ± 300 seconden (minimaal één oude TTL-periode vooraf).
- Kopieer site en database naar de nieuwe server; de oude blijft onaangeroerd live.
- Test op de nieuwe server via het hosts-bestand of een test-URL: pagina's, inloggen, formulieren, bestellingen.
- Zet SSL werkend klaar op de nieuwe server.
- Plan mail apart: mailboxen aanmaken, IMAP-sync, dan pas MX omzetten, daarna nasync.
- Wissel het A-record (en later de MX) op een rustig moment.
- Test live opnieuw: formulieren, betalingen, cronjobs; zet de TTL terug en verwijder de hosts-regel.
- Laat de oude omgeving 1–2 weken meedraaien als vangnet.
- Zeg het oude pakket pas op als alles aantoonbaar goed draait.
Houd je deze volgorde aan, dan is een verhuizing geen spannend moment maar een gecontroleerd proces — en merken je bezoekers er letterlijk niets van.