Gids voor engineers

Software­migratie

Softwaremigratie brengt een applicatie, de data, het platform of de tooling die haar uitlevert naar een nieuwe plek, terwijl mensen er gewoon mee blijven werken. Veilig aangepakt verloopt dat in golven, en geen golf schakelt over voordat dezelfde gatecontroles zijn geslaagd.

  1. Beoordelen Een strategie en een golf per workload

  2. Pilotgolf Eenvoudige workloads, eerst buiten productie

  3. Golf 1 Workloads gegroepeerd op afhankelijkheden

  4. Golf 2 Dezelfde stappen, meer workloads

  5. Golf 3 Kritieke systemen, zodra het patroon standhoudt

  • Voorbereiden en synchroniseren
  • Verifiëren, oud systeem stand-by
  • Uitfaseren

Planningsgate na de beoordeling

Uitschakelgate vóór het uitfaseren

  • Geen verkeer meer naar het oude systeem
  • Data gearchiveerd, back-ups verplaatst
  • Niemand heeft de weg terug nog nodig
Illustratie: een planning in golven. De golven herhalen dezelfde stappen en overlappen: de ene bereidt voor terwijl de vorige verifieert.

Wat valt onder softwaremigratie?

Vier soorten werk delen de naam, en de meeste projecten combineren er twee of meer. Applicaties verhuizen naar een ander datacenter, een andere regio, een ander account of een andere cloud, en een verhuizing naar de cloud begint met een landing zone. Data is het enige deel dat u niet opnieuw kunt deployen. Platforms, van een versie van het besturingssysteem tot een database-engine, worden vaak op hun plek geüpgraded, over een heel serverpark. En elke andere migratie loopt via de vierde soort: CI/CD en tooling.

Planningsgate: een strategie per workload

Welke migratiestrategie past bij welke workload?

AWS Prescriptive Guidance noemt zeven migratiestrategieën: de 7 R's. Het Cloud Adoption Framework van Microsoft noemt er acht, grotendeels dezelfde. Beide bepalen de strategie per workload, net als On-premise vs. cloud: de belangrijkste verschillen (en waarom het nu een keuze per workload is). Stel de vragen in volgorde en stop bij het eerste ja.

  1. Wordt het niet gebruikt, of is het de verhuizing niet waard?

    AWS ziet 90 dagen zonder inkomende verbindingen als een signaal.

    JaRetire

  2. Moet het voorlopig blijven waar het is?

    Dataresidentie, hardware zonder tegenhanger in de cloud, een recente upgrade of een afhankelijkheid die eerst moet verhuizen.

    JaRetain

  3. Kan een standaardproduct het werk doen?

    De data, de aanmelding en de netwerkverbindingen moeten dan nog steeds mee.

    JaRepurchaseMicrosoft: Replace

  4. Is het gezond, en kan het ongewijzigd draaien in de doelomgeving?

    Het advies van Microsoft: rehost geen workloads met problemen, want de verhuizing lost die niet op.

    JaRehostRelocate, voor een heel platform tegelijk

  5. Bespaart een managed service of een nieuwere runtime echt werk, met kleine codewijzigingen?

    Het voorbeeld van AWS: SQL Server naar Amazon RDS for SQL Server.

    JaReplatform

  6. Anders: staat de architectuur zelf in de weg?

    De duurste route. Bij grote migraties adviseert AWS eerst te verhuizen en daarna te moderniseren.

    JaRefactor of re-architectMicrosoft: Refactor, Rearchitect of Rebuild

Is geen enkel antwoord duidelijk, onderzoek de workload dan nader voordat hij een golf krijgt. Google raadt een proof of concept aan.

Big bang of gefaseerd: hoe pakt u de cutover aan?

De cutover is het moment van overschakelen: vanaf dan is het nieuwe systeem het systeem dat telt. Google raadt af om zero downtime te eisen waar de business zonder kan, omdat dat redundantie voor elke workload vraagt.

