Je website naar een nieuwe host verhuizen zonder downtime

Een website naar een nieuwe host verhuizen klinkt riskant, maar met een duidelijk plan is het een rustige, voorspelbare klus. De truc is om de nieuwe kopie te bouwen en te testen terwijl de oude gewoon bezoekers blijft bedienen, en pas daarna je domein door te verwijzen. Deze gids loopt het hele proces door voor een gewone kleine site. WordPress is het belangrijkste voorbeeld, en statische sites en eigen PHP-sites komen in grote lijnen aan bod.

Bepaal wanneer je verhuist en maak een overzicht van wat je hebt

Goede redenen om te verhuizen zijn herhaaldelijk trage laadtijden of storingen, een pakket dat niet meer past bij je verkeer, ontbrekende functies zoals een actuele PHP-versie of staging-tools, slechte support, of een verlengingsprijs die hoger is geworden dan de dienst waard is. Slechte redenen zijn een enkele slechte middag of een opvallende aanbieding die je niet goed hebt vergeleken. Weeg je nog je opties af? Onze gids over hoe je webhosting kiest laat zien waar je op moet letten, en die over verlengingsprijzen van hosting legt uit waarom de kosten na de eerste periode vaak veranderen.

Kies een rustige periode voor de verhuizing. Voor de meeste sites is dat een doordeweekse avond of een weekend met weinig verkeer, en nooit de week van een grote uitverkoop, lancering of campagne. Geef jezelf een paar dagen marge, ook als het eigenlijke werk maar een paar uur duurt.

Schrijf op voordat je iets aanraakt wat je huidige host allemaal voor je doet. Sites hangen vaak af van dingen waarvan niemand meer weet dat ze zijn ingesteld. Hieronder staat een eenvoudig overzicht om in te vullen.

Exporteer je huidige DNS-zone als tekst of maak screenshots van elk record. Deze ene stap voorkomt meer paniek na de verhuizing dan welke andere ook. Controleer ook of je domeinregistratie en je hosting bij hetzelfde bedrijf lopen. Weet je niet goed hoe die twee samenhangen? Domeinnamen en hosting legt het verband uit.

Maak een back-up, bouw de nieuwe site en test hem privé

Maak een volledige back-up van bestanden en databases en bewaar die ergens anders dan bij de oude host, bijvoorbeeld op je eigen computer en op een tweede plek. Vertrouw niet alleen op de automatische back-ups van de host, want je kunt de toegang kwijtraken als het account wordt gesloten. Controleer of de back-up echt opent. Een back-up die je nooit hebt teruggezet is slechts een hoop.

De nieuwe host instellen

Maak het account of pakket aan, voeg je domein toe als site of addon-domein, en kies dezelfde hoofdversie van PHP als je site nu draait, of een nieuwere waarvan je zeker weet dat je code die ondersteunt. Maak een lege database en een databasegebruiker met een sterk wachtwoord. Verander de DNS nog niet. In dit stadium is de nieuwe host gewoon een lege kamer die op je meubels wacht.

Bestanden en database kopiëren

Upload je bestanden via SFTP of de bestandsbeheerder in het controlepaneel. SFTP verdient de voorkeur boven gewone FTP, omdat je inloggegevens dan versleuteld worden. Pak bij een grote site de map in tot één archief, upload dat en pak het op de server uit. Dat gaat veel sneller dan duizenden kleine bestanden versturen.

Exporteer daarna je database bij de oude host en importeer die bij de nieuwe. Voor WordPress zijn er twee gebruikelijke routes. Je kunt een migratieplugin gebruiken die bestanden en database samen verpakt, of je doet het handmatig: kopieer de bestanden, importeer de database en pas dan het bestand wp-config.php aan met de nieuwe databasenaam, gebruiker en wachtwoord. Een statische site heeft alleen de bestanden nodig. Een eigen PHP-site heeft de bestanden en de database nodig, plus een zorgvuldige blik op elk configuratiebestand waarin paden, inloggegevens of API-sleutels staan.

Testen voordat je overschakelt

Controleer nu de nieuwe kopie terwijl het publiek nog de oude ziet. Er zijn twee betrouwbare manieren om dat te doen.

• Pas je hosts-bestand aan. Voeg op je eigen computer een regel toe die je domeinnaam koppelt aan het IP-adres van de nieuwe server. Je browser laadt dan de nieuwe kopie, terwijl iedereen anders nog de oude ziet. Verwijder de regel als je klaar bent.
• Gebruik een tijdelijke URL. Veel hosts geven nieuwe accounts een voorbeeldadres. Dat is makkelijker, al sturen sommige toepassingen, waaronder WordPress, je misschien terug naar het echte domein. Daarom is de methode met het hosts-bestand meestal overzichtelijker.

