De Adopt-fase (Migrate): workloads migreren naar Azure
Leestijd: 4 min
In het vorige blog over de Ready-fase hebben we uitgelegd hoe je een solide Azure Landing Zone opzet. Je hebt nu een omgeving die klaar is voor productie: structuur, netwerk, security, monitoring en governance staan.
Maar dan komt de stap waar veel organisaties het meest naar uitkijken (en soms ook een beetje tegenop zien): de daadwerkelijke migratie van workloads naar Azure.
Dat is precies waar de Adopt-fase (Migrate) binnen het Microsoft Cloud Adoption Framework (CAF) om draait
Wat is de Adopt (Migrate)-fase?
De Adopt-fase is het moment waarop plannen werkelijkheid worden. In deze fase ga je:
- Servers migreren (VM’s)
- Databases overzetten
- Fileshares en data migreren
- Applicaties testen en valideren
- Cutovers uitvoeren (livegang)
- En uiteindelijk productie draaien in Azure
Microsoft noemt deze fase Migrate, omdat het draait om het verplaatsen van bestaande workloads naar de cloud, vaak als eerste stap richting modernisering.
Waarom is deze fase zo belangrijk?
In deze fase komt alles samen.
- In de Strategy-fase bepaal je waarom je migreert
- In de Plan-fase bepaal je wat en wanneer
- In de Ready-fase richt je Azure goed in
Maar in de Migrate-fase draait het om uitvoering: risico's beheersen, downtime minimaliseren en zorgen dat alles blijft werken. Veel migraties lopen niet vast op techniek, maar op uitvoering. Denk aan:
- Onvoldoende testen
- Geen duidelijke cutoverplanning
- Onverwachte afhankelijkheden
- Onvoldoende communicatie richting gebruikers
- Te veel tegelijk migreren
De 6 R’s: kiezen hoe je migreert
Een belangrijk concept in deze fase is het migratiemodel van Microsoft: de 6 R’s. Elke workload valt grofweg in één van deze categorieën.
Rehost (lift-and-shift)
Een server wordt vrijwel één-op-één naar Azure verplaatst.
Voordeel: snel. Nadeel: je neemt vaak ook legacy-problemen mee.
Een server wordt vrijwel één-op-één naar Azure verplaatst.
Voordeel: snel. Nadeel: je neemt vaak ook legacy-problemen mee.
Refactor
Een applicatie wordt gedeeltelijk aangepast om beter gebruik te maken van Azure-services. Bijvoorbeeld: een applicatie blijft draaien, maar de database verhuist naar Azure SQL.
Een applicatie wordt gedeeltelijk aangepast om beter gebruik te maken van Azure-services. Bijvoorbeeld: een applicatie blijft draaien, maar de database verhuist naar Azure SQL.
Rearchitect
De applicatie wordt fundamenteel herontworpen, bijvoorbeeld naar microservices.
De applicatie wordt fundamenteel herontworpen, bijvoorbeeld naar microservices.
Rebuild
De oplossing wordt opnieuw gebouwd met een moderne cloud-native architectuur.
De oplossing wordt opnieuw gebouwd met een moderne cloud-native architectuur.
Replace
De applicatie wordt vervangen door een SaaS-oplossing, zoals Dynamics, ServiceNow of Microsoft 365.
De applicatie wordt vervangen door een SaaS-oplossing, zoals Dynamics, ServiceNow of Microsoft 365.
Retire
De workload wordt uitgefaseerd omdat deze niet meer nodig is.
De workload wordt uitgefaseerd omdat deze niet meer nodig is.
Dit laatste wordt vaak onderschat: het kan direct kosten en beheer reduceren.
In de Plan-fase is meestal al een richting bepaald; in de Migrate-fase voer je deze keuzes uit.
VM-migratie: vaak de eerste stap
Veel organisaties starten met het migreren van virtuele machines. Dat is herkenbaar, relatief voorspelbaar en levert vaak snel zichtbaar resultaat op.
Microsoft gebruikt hiervoor Azure Migrate als centrale tool.
Waar Azure Migrate in de Plan-fase wordt gebruikt voor discovery en assessment, wordt het hier ingezet voor:
- Replicatie van VM’s
- Migraties in waves
- Cutovers
- Status- en voortgangstracking
Migraties verlopen meestal gefaseerd:
- Testmigraties
- Productiemigraties
- Het uitschakelen van de oude on-prem systemen
Databasemigratie: vaak kritischer
Databases zijn meestal gevoeliger dan applicatieservers en vragen extra aandacht voor:
- Performance
- Compatibiliteit
- Downtime
- Data-integriteit
Veelvoorkomende migratiedoelen in Azure zijn:
- Azure SQL Database
- Azure SQL Managed Instance
- SQL Server op een Azure VM
- Azure Database for PostgreSQL of MySQL
Microsoft gebruikt hiervoor vaak Azure Database Migration Service (DMS) of assessments vanuit Azure Migrate. Het verschil met VM-migratie is dat databases vaak een kans bieden om direct te moderniseren.
Fileservers en data: vaak onderschat
Het migreren van fileshares lijkt eenvoudig, maar is vaak complexer dan verwacht. Denk aan:
- NTFS- en share-permissies
- Hardcoded paden in applicaties
- Legacy scripts en mapped drives
- Grote hoeveelheden data
- Gebruikers die blijven doorwerken tijdens de migratie
Veelgebruikte Azure-oplossingen zijn:
- Azure Files
- Storage Accounts met Blob Storage
- Azure File Sync (hybride scenario’s)
Ook hier geldt: test eerst, migreer daarna.
Testen en validatie
Testen wordt soms gezien als iets wat “erbij hoort”, maar in werkelijkheid is het cruciaal. Een migratie zonder testplan is gokken. Test daarom niet alleen of een server start, maar ook:
- Werkt de applicatie end-to-end?
- Zijn afhankelijkheden bereikbaar?
- Kloppen DNS en routing?
- Zijn firewallregels correct?
- Is de performance acceptabel?
- Werken back-ups, monitoring en alerts?
Een goede aanpak is om per migratiewave een vaste testchecklist te gebruiken en altijd eerst een testmigratie uit te voeren.
Cutover: livegang zonder paniek
De cutover is het moment waarop je definitief overschakelt van on-prem naar Azure. Dit is vaak het spannendste moment.
Voor een goede cutover heb je minimaal nodig:
- Een duidelijk cutoverplan met stappen en tijden
- Communicatie richting gebruikers
- Een rollbackscenario (wat als het misgaat?)
- Duidelijke verantwoordelijkheden
- Monitoring en logging actief
- Een acceptatiemoment voor livegang
Cutovers worden vaak gepland in een onderhoudswindow, bijvoorbeeld ’s avonds of in het weekend.
Output van de Migrate-fase
Aan het einde van deze fase:
- Draaien workloads in Azure
- Zijn de eerste migratiewaves afgerond
- Zijn delen van de on-prem omgeving uitgefaseerd
- Is monitoring en beheer actief
- Werken gebruikers op de nieuwe omgeving
Daarnaast heeft de organisatie ervaring opgedaan met het migratieproces, waardoor volgende waves vaak sneller verlopen.
Veelgemaakte fouten in een migratie
In de praktijk zien we vaak dezelfde valkuilen.
Te veel tegelijk migreren
Dit maakt het moeilijk om problemen te isoleren.
Dit maakt het moeilijk om problemen te isoleren.
Testen onderschatten
Migraties mislukken zelden door Azure zelf, maar vaak door vergeten afhankelijkheden.
Migraties mislukken zelden door Azure zelf, maar vaak door vergeten afhankelijkheden.
Alleen technisch kijken
Een workload kan technisch eenvoudig zijn, maar bedrijfskritisch.
Een workload kan technisch eenvoudig zijn, maar bedrijfskritisch.
Geen cutover- of rollbackplan
Als je pas tijdens de livegang bedenkt wat je doet bij problemen, ben je te laat.
Als je pas tijdens de livegang bedenkt wat je doet bij problemen, ben je te laat.
On-prem niet opruimen
Als oude systemen blijven draaien, betaal je dubbel en blijft legacy bestaan.
Als oude systemen blijven draaien, betaal je dubbel en blijft legacy bestaan.
Checklist: klaar voor migratie?
Je bent klaar voor de Adopt (Migrate)-fase als:
- De Landing Zone klaar is (Ready-fase afgerond)
- Migratiewaves en prioriteiten vastliggen
- De migratiestrategie per workload bepaald is (6 R’s)
- Azure Migrate ingericht is
- Testplannen en validatiecriteria klaarstaan
- Cutover- en rollbackprocessen zijn uitgewerkt
- Monitoring, logging en back-up actief zijn
Tot slot
De Adopt (Migrate)-fase is het moment waarop cloudmigratie concreet wordt: niet meer plannen, maar uitvoeren.
Een succesvolle migratie draait niet alleen om techniek, maar vooral om structuur, herhaalbaarheid, testen, communicatie en beheersbaarheid.
In het volgende blog gaan we verder met Adopt (Innovate): de fase waarin je verder gaat dan lift-and-shift en echt de voordelen van cloud-native gaat benutten.
Kies voor meer resultaat
Vragen? Deze beantwoorden we natuurlijk graag. Neem gerust contact met ons op!
.webp)