Honderden legacy-applicaties van VM's naar AWS migreren lukt als je het aanpakt als een productielijn en niet als honderden losse projecten: inventariseer en classificeer elke app, kies per app voor upgrade of herbouw, en verdeel het applicatielandschap in blokken die elk van een klein team zijn. Een gedeeld applicatieskelet, geteste stappen voor omschakeling en rollback, en runbooks die elk team kan volgen, houden de kwaliteit stabiel naarmate het volume groeit.
Begin met een inventaris die laat zien wat elke app echt nodig heeft
Voordat iemand AWS aanraakt, zet je elke applicatie op de legacy-VM's op een lijst en leg je de feiten vast die de migratie-inspanning bepalen. Een gedeelde spreadsheet is in het begin genoeg. Waar het om gaat, is dat elke app een rij heeft, een eigenaar en dezelfde kolommen.
Deel elke app daarna in bij een klein aantal sporen, zoals upgrade, herbouw en uitfaseren. Teams kunnen dan per spoor plannen in plaats van elke app opnieuw te bespreken.
- Runtime- en frameworkversie, met een markering bij alles wat end-of-life is
- Databases, gedeelde mappen en geplande taken waar de app van afhangt
- Inkomende en uitgaande integraties, inclusief hardgecodeerde hostnamen en IP-adressen
- Authenticatiemethode en eventuele geheimen die op de VM zijn opgeslagen
- Eigenaar vanuit de business, gebruiksniveau en acceptabel venster voor downtime
Kies per app voor upgrade of herbouw, niet één keer voor het hele programma
Geen enkele strategie past bij honderden apps. Sommige hebben alleen een frameworkupgrade, externe configuratie en een nieuw deploymentdoel nodig. Andere bevatten zoveel dode code of zo'n verwarde structuur dat herbouwen op een schone basis sneller is dan repareren.
Neem de beslissing aan de hand van schriftelijke criteria, zodat verschillende teams op hetzelfde antwoord uitkomen. Een bruikbare regel: moet je voor het landen op het standaardskelet toch de meeste controllers en de datatoegang herschrijven, herbouw de app dan. Is de bedrijfslogica grotendeels intact over te zetten, doe dan een upgrade.
Het programma van Crédit Agricole, dat 600+ interne applicaties van legacy-VM's naar AWS verhuisde, gebruikte beide routes. Apps werden opnieuw opgebouwd op het interne CodeIgniter-skelet van de bank; sommige kregen een upgrade, andere werden vanaf nul herbouwd.
- Upgrade als de code leesbaar is, het gedrag duidelijk en de achterstand van het framework klein
- Herbouw als bedrijfslogica overal met de presentatie verweven is of de app afhangt van taalfuncties die zijn verwijderd
- Faseer uit als het gebruik bijna nul is en de eigenaar akkoord gaat, want de goedkoopste migratie is de migratie die je overslaat
Verdeel het landschap in blokken en geef elk blok aan één team
Op deze schaal wordt één centraal team de bottleneck. Bij een opsplitsing in blokken krijgt een klein team een reeks samenhangende apps, waarvoor het verantwoordelijk is van analyse tot omschakeling.
Groepeer blokken op gedeelde afhankelijkheden, niet op alfabet. Apps die een database delen of elkaar aanroepen, moeten samen verhuizen, anders wordt hetzelfde integratiewerk in meerdere teams herhaald.
Blokken maken de voortgang ook meetbaar. Elk team rapporteert per app dezelfde statussen, zoals geanalyseerd, gemigreerd, getest, omgeschakeld en ontmanteld, en het overzicht van het programma is de som van die statussen. Het programma van Crédit Agricole werkte zo, en SDK Enterprises leverde als onderdeel van het programmateam 50+ van de applicatiemigraties op.
Bouw één standaardskelet en laat elke app daarop landen
Een standaard applicatieskelet maakt van honderden migraties een herhaalbaar proces. Het legt de beslissingen vast die je niet voor elke app opnieuw wilt nemen: mappenstructuur, configuratie via omgevingsvariabelen, logformaat, health checks, koppelpunten voor authenticatie en de deploymentpipeline.
Elke gemigreerde app verschilt daarna alleen nog in zijn bedrijfslogica. Reviewers weten waar ze moeten kijken, beheerteams krijgen consistente logs en alarmen, en een correctie in het skelet bereikt elke app die erop is gebouwd.
Houd het skelet klein en onder versiebeheer. Groeit het uit tot een eigen framework, dan gaan teams eromheen werken.
Plan omschakeling en rollback vóór de eerste migratie
Elke app heeft een omschakelplan nodig dat vastlegt hoe het verkeer overgaat, hoe de data overgaat en hoe je teruggaat. Beslis dit voordat de eerste app verhuist. Een rollback improviseren tijdens een incident is precies hoe migratieprogramma's het vertrouwen van de business verliezen.
- Bevriezingsperiode: spreek met de eigenaar af wanneer de wijzigingen op de oude VM stoppen
- Datasynchronisatie: migreer de data vooraf en draai tijdens het omschakelvenster een laatste deltasynchronisatie
- Verkeer omzetten: wijzig de DNS- of load-balancerroutering, met lage DNS-TTL's die dagen van tevoren zijn ingesteld
- Smoke tests: een korte, gescripte controle van inloggen, de belangrijkste schermen en de integraties direct na het omzetten
- Trigger voor rollback: een persoon bij naam en schriftelijke voorwaarden om terug te schakelen
- Oude VM bewaren: zet hem stil, maar verwijder hem niet voordat de app een afgesproken periode foutloos op AWS heeft gedraaid
Schrijf runbooks die elk team vanaf dag één kan volgen
Een runbook is de checklist voor één herhaalbare handeling: een app voorbereiden, omschakelen, terugdraaien, de VM ontmantelen. Schrijf elk runbook één keer, test het op de eerste paar apps en werk het bij telkens als een team ergens door verrast wordt.
Goede runbooks noemen commando's, eigenaren en verwachte resultaten, geen voornemens. ‘Controleer of de app werkt’ is geen stap. ‘Log in als testgebruiker en controleer of het dashboard de accountgegevens laadt’ wel.
Runbooks zorgen er ook voor dat engineers die halverwege het programma instappen snel productief worden. Een specialist die in week zes begint, moet na één sessie samen met een collega een app kunnen omschakelen door de documenten te volgen.
Waar een extern team past in een grote migratie
Grote programma's hebben vaak voor een bepaalde periode extra capaciteit nodig, zonder de regie uit handen te geven. Wij nemen migratieblokken binnen grotere programma's op ons en werken daarbij met het skelet, de runbooks en de tooling van de klant, met onze engineers en gescreende freelance specialisten onder één contract.
De kern
- Inventariseer en classificeer elke app voordat je er een migreert, zodat je het werk per spoor kunt plannen.
- Kies per app voor upgrade, herbouw of uitfaseren, met schriftelijke criteria die elk team op dezelfde manier toepast.
- Verdeel het landschap in blokken van samenhangende apps, die elk van begin tot eind van één klein team zijn.
- Een klein applicatieskelet onder versiebeheer maakt honderden migraties consistent en reviewbaar.
- Schakel nooit een app om zonder een geteste weg terug en zonder dat de oude VM nog beschikbaar is.
Veelgestelde vragen
Hoe lang duurt het om honderden applicaties naar AWS te migreren?
Dat hangt af van het aantal apps, het aandeel dat herbouwd moet worden, het aantal parallelle teams en de omschakelvensters die de business accepteert. Maak de schatting na de classificatie: meet de doorlooptijd van een paar apps per spoor, vermenigvuldig met de omvang van elk spoor en deel door de capaciteit van de teams.
Eerst lift-and-shift en later moderniseren: is dat verstandig?
Lift-and-shift is het snelst als een app al op een ondersteunde runtime draait en het doel is een datacenter te verlaten. Bij apps op een runtime die end-of-life is, verhuis je met ongewijzigd overzetten de oude risico's naar het nieuwe platform, dus een upgrade of herbouw tijdens de verhuizing is vaak goedkoper over het geheel.
Wat is een migratie met opsplitsing in blokken?
Bij een migratie met opsplitsing in blokken verdeel je een groot applicatielandschap in reeksen samenhangende apps en wijs je elke reeks toe aan één team dat er verantwoordelijk voor is van analyse tot omschakeling. Zo verdwijnt de centrale bottleneck en is de voortgang over veel teams heen makkelijk te volgen.