GOLVENPLANNING · ARCHITECTUURBESLISSING
Migratiegolven plannen voor enterprise-applicaties op STACKIT
Een golf is een groep eenheden die samen verhuist. StackToIT berekent het deel dat uit afhankelijkheden volgt: een eenheid verhuist na alles waarvan die afhangt, en de stappen van het plan liggen verdeeld over tien fasen, van beslissingen tot ontmanteling. StackToIT bepaalt niet welke applicatie als eerste gaat. Die keuze hangt af van gedeelde componenten, RTO en RPO, datavolume en de capaciteit van uw team, en de run bewaart de waarden uit het applicatiebestand precies zoals u ze schreef.
Vier manieren om de golven te knippen
Elke optie beantwoordt dezelfde vraag anders: wat verhuist samen, en wat moet waar zijn voordat het gebeurt.
| Optie | Wat het u oplevert | Wat het kost |
|---|---|---|
| Per laag: netwerk, dan data, dan workloads | De volgorde die StackToIT berekent. Elke afhankelijkheid wordt gerespecteerd en elke laag wordt één keer getest voor de hele omgeving. | Applicaties bereiken hun cutover laat en tegelijk. Bron en doel draaien het hele programma naast elkaar. |
| Per applicatie: eerst een pilot, dan de rest | Een team leert het volledige pad op één applicatie. Het Microsoft Cloud Adoption Framework adviseert te beginnen met eenvoudigere workloads en in vroege golven ook één of twee complexe workloads op te nemen. | Het gedeelde netwerk, de security groups en de identiteit moeten eerst bestaan, en alles wat een applicatie deelt met een applicatie die achterblijft, heeft tot de laatste golf een koppeling tussen beide zijden nodig. |
| Per risico: de minst kritieke eerst, de kritieke laatst | Kritieke systemen verhuizen nadat het proces zich heeft bewezen. Niet-productieomgevingen gaan vóór productie. | Uw meest kritieke applicatie vereist een methode met vrijwel geen downtime, met replicatie en een geteste rollback, en wordt als laatste ingepland, dus die wacht het langst op de bron. |
| Eén venster voor de hele omgeving | Eén schrijfstop, één cutover, één GO- of ROLLBACK-beslissing. Geen periode waarin twee omgevingen van elkaar afhangen. | Alles wordt in één keer beoordeeld, het venster moet alle dataverplaatsingen bevatten en bij een mislukte cutover gaat de hele omgeving terug. |
De eerste rij is wat de run berekent. De andere drie zijn keuzes die u daarbovenop maakt; de run biedt geen rangschikking daartussen.
Wat de run met een applicatiebestand doet
Een AWS-omgeving van 13 resources met twee applicaties, beoordeeld op 4 november 2026. Links: de billing-applicatie zoals het applicatiebestand die vermeldt. Rechts: het volledige waves.csv van de run.
- id: billing
name: Billing
selectors:
- aws_instance.billing_app
- aws_db_instance.billing_db
- aws_sqs_queue.billing_events
- aws_s3_bucket.billing_archive
environment: production
owners:
business: finance
technical: billing-platform
business_criticality: critical
availability:
rto: 30m
rpo: 5m
downtime_tolerance: 15m
data:
classification: confidential
sovereignty:
tier: mandatorywave,wave_state,unit,type,module_call,presence,class,confidence,application,application_status,proposed_group
1,MEMBER,aws_s3_bucket.billing_archive,aws_s3_bucket,,KNOWN_PRESENT,DIRECT,MEDIUM,billing,CONFIRMED,
1,MEMBER,aws_s3_bucket.shop_assets,aws_s3_bucket,,KNOWN_PRESENT,DIRECT,MEDIUM,shop,CONFIRMED,
1,MEMBER,aws_sqs_queue.billing_events,aws_sqs_queue,,KNOWN_PRESENT,REPLATFORM,MEDIUM,billing,CONFIRMED,
1,MEMBER,aws_vpc.core,aws_vpc,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,UNASSIGNED,UNASSIGNED,
2,MEMBER,aws_security_group.web,aws_security_group,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,UNASSIGNED,SHARED,billing_app; shop_web
2,MEMBER,aws_subnet.db_a,aws_subnet,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,UNASSIGNED,UNASSIGNED,
2,MEMBER,aws_subnet.db_b,aws_subnet,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,UNASSIGNED,UNASSIGNED,
2,MEMBER,aws_subnet.web,aws_subnet,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,UNASSIGNED,UNASSIGNED,
3,MEMBER,aws_db_instance.billing_db,aws_db_instance,,KNOWN_PRESENT,REPLATFORM,MEDIUM,billing,CONFIRMED,
3,MEMBER,aws_db_instance.shop_db,aws_db_instance,,KNOWN_PRESENT,REPLATFORM,MEDIUM,shop,CONFIRMED,
3,MEMBER,aws_instance.billing_app,aws_instance,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,billing,CONFIRMED,
3,MEMBER,aws_instance.shop_web,aws_instance,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,shop,CONFIRMED,Applicaties zijn bevestigd
De zeven eenheden die het bestand noemt, tonen application CONFIRMED met de naam van de applicatie ernaast. De servers en databases van beide applicaties delen de derde eenheidsgolf.
Gedeelde eenheden blijven niet toegewezen
De security group die beide applicaties gebruiken, is gemarkeerd als SHARED en hoort bij geen van beide. De golvenplanning moet die behandelen als voorwaarde voor beide.
Het bestand veranderde de volgorde niet
Een tweede run van dezelfde omgeving zonder het applicatiebestand leverde dezelfde golven en dezelfde 138 stappen op. Het bestand voegt eigenaren, kritikaliteit, RTO en RPO toe zoals geschreven, geen andere volgorde.
De eenheden in volgorde van afhankelijkheid
| Eenheidsgolf | Eenheden | Waarom ze daar staan |
|---|---|---|
| 1 | billing_archive en shop_assets (DIRECT), billing_events (REPLATFORM), de VPC (RECONFIGURE) | Ze zijn van geen enkele andere eenheid afhankelijk. Het kopiëren van de buckets kan vroeg beginnen, lang voordat hun applicaties overschakelen. |
| 2 | De security group en drie subnets (RECONFIGURE) | Ze wachten op de VPC. Servers en databases wachten op hun beurt op deze eenheden. |
| 3 | billing_db en shop_db (REPLATFORM), billing_app en shop_web (RECONFIGURE) | Ze zijn afhankelijk van de netwerken. In deze golf worden de applicaties verplaatsbaar. |
Dit is technical-sequencing.md van de run. Het ordent 12 eenheden in drie eenheidsgolven; het migratieplan legt de 138 stappen van het plan uit over tien golven. De twee nummeringen zijn niet hetzelfde, dus geef aan welke nummering u bedoelt als u het over golf 3 hebt.
De tien golven van het plan
| Plangolf | Wat het migratieplan daar neerzet | In deze run |
|---|---|---|
| 0 Beslissingen | Vragen die nog niemand heeft beantwoord | 5 beslissingen met 8 vragen waar stappen op wachten |
| 1 Landing zone | Het project en de voorwaarden die iemand levert vóór de eerste apply | Geen stap; het project levert u zelf |
| 2 Netwerk en beveiliging | Netwerken, routering en security groups | 5 werkpakketten |
| 3 Dataservices | Databases, objectopslag en volumes | 2 werkpakketten |
| 4 Platform | Kubernetes, load balancers, logging en andere gedeelde services | 1 werkpakket |
| 5 Workloads | Servers en wat eraan hangt | 2 werkpakketten |
| 6 Datamigratie | Data van de bron naar de nieuwe services kopiëren | 3 werkpakketten van 20, 24 en 12 stappen |
| 7 Cutover | Verkeer verplaatsen en de stappen die vóór productie moeten komen | 5 werkpakketten |
| 8 Verificatie | De gemigreerde omgeving controleren | 5 werkpakketten |
| 9 Ontmanteling | De bron uitfaseren | 4 werkpakketten |
Het plan bevat 138 stappen: 24 geautomatiseerd en 114 handmatig, in 27 werkpakketten. Van die 138 horen er 111 bij een van de twee applicaties; de rest hoort bij de omgeving.
De gates die de hele omgeving beslaan
Ook golvenplanning per applicatie loopt hier tegenaan. Ze komen uit execution-plan.json van de run, en hier moet u uw eigen indeling aanbrengen.
Eén readiness-gate vóór elke cutover
De readinessstap wacht op 23 stappen: elke workloadstap en elke dataverplaatsing. Het plan weet niet welk entrypoint welke opslag bedient, dus elke omschakeling wacht op al die stappen.
Eén GO- of ROLLBACK-beslissing
De rollbackbeslissing wacht op 32 stappen. GO geeft vrij om de bronresources uit te faseren; ROLLBACK draait de cutover terug en houdt de bron in bedrijf. Uitfaseringsstappen wachten erachter.
Een omschakeling is klein zodra de gate is gesplitst
De verkeersomschakeling van een server heeft 4 directe voorgangers: de server, de netwerkinterface, de beslissing over het bootimage en de readiness-gate voor de hele omgeving. Haal die gate per applicatie uit het pad en de omschakeling zelf is een kleine stap; de gate is waar u knipt.
Dataverplaatsingen zijn geen cutovers
Voor een bucket kent het plan een eerste kopie terwijl de schrijvers blijven schrijven, herhaalde kopieën tot een ronde in het venster voor de schrijfstop past, en dan een reconcile. Begin daar vroeg mee en de cutover van de golf krimpt tot een omschakeling.
Beslissingen zijn een golf op zich
Golf 0 is de golf die u volledig in eigen hand hebt. Elk antwoord, of het nu een bootimage is, een methode voor dataverplaatsing, de opt-in voor een messaging-API die nog kan veranderen of de standaard egressregel, geeft stappen in latere golven vrij.
Zo beslist u, in volgorde
Som op wat gedeeld is
Lees de SHARED-rijen en de niet-toegewezen eenheden. Gedeelde netwerken, groepen en wachtrijen bepalen welke applicatie überhaupt als eerste kan gaan, en AWS Prescriptive Guidance noemt afhankelijkheden als reden om een applicatie achter te houden tot andere zijn verhuisd.
Schrijf het applicatiebestand
Geef elke applicatie eigenaren, kritikaliteit, RTO en RPO. De run bewaart ze zoals geschreven en zet ze naast elke eenheid; hij berekent er niets mee.
Kies de pilot
Kies een applicatie van gemiddelde kritikaliteit met een representatieve database, niet de eenvoudigste bucket. Een pilot die een databaseverplaatsing oefent, bewijst het pad dat de kritieke applicatie zal volgen.
Splits de gates
Maak van de readiness- en rollbackgates voor de hele omgeving er één per golf in uw eigen golfindeling, en behoud de stapvolgorde van de run binnen elke golf. Doe dit in uw eigen planning: de run houdt van elke soort één gate, ook na een nieuwe run met uw antwoorden.
Leg de vensters voor de schrijfstop vast met de business
Het Microsoft Cloud Adoption Framework raadt af om migraties in kritieke bedrijfsperioden in te plannen en vraagt om een getest rollbackplan vóór de eerste verhuizing.
Vragen van architecten
Maakt StackToIT een planning?
Nee. Het migratieplan zegt dat een golf een vertrekpunt voor de planning is en geen planning. De run ordent eenheden op afhankelijkheid en legt de stappen vast met hun eigenaren en voorwaarden; datums, vensters en capaciteit komen van u.
Kan het applicatiebestand de golven herordenen?
In deze build niet: dezelfde omgeving gaf met en zonder het bestand identieke eenheidsgolven en dezelfde 138 stappen. Gebruik het bestand om vast te leggen wie waarvan eigenaar is en welke RTO en RPO gelden, en knip de applicatiegolven zelf.
Welke applicatie moet als eerste verhuizen?
De run kent geen rangschikking. Het Microsoft Cloud Adoption Framework stelt eenvoudige workloads met laag risico eerst voor en één of twee representatieve complexe workloads in vroege golven. In de omgeving hierboven wijst dat naar de minder kritieke applicatie met een database, met de kritieke erna.
Waarom staan buckets in de eerste eenheidsgolf terwijl hun applicatie in de derde staat?
Een bucket hangt van geen enkele netwerkeenheid af en kan dus vroeg worden gekopieerd. De cutover van de consumenten ervan wacht nog op de golf van de applicatie zelf, dus een vroege kopie verkort het latere venster in plaats van de volgorde te wijzigen.
Bronnen
Uw volgende stap: STACKIT.
Vertel ons over uw omgeving, dan laten wij zien wat StackToIT daarvoor oplevert: doelarchitectuur, Terraform-artefacten en een gestructureerd migratieplan.
Laat uw gegevens achter, onze specialisten nemen contact met u op.
Liever zelf een e-mail sturen? connect@stacktoit.com
Hartelijk dank.
Uw verzoek is bij ons binnengekomen. Onze specialisten nemen contact met u op.