Website migreren zonder downtime: plan, test en herstel (2026)

Je migreert een website het veiligst door de nieuwe omgeving eerst los te controleren, de omschakeling klein te houden en een terugvalbesluit klaar te hebben. Nul uitval is geen garantie, maar je kunt de kans en duur van verstoring wel bewust beheersen.

Stappenplan

1. Maak een inventaris met eigenaar

Noteer huidige host, domeinrecords, belangrijke URL's, formulierbestemming en afhankelijkheden zoals e-mail. Start bij de website-audit als die lijst ontbreekt.

Maak de inventaris zo dat een tweede persoon hem kan controleren. Leg per onderdeel vast wat het doet, waar het nu draait, wie eigenaar is en hoe je weet dat het na de migratie werkt. Neem niet alleen zichtbare pagina's op, maar ook redirects, formulieren, uploads, geplande taken, mail en subdomeinen. Gebruik geen exports met persoonsgegevens of toegangscodes als werkdocument; noteer alleen de route en verantwoordelijke.

2. Test de nieuwe omgeving zonder omschakeling

Controleer kernpagina's, HTTPS en een veilig testformulier voordat je DNS wijzigt. Gebruik de livegangchecklist voor dezelfde controles na de omschakeling.

Een testomgeving is alleen nuttig wanneer je weet welke onderdelen daarvan afwijken van productie. Test de homepage, een belangrijke instappagina, een foutpad in het formulier en een route die oude inhoud gebruikt. Controleer dat zoekmachines of echte bezoekers niet onbedoeld op de testomgeving terechtkomen volgens het beleid van je platform. De test hoeft niet alle verkeerssituaties na te bootsen, maar moet aantonen dat de afgesproken kernroute op de nieuwe omgeving bestaat.

3. Plan URL's en redirects

Houd belangrijke URL's gelijk waar dat kan. Verandert een URL, leg dan een passende server-side redirect en controleer doel, status en keten. Google behandelt URL-wijzigingen bij siteverhuizingen als een proces van mapping en controle, niet als een rankingbelofte.

Maak een mapping met oude URL, nieuwe bestemming, reden en testuitkomst. Kies een bestemming die dezelfde behoefte zo goed mogelijk beantwoordt; een homepage is zelden een passend antwoord op een specifieke oude pagina. Controleer ook dat een redirect niet via meerdere tussenstappen loopt en dat interne links naar de nieuwe structuur verwijzen. Beschrijf het resultaat als technische controle, niet als garantie voor verkeer of indexatie.

4. Wijzig DNS gecontroleerd

Leg huidige records vast, bepaal wie de wijziging uitvoert en volg DNS wijzigen zonder uitval. ICANN legt uit dat DNS namen naar technische adressen vertaalt in zijn actuele DNS-overzicht.

Plan de omschakeling pas wanneer certificaat, nieuwe omgeving en herstelactie klaarstaan. Noteer welke records je wijzigt, welke records bewust onaangeroerd blijven en welke afhankelijkheid ieder record heeft. Een lagere TTL of een snel antwoord uit één netwerk bewijst niet dat de omschakeling overal tegelijk zichtbaar is. Houd daarom een controlevenster aan met een bereikbare eigenaar en maak geen extra ontwerp- of inhoudswijziging terwijl je de technische verhuizing beoordeelt.

5. Controleer en beslis over herstel

Test na de wijziging dezelfde kernpaden. Bij een onbekende afwijking stop je verdere wijzigingen en voer je het vooraf gekozen herstel uit.

Controleer de bedoelde domeinvariant via HTTPS, belangrijke URL's, minstens één oude redirect en het formulier met veilige testgegevens. Vergelijk de uitkomst met de lijst van vóór de omschakeling. Zie je dat een route naar een verkeerde omgeving wijst, dat een certificaatwaarschuwing verschijnt of dat ontvangst ontbreekt, behandel dit als blokkade. Ga niet tegelijk cache, DNS en applicatie aanpassen; bepaal eerst welke laag je testte.

Besliskader: welke migratie is verantwoord?

Een migratie kan door wanneer de inventaris compleet genoeg is voor de gekozen scope, de nieuwe omgeving de kernroute heeft doorstaan, de uitvoerder en herstelbeslisser bereikbaar zijn en je de vorige situatie kunt aanwijzen. Wacht als een cruciale afhankelijkheid geen eigenaar heeft, als redirects nog niet gemapt zijn of als je niet weet hoe je teruggaat. Splits een groot project wanneer dat kan: eerst platform en bestaande URL's, later pas een grote structuurwijziging of redesign.

Gebruik een stopregel die iedereen begrijpt. Een onverklaarbare HTTPS-fout, een niet-werkend formulier, uitval van een afgesproken kernpagina of een onverwacht geraakte maildienst vraagt herstel of onderzoek voordat je verdergaat. Een niet-kritische tekstafwijking kan als open punt mee, zolang eigenaar en hertest staan genoteerd. De grens is de afgesproken gebruikersroute, niet de wens om het venster snel af te ronden.

Herstel, hertest en overdracht

Herstel volgens de vooraf genoteerde keuze, bijvoorbeeld door de vorige configuratie of release terug te zetten. Noteer tijdstip, reden en wie het besluit nam. Test daarna dezelfde kernroute opnieuw en laat de eigenaar het resultaat bevestigen. Een back-up kan onderdeel zijn van die route, maar is zonder herstelstappen en controle geen zelfstandig plan.

Sluit af met een overdracht waarin je aangeeft wat verhuisd is, welke URL's en diensten zijn getest, welke afwijkingen nog openstaan en wanneer je opnieuw controleert. Gebruik de DNS-handleiding voor wijzigingen die later alsnog nodig blijken. Zo blijft een volgende wijziging verbonden aan bewijs in plaats van aan aannames over de vorige verhuizing.

Moet je vooraf voorstellen voor deze werkzaamheden naast elkaar leggen, begin dan met website-offertes vergelijken zonder prijzen en vraag naar scope, eigenaarschap, controles en overdracht.

Praktijkcheck in het omschakelvenster

Houd één lijst bij die vóór en na de migratie hetzelfde is: domeinvariant, belangrijke pagina, oude URL, formulierbevestiging, afgesproken ontvangst en eventuele subdomeinroute. Voer iedere regel uit op de nieuwe omgeving en noteer de uitkomst zonder hem meteen te verklaren. Vergelijk daarna met de vooraf vastgelegde verwachting. Een route die bij jou werkt maar naar een verkeerde omgeving verwijst, is geen groen resultaat. Een route die nog niet stabiel is, vraagt de afgesproken wachttijd of herstelactie, niet een extra grote wijziging.

Plan ook een korte controle nadat het eerste venster is gesloten. Sommige afhankelijkheden of omleidingen komen pas dan aan het licht. Beperk die ronde tot dezelfde kernroute en duidelijke signalen. Als iets afwijkt, gebruik je de inventaris om de verantwoordelijke laag en eigenaar terug te vinden.

Veelgemaakte fouten

• DNS aanpassen voordat de nieuwe site getest is. Dat maakt diagnose lastiger.
• Redirects pas na livegang bedenken. Maak de mapping vooraf.
• E-mailafhankelijkheden vergeten. DNS kan meer raken dan webverkeer.
• Geen tijdvenster communiceren. Leg vast wie bereikbaar is.
• Back-up als herstelplan verwarren. Bepaal ook hoe en wanneer je werkelijk terugzet.

Officiële bronnen

Google over siteverhuizingen · ICANN over DNS

Wil je een migratie laten voorbereiden met een controleerbare terugvalroute, stel je vraag via WhatsApp.