Cutoveraanpakken vergeleken
AanpakHoe het werktRisicoDe weg terugPast bij
Big bang Schrijfacties stoppen, alles verhuizen en in één onderhoudsvenster overschakelen: de stop-the-world-cutover uit de patronen voor het vervangen van legacysystemen. HoogEén gemiste afhankelijkheid raakt alles. Terugschakelen, zolang er geen schrijfacties op de nieuwe kant zijn beland. Kleine systemen met een onderhoudsvenster.
Gefaseerd in golven Groepen workloads verhuizen één voor één, elk met een eigen cutover. GemiddeldBeperkt tot één golf, terwijl oud en nieuw gekoppeld zijn. Per golf. Eerdere golven blijven waar ze zijn. Grote IT-landschappen en serverparken.
Parallel draaien Beide verwerken dezelfde invoer, en de uitvoer wordt vergeleken tot die overeenkomt. Dan schakelt u over. LaagKostbaar: u draait twee systemen. Het oude systeem blijft leidend tot de overstap. Berekeningen, facturatie, rapportages.
Strangler fig Nieuwe code groeit om de oude heen en neemt één functie per keer over, met een routeringslaag ertussen. LaagPer stap, plus overgangscode die u later weer verwijdert. Die functie terugrouteren naar de oude code. Een grote legacy-applicatie vervangen.
Illustratie: elke lijn toont welk deel van het productieverkeer het nieuwe systeem verwerkt, door de tijd heen. Gestippeld: schaduwverkeer, vergeleken maar niet bediend.

Cutovergate: geverifieerde data, geteste rollback, geoefende cutover

Hoe plant u een rollback?

Leg vóór de nacht vast wat als mislukt geldt, wie de knoop doorhakt, uiterlijk wanneer, en wat er gebeurt met data die in de tussentijd is geschreven. Microsoft vraagt om rollbacktriggers zoals foutpercentages, een geteste procedure en een met naam aangewezen beslisser voor de rollback. Google voegt daar een maximale tijd per stap aan toe: verstrijkt die, dan volgt de rollback.

Het veilige patroon voor de data kopieert vroeg, houdt de kopie synchroon en maakt de laatste overstap kort: stop de schrijfacties, wacht tot de replicatievertraging nul is en vergelijk dan checksums, niet alleen het aantal rijen. Oefen vóór de nacht het hele runbook met data op productieomvang, en meet de tijd van elke stap. Microsoft noemt dit een mock cutover of generale repetitie.

Na de laatste rij van het runbook betekent de weg terug dat u nieuwe schrijfacties in omgekeerde richting synchroniseert, en Disaster recovery in 2026: RTO versus RPO, de vier DR-strategieën en wat EU DORA vereist wijst erop dat terugschakelen (failback) meestal de moeilijkste helft is, omdat de data opnieuw gesynchroniseerd moet worden.

Voorbeeld van een runbook voor de cutover
WanneerStapWeg terug
Week ervoorChange freeze: pipelines blokkeren releases naar de bron.Niets terug te draaien
Dag ervoorLaatste generale repetitie op data van productieomvang, elke stap getimed.De datum verschuiven
00:00Go/no-go: gatecontroles groen, eigenaar van de rollback benoemd.Hier stoppen
00:05Schrijfacties gestopt; de bron wordt read-only.De bron weer beschrijfbaar maken
00:25Replicatievertraging nul, laatste sync, checksums kloppen.Doelomgeving weggooien, bron weer beschrijfbaar maken
00:45DNS en load balancer wijzen naar de doelomgeving; smoketests slagen.DNS en load balancer terugzetten
01:00Schrijfacties open op de doelomgeving. Deadline voor de rollback.Nieuwe schrijfacties terugspelen naar de bron, of vooruit herstellen
Illustratie: een voorbeeld van een runbook voor de cutover. Uw tijden komen uit de generale repetitie.

Wat verandert er wanneer een migratie als pipeline draait?

Een upgrade van een heel serverpark is één wijziging die honderden keren wordt toegepast. Met de hand blijft elke batch zo klein als mensen kunnen bijhouden.

Bij Nike werden de upgrades van Windows-servers in 900+ winkels met de hand uitgevoerd, verdeeld over vijf teams, tot es.nl ze samenbracht in één self-service pipeline. Elke server kostte daarna ongeveer 3 uur in plaats van 6 tot 8, en er draaiden er 8 veilig parallel in plaats van 2. AWS koppelt de grootte van een golf aan hoeveel parallelle verandering u aankunt. De pipeline verhoogde dat aantal.

Bij ASML zette es.nl de offload van geselecteerde tests van productiemachines naar Google Cloud Platform in gang, om de doorvoer te verhogen en feedbackcycli te verkorten. Geselecteerd is hier het sleutelwoord: een eerste golf gaat naar waar de winst duidelijk is.

Lees de Nike-caseLees de ASML-case

Met de hand 2 servers tegelijk, elk 6 tot 8 uur

Eén pipeline 8 servers tegelijk, elk ongeveer 3 uur

Illustratie: één batch upgrades op een as van 8 uur. Elke balk is een server.

Waar u begint

Ken uw releaseproces vóór de eerste golf

Elke cutover loopt via dezelfde pipelines, goedkeuringen en overdrachten als een gewone release. De gratis Release Check laat in minder dan 5 minuten zien waar de tijd van uw laatste release naartoe ging en wat dat per jaar kost, zonder gesprek.