Een cloudmigratie plannen (zonder gek te worden)

Je weet dat je naar de cloud moet. Maar je ziet ertegenop: wat als we data kwijtraken? Hoe lang gaat dit duren? Wat als het duurder uitpakt dan on-premise blijven? Kiezen we wel de juiste provider?

De afgelopen jaren hebben we 8 productiesystemen gemigreerd naar AWS, Azure en Google Cloud. Wat we daarvan geleerd hebben: de meeste cloudmigraties slagen gewoon. De migraties die misgaan, gaan meestal mis door slechte planning — niet door slechte uitvoering.

Voordat je drie maanden aan plannen besteedt, beantwoord je deze vraag eerlijk: waarom ga je eigenlijk over?

• Sneller kunnen opschalen? Cloud wint. On-prem komt niet in de buurt van die elasticiteit.

• Kosten drukken? Cloud kán winnen — maar alleen als je on-prem omgeving flink overgedimensioneerd is, of als je betaalt voor hardware die staat te niksen.

• Moderne infrastructuur? Cloud wint. Managed databases, CI/CD en monitoring zijn er eersterangs burgers.

• Van vendor lock-in af? Migreer daar niet voor. Je ruilt de ene lock-in (je hardwareleverancier) in voor de andere (AWS/Azure/GCP). Het blijft lock-in.

Wanneer je beter on-prem blijft: is je systeem klein, stabiel en kostenefficiënt zoals het nu draait? Dan kost de migratie je vaker wel dan niet meer dan hij oplevert. Heb je harde compliance-eisen (HIPAA, dataresidentie voor de overheid, air-gapped netwerken)? Dan kan de cloud prima, maar je koopt er complexiteit bij.

Houdt de migratie na deze eerlijke check nog steeds stand? Ga door.

Breng in kaart wat je hebt. Eén persoon, twee weken, een spreadsheet.

• Lijst elk systeem op: applicatie, database, cache, queue, message broker, API en elke geplande job.

• Noteer de afhankelijkheden: welk systeem roept welk systeem aan? Synchroon of asynchroon?

• Schat de complexiteit in: simpele REST API + Postgres = laag. Monoliet met 15 afhankelijkheden, realtime data en betaalkoppelingen = hoog.

• Kijk naar je datavolume: kleine database (< 10 GB) = zo verhuisd. Grote dataset (> 1 TB) = reken op bandbreedtegedoe en downtime.

Wat het oplevert: een inventarisatie van één A4. Staan er 50+ regels op? Reken op 6+ maanden. Zijn het er 5 à 8? Dan kun je in 3 à 4 maanden klaar zijn.

Er zijn drie strategieën. Kies er één:

Lift & shift (het snelst): verhuizen zoals het is. Je applicatie draait op VM's in plaats van op fysieke servers. Duurt 2 à 4 maanden, met minimale codewijzigingen. Nadeel: je profiteert nergens van cloud-native features als auto-scaling en managed services. Je huurt eigenlijk gewoon andermans infrastructuur.

Re-architect (de balans): verhuizen én moderniseren. On-prem database eruit, managed RDS erin. Load balancers ervoor. Auto-scaling groups erbij. Duurt 4 à 6 maanden met redelijk wat codewijzigingen. Je pakt de cloudvoordelen mee en houdt je kernlogica intact.

Refactor (het beste op lange termijn): herschrijven voor de cloud. Serverless functies, microservices, alles managed. Duurt 6 à 12 maanden, vraagt de grootste codewijzigingen en is vooraf het duurst. Maar daarna het goedkoopst in beheer, het best schaalbaar en met de minste ops-last.

Ons advies: begin bij re-architect. Dat is de sweet spot — genoeg cloudvoordeel om de moeite te rechtvaardigen, en niet zoveel verandering dat je er een lading nieuwe bugs bij bouwt.

Vraag je cloudprovider om een kostenraming. Je levert je infrastructuurspecs aan, zij rekenen het voor je door.

• Je huidige on-prem kosten: wat ben je nu kwijt? (Hardware, hosting, koeling, bandbreedte, en de uren van de mensen die het draaiend houden.)

• Je verwachte cloudkosten: de pricing calculator van AWS, Azure of Google Cloud.

• Je break-evenpunt: wanneer zijn je opgetelde cloudkosten gelijk aan wat de migratie kostte? (Reken op $150K–500K, afhankelijk van de complexiteit.)

Kost de cloud je meer dan on-prem blijven? Dan is migreren misschien gewoon geen goed idee.

Uit de praktijk: we hebben een klant van on-prem naar AWS gebracht. On-prem: $40K per jaar aan hardware en hosting. AWS: $30K per jaar, na re-architect-optimalisatie. Break-even na 18 maanden. Maar ze kregen er ook 5x snellere deployments en 99,99% uptime bij. Meer dan de moeite waard.

1. Kies je eerste systeem. Begin met iets dat niet kritisch is. Een rapportagetool. Een intern dashboard. Iets met afhankelijkheden, maar waar niemand wakker van ligt. Zo leer je het proces kennen voordat je aan je kernproduct zit.

2. Doe een pilotmigratie. Migreer één systeem echt, van begin tot eind. Dat leert je:

• hoe lang het werkelijk duurt (meestal twee keer zo lang als je dacht)

• wat er stukgaat (en hoe je het repareert)

• waar je team op vastloopt (en of je hulp nodig hebt)

1. Prik je datum voor productie. Na de pilot weet je genoeg. Duurde de pilot 3 weken? Geef productie er 6 plus buffer. Ga ervan uit dat 20% van die tijd opgaat aan onverwachte chaos.

2. Plan je cutover. Dit is het engste stuk: de omschakeling van oud naar nieuw. Komt er downtime bij kijken? (Lift & shift: reken op 2 à 4 uur. Re-architect: idealiter nul, met blue-green deployments.) Wie moet er stand-by staan? En wat is je terugvalplan als er iets breekt?

Fout 1: de overdrachtstijd van je data onderschatten. 500 GB verplaatsen duurt langer dan je denkt, zeker over het internet. Reken op minimaal een week. Denk aan replicatiestrategieën voor je database — doorlopend synchroniseren in plaats van één keer kopiëren.

Fout 2: je rollback niet testen. Ga ervan uit dat er iets stukgaat. Voordat je productie migreert, moet je het terugdraaien geoefend hebben. Krijg je het oude systeem binnen 30 minuten terug in de lucht? Zo niet, dan ben je er nog niet klaar voor.

Fout 3: migreren zonder duidelijke eigenaar. Eén persoon moet de planning, het budget en de beslissingen bezitten. Geen commissie. Eén iemand aanspreekbaar. Alles gaat sneller zodra duidelijk is wie beslist.

1. Doe die inventarisatie. Ga deze week twee uur zitten en schrijf op wat je hebt.

2. Kies een strategie. Lift & shift, re-architect of refactor? Wij zeggen meestal: re-architect.

3. Reken de kosten door. Gebruik de calculator van je cloudprovider. Is het het waard?

4. Plan een pilot. Pak een niet-kritisch systeem en doe het gewoon. Leer het voordat je je aan productie committeert.

Ben je een cloudmigratie aan het plannen en wil je er iemand met ervaring naar laten kijken? We doen gratis migratie-assessments: we bekijken je huidige systeem, schatten de complexiteit en de doorlooptijd in, en wijzen je op de risico's voordat je erin trapt. We hebben dit vaker gedaan en kennen de valkuilen.

Vraag een gratis migratie-assessment aan – neem contact op, dan bespreken we jouw situatie.