Klik tijdens het testen door de homepage, een paar subpagina's, zoekfunctie, formulieren, logins, de checkout als je die hebt, en fotogalerijen. Verstuur een testbericht via het contactformulier en controleer of de e-mail aankomt. Let op kapotte afbeeldingen, waarschuwingen voor gemengde inhoud en foutpagina's. Vergelijk de nieuwe kopie naast de oude.

Verlaag de TTL, bevries wijzigingen en schakel de DNS om

DNS is het systeem dat je domeinnaam omzet in een serveradres. Elk DNS-record heeft een TTL, kort voor time to live, die andere netwerken vertelt hoe lang ze het antwoord mogen onthouden voordat ze opnieuw vragen. Als je TTL een dag duurt, blijven sommige bezoekers na de omschakeling mogelijk tot een dag lang naar de oude server gaan.

Verlaag minstens twee dagen voor de verhuizing de TTL van je belangrijkste records naar iets kort, zoals vijf minuten. Dit moet vroeg gebeuren, want de oude lange TTL moet eerst overal verlopen. Een uur voor de omschakeling verlagen helpt nauwelijks.

Wijzigingen in content bevriezen

Zodra je definitieve kopie klaar is, stop je wijzigingen op de oude site. Een blog kan gewoon even niet publiceren. Een webshop is lastiger, want bestellingen die na je laatste databasekopie op de oude server binnenkomen, bestaan niet op de nieuwe. Plan voor winkels, ledensites en forums een kort onderhoudsvenster, maak de laatste databasekopie aan het begin ervan en voorkom bestellingen in de tussentijd. Doe daarna een laatste synchronisatie van bestanden en database naar de nieuwe host en voer een laatste korte test uit.

De records omzetten

Er zijn twee manieren om je domein naar de nieuwe host te laten wijzen.

• Wijzig het A-record (en AAAA als je dat gebruikt) bij je huidige DNS-provider, zodat het naar het IP-adres van de nieuwe server wijst. De rest van je DNS, inclusief e-mail, blijft dan precies zoals het is. Voor de meeste mensen is dit de veiligste optie.
• Wijzig de nameservers bij je registrar, zodat de nieuwe host alle DNS beheert. Dat is overzichtelijk, maar doe het pas nadat je elk record uit je overzicht bij de nieuwe host hebt nagemaakt, vooral MX- en TXT-records. Ontbrekende records zijn de gebruikelijke oorzaak van verloren e-mail na een verhuizing.

Hoe lang propagatie echt duurt

Mensen zeggen vaak dat DNS tot 48 uur duurt, maar dat is een gewoonte uit het slechtste geval en geen regel. Er verspreidt zich eigenlijk niets vanuit je DNS-provider. In plaats daarvan bewaren duizenden resolvers wereldwijd elk hun eigen antwoord in de cache, en elk ververst dat pas als de timer afloopt. Met een vooraf ingestelde korte TTL bereiken de meeste bezoekers de nieuwe server binnen enkele minuten tot een paar uur. Wijzigingen van nameservers kunnen langer duren, omdat ook het register zelf cachet en sommige internetproviders antwoorden langer vasthouden dan zou moeten. Daarom moet de oude host tijdens de overgang online blijven. Sommige mensen zien de oude site, anderen de nieuwe, en beide moeten werken.

Je kunt de voortgang volgen met openbare DNS-opzoektools die veel locaties bevragen, of met een opdrachtregelopzoeking op je eigen computer. Bedenk dat ook je eigen computer en router antwoorden cachen, dus testen vanaf een telefoon op mobiele data kan een nuttige tweede mening geven.

E-mail, SSL en URL's regelen

E-mail en MX-records

E-mail is het onderdeel dat het vaakst vergeten wordt. Zoek eerst uit waar je mail staat. Wordt die gehost bij je oude webhost, dan moet je ook de mailboxen verhuizen, inclusief de opgeslagen berichten. Maak dezelfde mailboxen aan bij de nieuwe host en kopieer de oude mail met een IMAP-overdrachtstool, of door beide accounts aan een mailprogramma toe te voegen en mappen over te slepen. Blijf verzenden en ontvangen via de oude server tot het kopiëren klaar is.

De MX-records vertellen de wereld waar je mail moet worden bezorgd. Als je alleen het A-record wijzigt, blijft MX ongemoeid en blijft de mail gaan waar die nu naartoe gaat. Als je de nameservers wijzigt, kopieer dan de MX-records exact, plus de TXT-records voor SPF, DKIM en DMARC, die helpen voorkomen dat je berichten in de spammap belanden. Zit je e-mail bij een aparte e-mailprovider, laat de records daarvan dan helemaal met rust. Stuur bij twijfel dezelfde dag testberichten in beide richtingen.

