Een migratie naar de cloud roept bij veel organisaties dezelfde vraag op: hoe voorkomen we dat onze klanten iets merken van de verhuizing? Bedrijfskritische systemen mogen niet uren onbereikbaar zijn, en een mislukte overgang die pas op maandagochtend zichtbaar wordt, is precies het scenario dat niemand wil. Toch is een migratie zonder downtime goed te plannen. Het vraagt geen geluk, maar discipline: een heldere aanpak, veel repetitie en een uitgewerkt terugvalscenario. In dit artikel loop ik door de fasen die wij bij elk migratietraject aanhouden.
Begin met een eerlijke assessment
Elke succesvolle migratie start met een grondige inventarisatie. We brengen alle workloads, afhankelijkheden en integraties in kaart: welke applicaties praten met elkaar, welke datastromen zijn er, en waar zitten de verborgen koppelingen die pas opvallen als ze wegvallen? Een oude batchverwerking die 's nachts data ophaalt uit een systeem dat niemand meer beheert, kan een migratie flink vertragen als u er pas tijdens de cutover achter komt.
In deze fase categoriseren we ook per workload de migratiestrategie. Sommige applicaties kunnen ongewijzigd mee (lift-and-shift), andere hebben aanpassingen nodig om schaalbaar te draaien (re-architecting), en een enkele is beter gebaat bij vervanging. Deze keuzes bepalen de volgorde en het risicoprofiel van het hele traject.
Bouw eerst een solide landing zone
Voordat er ook maar één workload verhuist, richten we de doelomgeving volledig in. Deze landing zone is het fundament: netwerksegmentatie, identiteits- en toegangsbeheer, logging, monitoring en kostenbewaking staan allemaal vast voordat de eerste applicatie landt. We leggen deze omgeving vast als infrastructure as code met Terraform, zodat elke wijziging reproduceerbaar en herleidbaar is.
Het voordeel van deze aanpak is dat de doelomgeving geen verzameling handmatige acties wordt, maar een gedocumenteerd systeem. Wanneer we later een tweede regio of een testomgeving nodig hebben, staat die binnen enkele minuten. Dat betaalt zich terug op het moment dat het spannend wordt.
Repliceer data voordat u schakelt
Data is bij een migratie zonder downtime het lastigste onderdeel. Applicatieservers zijn relatief eenvoudig te dupliceren, maar een database die continu wijzigt, kunt u niet zomaar kopiëren en weer aansluiten. Daarom zetten we ruim voor de cutover een replicatiestroom op tussen de bron en de nieuwe omgeving.
Concreet betekent dit dat de nieuwe database als replica meeloopt en voortdurend bijwerkt met de laatste wijzigingen. Op het moment van overschakelen is de achterstand teruggebracht tot enkele seconden. We meten die replicatievertraging actief, zodat we exact weten hoe lang de laatste synchronisatie duurt en wanneer de nieuwe omgeving klaar is om het verkeer over te nemen.
Schakel gefaseerd of blue-green over
De daadwerkelijke overgang doen we nooit in één grote sprong. Twee benaderingen werken in de praktijk het beste. Bij een blue-green-aanpak draaien de oude omgeving (blue) en de nieuwe omgeving (green) tegelijkertijd. Zodra green volledig getest en gesynchroniseerd is, verleggen we het verkeer via de load balancer naar de nieuwe omgeving. Blue blijft nog een tijd stand-by staan, zodat teruggaan een kwestie van seconden is.
Bij grotere landschappen kiezen we vaker voor een gefaseerde cutover. We verleggen dan eerst een klein deel van het verkeer, bijvoorbeeld vijf procent, naar de nieuwe omgeving en bewaken nauwlettend de foutpercentages en responstijden. Blijven die stabiel, dan bouwen we het aandeel stap voor stap op. Zo beperken we de impact van een onverwacht probleem tot een fractie van de gebruikers in plaats van tot iedereen tegelijk.
Zorg altijd voor een rollback-plan
Een migratie zonder een uitgewerkt terugvalscenario is een gok. Voor elke cutover leggen we vooraf vast onder welke condities we teruggaan, wie dat besluit neemt en welke stappen dat precies vergt. Belangrijk is dat rollback niet alleen op papier bestaat: we oefenen de procedure in een testomgeving totdat het team hem blind kan uitvoeren.
Dat oefenen legt bovendien fouten bloot die u anders pas tijdens de echte cutover zou tegenkomen. Een vergeten configuratie, een certificaat dat niet meeverhuist of een firewallregel die ontbreekt: het is altijd beter om die tijdens een repetitie te vinden dan om drie uur 's nachts tijdens de productie-overgang.
Vergeet de nazorg niet
Op het moment dat het verkeer volledig op de nieuwe omgeving draait, is de migratie technisch afgerond, maar het werk nog niet. De eerste dagen bewaken we performance, kosten en foutmeldingen intensiever dan normaal. Applicaties gedragen zich in een cloudomgeving soms net anders dan in het eigen datacenter, en die nuances komen pas onder echte productiebelasting naar boven.
Pas als de nieuwe omgeving aantoonbaar stabiel draait, ontmantelen we de oude infrastructuur. Daarna optimaliseren we door: right-sizing van resources, het afbouwen van tijdelijke dubbele capaciteit en het aanscherpen van monitoring en alerts. Zo verandert een migratie zonder downtime niet alleen de plek waar uw software draait, maar levert die vanaf dag één een omgeving op die betrouwbaarder en beter beheersbaar is dan wat u achterliet.