Een cloud migratie is een operatie aan het hart van je IT. Je verplaatst systemen waar je organisatie dagelijks op draait naar een andere omgeving. De vraag is niet of er risico op downtime is, maar hoe je dat risico beheersbaar houdt.
Downtime kost geld. Gartner schat de kosten op $137 per minuut voor kleinere bedrijven tot $9.000 per minuut voor multinationals. In de Eurozone komt dat neer op gemiddeld €4.600 per minuut. Zelfs voor een mkb-bedrijf met een webshop die €50.000 per maand omzet, betekent vier uur offline al een paar duizend euro aan gemiste bestellingen, plus de indirecte schade: klanten die afhaken, zoekmachines die een trage site afstraffen, medewerkers die duimen draaien.
Het goede nieuws: met de juiste aanpak kun je een migratie uitvoeren met minimale tot nul downtime. Dit artikel laat zien hoe.
Waarom migraties misgaan
De meeste migratiefouten vallen in drie categorieën.
Onvolledige inventarisatie. Je weet niet precies wat er draait, welke afhankelijkheden er zijn, en welke systemen met elkaar communiceren. Een applicatie lijkt standalone, maar blijkt een API-call te doen naar een interne service die je nog niet gemigreerd hebt. Resultaat: de applicatie start op in de cloud en faalt direct.
Big bang cutover. Alles tegelijk overzetten op een vrijdagavond en hopen dat het maandagochtend werkt. Dit is de riskantste strategie die er bestaat. Als er iets misgaat (en er gaat altijd iets mis), heb je geen werkende omgeving om op terug te vallen.
Geen rollback plan. Als de nieuwe omgeving niet werkt zoals verwacht, moet je binnen minuten terug kunnen. Zonder getest rollback plan zit je vast: de oude omgeving is al afgeschakeld, de nieuwe werkt niet, en je team improviseert onder druk.
De vier strategieën
Er zijn vier bewezen methoden om downtime te minimaliseren. Elke methode past bij een ander type workload.
1. Blue-green deployment. Je bouwt de volledige nieuwe omgeving (green) op naast de bestaande (blue). Beide draaien tegelijkertijd. Zodra green is getest en klaar, schakel je het verkeer om via DNS of een load balancer. De cutover duurt seconden. Als green niet functioneert, schakel je terug naar blue. Nadeel: je betaalt tijdelijk dubbele infrastructuurkosten, en databases moeten gesynchroniseerd blijven tijdens de parallelle periode.
2. Canary deployment. Je stuurt een klein percentage van je verkeer (5-10%) naar de nieuwe omgeving terwijl de rest via de oude loopt. Monitor je de nieuwe omgeving en ziet alles er goed uit, dan verhoog je geleidelijk: 25%, 50%, 75%, 100%. Bij problemen draai je het percentage terug naar nul. Dit is veiliger dan blue-green omdat je met weinig gebruikers test, maar het vereist een load balancer die weighted routing ondersteunt.
3. Rolling migration. Je migreert componenten een voor een. Eerst de statische website, dan de API, dan de database, dan de achtergrondprocessen. Elk component wordt apart getest voordat je doorgaat. Dit spreidt het risico, maar duurt langer en vereist dat oude en nieuwe componenten tijdelijk met elkaar kunnen communiceren.
4. Database-first. De database is bijna altijd het lastigste onderdeel van een migratie. Bij deze aanpak migreer je de database als eerste, met replicatie tussen oud en nieuw. De applicatie blijft op de oude servers draaien maar leest en schrijft naar de nieuwe database. Zodra de database stabiel is, verplaats je de applicatie. Dit isoleert het moeilijkste deel van de migratie.
4 strategieën voor minimale downtime
Kies op basis van risicotolerantie en workload
De database: het moeilijkste onderdeel
Bij bijna elke migratie is de database het punt waar het spannend wordt. Bestanden kopiëren is relatief simpel. Een draaiende database verplaatsen zonder dataverlies is dat niet.
De standaardaanpak werkt in drie stappen. Eerst een volledige kopie (initial sync) van de database naar de nieuwe omgeving. Dat kan uren duren afhankelijk van de grootte, maar de applicatie draait gewoon door op de oude database. Daarna schakel je replicatie in: elke wijziging op de oude database wordt automatisch doorgevoerd op de nieuwe. MySQL, PostgreSQL en de meeste moderne databases ondersteunen dit natively. Tot slot, als de replicatie stabiel loopt en de vertraging (lag) onder een paar seconden zit, doe je de cutover: je wijst de applicatie naar de nieuwe database.
De cutover zelf duurt typisch 30 seconden tot 2 minuten. In die periode schrijf je kort naar geen van beide databases. Daarna wijst alles naar de nieuwe locatie.
Twee valkuilen hier. Eén: de replicatie-lag testen onder productiebelasting, niet alleen op een rustig moment. Een database die 100 queries per seconde verwerkt, kan bij 1.000 queries per seconde een lag opbouwen die de cutover bemoeilijkt. Twee: schema-wijzigingen. Als de nieuwe omgeving een iets andere databaseversie draait, test dan of alle queries identiek werken. Een verschil in hoe een JOIN wordt verwerkt kan subtiele dataproblemen veroorzaken die pas dagen later opvallen.
DNS: de onderschatte factor
DNS-records hebben een TTL (Time To Live) die bepaalt hoe lang ze gecacht worden. De standaard TTL bij veel providers is 3600 seconden (1 uur) of hoger. Als je een cutover doet en de DNS wijzigt, kan het tot een uur duren voordat alle gebruikers naar de nieuwe server worden gestuurd. In die tussentijd gaat een deel van het verkeer naar de oude server en een deel naar de nieuwe.
De oplossing is simpel maar wordt vaak vergeten: verlaag de DNS TTL 24 tot 48 uur voor de geplande migratie naar een lage waarde, bijvoorbeeld 60 of 120 seconden. Na de cutover wacht je een paar minuten en dan wijst vrijwel alle verkeer naar de nieuwe omgeving. Na een stabiele periode verhoog je de TTL weer.
Cloudflare stelt een minimum van 120 seconden. Bij traditionele DNS-providers kun je vaak lager (30 seconden), maar niet elke resolver respecteert extreem lage TTL-waarden. Reken op een transitieperiode van 2 tot 5 minuten na de DNS-wijziging.
Het migratiedraaiboek
Een migratie zonder draaiboek is een migratie die misgaat. Het draaiboek beschrijft precies wat er moet gebeuren, in welke volgorde, door wie, en wat het terugvalplan is bij elke stap.
Een basisstructuur:
Week -2: Voorbereiding. Inventariseer alle systemen, afhankelijkheden en datastores. Verlaag DNS TTL. Stel monitoring in op beide omgevingen. Documenteer de huidige prestaties als baseline (responstijden, errorrates, throughput). Plan de cutover op een rustig moment (niet op vrijdagmiddag, niet voor een piekperiode).
Week -1: Dry run. Voer de volledige migratie uit op een testomgeving die de productieomgeving spiegelt. Test de cutover, test het rollback plan, meet de tijdsinvestering. Documenteer alles wat niet ging zoals verwacht.
D-day: Uitvoering. Volg het draaiboek stap voor stap. Elke stap heeft een go/no-go punt: als de controle faalt, stop je en voer je het rollback plan uit. Communiceer duidelijk naar stakeholders (vooraf: "we migreren vanavond", achteraf: "alles draait op de nieuwe omgeving").
Week +1: Stabilisatie. Monitor intensief. Vergelijk de prestaties met de baseline. Houd de oude omgeving minimaal een week actief als terugvaloptie. Verwijder de oude omgeving pas als alles stabiel is.
Migratiedraaiboek: van voorbereiding tot cutover
Minimaal 3 weken doorlooptijd voor een veilige migratie
De checklist voor cutover-avond
Op de avond van de cutover wil je geen verassingen. Deze lijst voorkomt de meest voorkomende fouten:
Vooraf: DNS TTL al verlaagd (48 uur geleden)? Database replicatie draait en lag is <5 seconden? Monitoring actief op beide omgevingen? Rollback plan getest in de dry run? Alle betrokkenen weten hun rol en zijn bereikbaar? Communicatie naar gebruikers verstuurd?
Tijdens: volg het draaiboek, geen improvisatie. Check na elke stap of de controle slaagt. Bij een faal: stop, rollback, analyseer, plan een nieuw moment. Niet doordrukken.
Achteraf: vergelijk errorrates, responstijden en throughput met de baseline. Monitor actief voor minimaal 24 uur. Houd de oude omgeving beschikbaar tot je zeker bent.
De kern
Zero downtime bij een cloud migratie is geen marketingbelofte, het is een engineeringdiscipline. De kern is simpel: bouw de nieuwe omgeving op naast de oude, test uitgebreid, schakel geleidelijk over, en houd een terugvalplan achter de hand. De database is het moeilijkste onderdeel. DNS TTL wordt het vaakst vergeten. En een dry run is niet optioneel.
Plan minimaal drie weken doorlooptijd. Niet omdat de technische migratie zo lang duurt, maar omdat voorbereiding en testen het verschil maken tussen een soepele overstap en een nachtmerrie.
Hulp nodig bij je migratie? Onze experts begeleiden je van planning tot cutover. Neem contact op voor een vrijblijvend gesprek.