SSL-certificaten

Een veilig slotje vereist een geldig certificaat op de nieuwe server. De meeste hosts kunnen een gratis automatisch certificaat uitgeven, maar ze willen meestal eerst dat het domein naar hen wijst, dus uitgifte lukt misschien pas na de DNS-omschakeling. Reken op een kort tijdsvenster en vraag het certificaat aan zodra de records veranderen. Sommige hosts laten je vooraf een certificaat installeren, wat een gat voorkomt. Controleer als het actief is dat elke pagina via HTTPS laadt zonder waarschuwingen voor gemengde inhoud, en dat HTTP-adressen doorsturen naar HTTPS.

Redirects en URL's

Houd je URL's waar mogelijk identiek. Verandert het webadres van een pagina, voeg dan een permanente redirect toe van het oude naar het nieuwe adres, zodat bezoekers en zoekmachines die volgen. Neem je redirectregels mee, die vaak in een verborgen bestand genaamd .htaccess of in de serverconfiguratie staan. Controleer ook of je voorkeursversie van het domein, met of zonder www, zich hetzelfde gedraagt als voorheen. Verander je ook de domeinnaam zelf, dan is dat een apart project dat een eigen plan verdient.

Houd na de omschakeling toezicht en bewaar een terugdraaiplan

Houd de site de eerste dagen goed in de gaten. Laad regelmatig belangrijke pagina's, test formulieren en checkout, en bekijk de foutlogs van de server. Stel een gratis uptimemonitor in als je die nog niet hebt. Controleer of geplande taken draaien, want cron jobs zijn makkelijk te vergeten. Zorg bij WordPress dat geplande berichten worden gepubliceerd en dat back-upplugins werken. Maak opnieuw back-ups bij de nieuwe host en controleer of je analytics- en Search Console-tools nog gegevens tonen.

Je terugdraaiplan is simpel, omdat je je erop hebt voorbereid. De oude site draait nog en je oorspronkelijke DNS-records zijn opgeslagen. Als er iets ernstigs misgaat dat niet snel op te lossen is, zet je de records terug naar de oude waarden. Dankzij de korte TTL verspreidt ook de terugdraaiing zich snel. Bepaal van tevoren wat als ernstig geldt, bijvoorbeeld een checkout die niet werkt of e-mail die niet aankomt, zodat je daar niet onder stress over hoeft te discussiëren.

Houd het oude pakket nog even aan, meestal een tot twee weken, en langer als je twijfelt over de mail of een maandelijkse factureringscyclus hebt. Zeg het niet op dezelfde dag op. Maak voordat je opzegt nog een laatste back-up, controleer dat er geen mail meer op staat, en kijk of niets, zoals een subdomein of een klein nevenproject, er nog van afhangt. Controleer ook of je domeinregistratie bij het oude pakket was inbegrepen, zodat je die niet per ongeluk kwijtraakt.

Veelgemaakte fouten en wanneer je hulp inschakelt

• E-mail vergeten. De mail stopt omdat MX- of TXT-records niet zijn gekopieerd.
• De TTL hoog laten. De omschakeling sleept zich dan uren of dagen voort.
• De test overslaan. Problemen komen dan voor de ogen van klanten aan het licht in plaats van in privé.
• Het oude pakket te vroeg opzeggen. Zo verdwijnt je vangnet terwijl de DNS nog aan het bijkomen is.
• Beide kopieën bewerken. Content die tijdens de verhuizing op de oude site wordt toegevoegd, gaat verloren.
• De DNS-records niet opslaan. Je kunt niet herbouwen wat je niet hebt opgeschreven.
• PHP- en softwareversies negeren. Een oude plugin kan falen op een nieuwere serverversie.

Veel hosts bieden een gratis migratieservice aan, meestal voor nieuwe klanten die een standaardsite verhuizen. Voor eenvoudige WordPress-sites is dat de moeite waard, want het bespaart tijd en de specialisten hebben het al vaak gedaan. Stel eerst een paar vragen. Dekt het bestanden, databases en e-mail? Hoeveel sites of mailboxen zijn inbegrepen? Testen ze de site voor de omschakeling, en krijg je een voorbeeld te zien? Blijft de oude site onaangeroerd? Wie beheert de DNS, en wat gebeurt er als er iets misgaat? Zijn er beperkingen qua grootte, eigen code of bepaalde toepassingen? Laat de antwoorden waar mogelijk schriftelijk vastleggen.

Overweeg betaalde professionele hulp als je een webshop met lopende bestellingen draait, een ledensysteem of boekingssysteem, een grote database, eigen code die niemand in je team heeft geschreven, of ingewikkelde e-mailconfiguraties. Een freelancer of bureau kan ook verstandig zijn als downtime je meer kost dan hun tarief. Ook als je iemand inhuurt, bewaar je eigen overzicht en back-ups en houd je zelf de controle over je domeinaccount.

Een voorbeeld van een verhuisplanning

1. Een week van tevoren: Besluit te verhuizen, kies de nieuwe host en maak je overzicht van bestanden, databases, e-mail, cron jobs, DNS en SSL compleet.
2. Drie tot vijf dagen van tevoren: Exporteer de DNS-zone, maak volledige back-ups en controleer dat ze terug te zetten zijn.
3. Drie dagen van tevoren: Verlaag de TTL van je belangrijkste DNS-records naar een paar minuten.
4. Twee dagen van tevoren: Stel de nieuwe host in, kopieer bestanden en database en werk de configuratie bij.
5. Een dag van tevoren: Test via het hosts-bestand of een tijdelijke URL en los problemen op.
6. Omschakeldag, begin: Bevries wijzigingen in content, doe een laatste synchronisatie van bestanden en database en voer een korte test uit.
7. Omschakeldag, midden: Werk het A-record of de nameservers bij en vraag dan het SSL-certificaat aan.
8. Dezelfde dag: Controleer of e-mail in beide richtingen nog werkt en of HTTPS en redirects functioneren.
9. Dag een tot drie: Houd uptime, logs, formulieren, cron jobs en analytics in de gaten. Geef content weer vrij als je er zeker van bent.
10. Dag zeven tot veertien: Maak een laatste back-up van het oude pakket, controleer dat er niets van afhangt en zeg het op. Zet de TTL terug naar een normale waarde.

Checklist voor en na de omschakeling

Vooraf

• Overzicht opgeschreven: bestanden, databases, e-mail, cron jobs, DNS-records, SSL.
• DNS-zone geëxporteerd en buiten de oude host opgeslagen.
• Volledige back-ups gemaakt, op twee plekken bewaard en testmatig teruggezet.
• TTL minstens twee dagen voor de omschakeling verlaagd.
• Nieuwe host ingesteld met een gelijke of compatibele PHP-versie.
• Bestanden en database gekopieerd, configuratie bijgewerkt.
• Site getest via het hosts-bestand of een tijdelijke URL, inclusief formulieren en logins.
• E-mailplan bepaald, mailboxen aangemaakt, oude berichten gekopieerd.
• Contentstop gepland en aangekondigd aan iedereen die de site bewerkt.
• Terugdraaiplan opgesteld, met de oorspronkelijke DNS-waarden bij de hand.

Achteraf

• Domein laadt vanaf de nieuwe server op meerdere netwerken en apparaten.
• HTTPS werkt op elke pagina en HTTP stuurt door naar HTTPS.
• E-mail verzendt en ontvangt, en SPF-, DKIM- en DMARC-records staan op hun plek.
• Formulieren, checkout, zoeken en logins werken.
• Redirects en de voorkeur voor www of niet-www gedragen zich als voorheen.
• Cron jobs en geplande taken draaien.
• Uptimemonitoring en back-ups zijn actief op de nieuwe host.
• TTL weer verhoogd nadat alles stabiel is.
• Oud pakket een tot twee weken bewaard en daarna opgezegd na een laatste back-up.

Een opmerking over transparantie: DealPortal kan een commissie ontvangen als je via sommige links op onze site iets koopt. Dat verandert niets aan de prijs die je betaalt of aan het advies dat wij geven.

Belangrijkste punten

• Bouw en test de nieuwe kopie eerst privé, met het hosts-bestand of een tijdelijke URL, terwijl de oude site blijft draaien.
• Verlaag je DNS-TTL minstens twee dagen van tevoren en bewaar een kopie van elk DNS-record voordat je iets verandert.
• Behandel e-mail als een aparte taak: verhuis de mailboxen, kopieer MX-, SPF-, DKIM- en DMARC-records en test in beide richtingen.
• Propagatie gaat met een korte TTL meestal snel, maar sommige bezoekers zien nog een tijd de oude site, dus zet de oude nooit te vroeg uit.
• Houd het oude pakket een tot twee weken aan en zorg voor een schriftelijk terugdraaiplan.
• Gebruik een gratis migratieservice voor eenvoudige sites en schakel een professional in voor webshops, eigen code of alles waarbij downtime duur is.