WELLENPLANUNG · ARCHITEKTURENTSCHEIDUNG
Migrationswellen für Unternehmensanwendungen auf STACKIT planen
Eine Welle ist eine Gruppe von Einheiten, die gemeinsam umzieht. StackToIT berechnet den Teil, der aus Abhängigkeiten folgt: Eine Einheit zieht nach allem um, wovon sie abhängt, und die Schritte des Plans liegen in zehn Phasen von den Entscheidungen bis zur Stilllegung. Welche Anwendung zuerst kommt, entscheidet es nicht. Diese Wahl hängt von gemeinsam genutzten Komponenten, RTO und RPO, Datenmenge und der Kapazität Ihres Teams ab, und der Lauf übernimmt die Werte der Anwendungsdatei genau so, wie Sie sie geschrieben haben.
Vier Wege, die Wellen zu schneiden
Jede Option beantwortet dieselbe Frage anders: Was zieht gemeinsam um, und was muss vorher gelten?
| Option | Was sie bringt | Was sie kostet |
|---|---|---|
| Nach Schicht: Netzwerk, dann Daten, dann Workloads | Die Reihenfolge, die StackToIT berechnet. Jede Abhängigkeit wird beachtet, und jede Schicht wird einmal für die ganze Umgebung getestet. | Anwendungen erreichen ihren Cutover spät und gemeinsam. Quelle und Ziel laufen das ganze Programm hindurch nebeneinander. |
| Nach Anwendung: erst ein Pilot, dann der Rest | Ein Team lernt den vollständigen Weg an einer Anwendung. Das Cloud Adoption Framework von Microsoft rät, mit einfacheren Workloads zu beginnen und ein bis zwei komplexe in frühe Wellen zu legen. | Gemeinsames Netzwerk, Security Groups und Identität müssen zuerst stehen, und was eine Anwendung mit einer zurückbleibenden teilt, braucht bis zur letzten Welle eine Verbindung zwischen beiden Seiten. |
| Nach Risiko: Unkritisches zuerst, Kritisches zuletzt | Kritische Systeme ziehen um, nachdem sich der Ablauf bewährt hat. Nicht-Produktionsumgebungen kommen vor der Produktion. | Ihre kritischste Anwendung braucht eine Methode mit nahezu keiner Ausfallzeit, mit Replikation und getestetem Rollback, und sie ist zuletzt eingeplant, wartet also am längsten auf der Quelle. |
| Ein Fenster für die ganze Umgebung | Ein Schreibstopp, ein Cutover, eine GO-oder-ROLLBACK-Entscheidung. Keine Phase, in der zwei Umgebungen voneinander abhängen. | Alles wird auf einmal beurteilt, das Fenster muss alle Datenumzüge fassen, und ein Fehler wirft die ganze Umgebung zurück. |
Die erste Zeile ist das, was der Lauf berechnet. Die übrigen drei sind Entscheidungen, die Sie darauf aufsetzen; der Lauf stellt keine Rangfolge zwischen ihnen auf.
Was der Lauf mit einer Anwendungsdatei macht
Eine AWS-Umgebung mit 13 Ressourcen und zwei Anwendungen, bewertet am 4. November 2026. Links: die Anwendung Billing, wie die Anwendungsdatei sie beschreibt. Rechts: waves.csv des Laufs, vollständig.
- 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,Anwendungen sind bestätigt
Die sieben in der Datei genannten Einheiten zeigen application CONFIRMED mit dem Namen der Anwendung daneben. Die Server und Datenbanken beider Anwendungen teilen sich die dritte Einheitenwelle.
Gemeinsame Einheiten bleiben unzugeordnet
Die Security Group, die beide Anwendungen nutzen, ist als SHARED markiert und gehört keiner. Die Wellenplanung muss sie als Voraussetzung beider behandeln.
Die Datei änderte die Reihenfolge nicht
Ein zweiter Lauf derselben Umgebung ohne Anwendungsdatei ergab dieselben Wellen und dieselben 138 Schritte. Die Datei ergänzt Verantwortliche, Kritikalität, RTO und RPO wie geschrieben, aber keine andere Reihenfolge.
Die Einheiten in Abhängigkeitsreihenfolge
| Einheitenwelle | Einheiten | Warum sie dort stehen |
|---|---|---|
| 1 | billing_archive und shop_assets (DIRECT), billing_events (REPLATFORM), die VPC (RECONFIGURE) | Sie hängen von keiner anderen Einheit ab. Die Buckets können ihre erste Kopie früh beginnen, lange vor dem Cutover ihrer Anwendungen. |
| 2 | Die Security Group und drei Subnetze (RECONFIGURE) | Sie warten auf die VPC. Server und Datenbanken warten wiederum auf sie. |
| 3 | billing_db und shop_db (REPLATFORM), billing_app und shop_web (RECONFIGURE) | Sie hängen von den Netzwerken ab. In dieser Welle werden die Anwendungen umziehbar. |
Das ist technical-sequencing.md des Laufs. Sie ordnet 12 Einheiten in drei Einheitenwellen; die Migrationsplan-Datei legt die 138 Schritte des Plans in zehn Wellen aus. Die beiden Zählungen meinen nicht dasselbe; sagen Sie also dazu, welche Sie meinen, wenn Sie von Welle 3 sprechen.
Die zehn Wellen des Plans
| Planwelle | Was die Migrationsplan-Datei dort einordnet | In diesem Lauf |
|---|---|---|
| 0 Decisions | Fragen, die noch niemand beantwortet hat | 5 Entscheidungen mit 8 Fragen, auf die Schritte warten |
| 1 Landing zone | Das Projekt und die Voraussetzungen, die eine Person vor dem ersten Apply bereitstellt | Kein Schritt; das Projekt stellen Sie bereit |
| 2 Network and security | Netzwerke, Routing und Security Groups | 5 Arbeitspakete |
| 3 Data services | Datenbanken, Objektspeicher und Volumes | 2 Arbeitspakete |
| 4 Platform | Kubernetes, Load Balancer, Logging und andere gemeinsame Dienste | 1 Arbeitspaket |
| 5 Workloads | Server und das, was an ihnen hängt | 2 Arbeitspakete |
| 6 Data migration | Daten von der Quelle in die neuen Dienste kopieren | 3 Arbeitspakete mit 20, 24 und 12 Schritten |
| 7 Cutover | Verkehr umschalten und die Schritte, die vor der Produktion stehen müssen | 5 Arbeitspakete |
| 8 Verification | Die migrierte Umgebung prüfen | 5 Arbeitspakete |
| 9 Decommission | Die Quelle stilllegen | 4 Arbeitspakete |
Der Plan hat 138 Schritte: 24 automatisiert und 114 manuell, in 27 Arbeitspaketen. Von den 138 gehören 111 zu einer der beiden Anwendungen, der Rest zur Umgebung.
Die Gates, die die ganze Umgebung betreffen
Auch die Wellenplanung nach Anwendung stößt auf sie. Sie stammen aus execution-plan.json des Laufs, und an ihnen muss Ihr eigener Schnitt ansetzen.
Ein Bereitschafts-Gate vor jedem Cutover
Der Readiness-Schritt wartet auf 23 Schritte: jeden Workload-Schritt und jeden Datenumzug. Der Plan weiß nicht, welcher Einstiegspunkt welchen Speicher bedient; deshalb wartet jede Umschaltung auf alle.
Eine GO-oder-ROLLBACK-Entscheidung
Die Rollback-Entscheidung wartet auf 32 Schritte. GO gibt die Quellressourcen zur Stilllegung frei; ROLLBACK macht den Cutover rückgängig und lässt die Quelle weiter bedienen. Die Stilllegungsschritte stehen dahinter.
Ist das Gate geteilt, ist eine Umschaltung klein
Die Verkehrsumschaltung eines Servers hat 4 direkte Vorgänger: ihren Server, ihre Netzwerkschnittstelle, die Entscheidung zum Boot-Image und das umgebungsweite Readiness-Gate. Nehmen Sie dieses Gate je Anwendung aus dem Pfad, bleibt die Umschaltung selbst ein kleiner Schritt; an diesem Gate setzen Sie den Schnitt.
Datenumzüge sind keine Cutover
Für einen Bucket sieht der Plan eine erste Kopie bei laufenden Schreibzugriffen vor, wiederholte Kopien, bis ein Durchlauf ins Schreibstopp-Fenster passt, und dann einen Abgleich. Beginnen Sie damit früh, schrumpft der Cutover der Welle auf eine Umschaltung.
Entscheidungen sind eine eigene Welle
Welle 0 steuern Sie vollständig selbst. Jede Antwort, ob zu Boot-Image, Datenumzugsmethode, der Freigabe einer noch veränderlichen Messaging-API oder der Standard-Egress-Regel, schaltet Schritte späterer Wellen frei.
So entscheiden Sie, der Reihe nach
Gemeinsames auflisten
Lesen Sie die SHARED-Zeilen und die nicht zugeordneten Einheiten. Gemeinsame Netzwerke, Gruppen und Queues entscheiden, welche Anwendung überhaupt zuerst gehen kann; AWS Prescriptive Guidance nennt Abhängigkeiten als Grund, eine Anwendung zurückzuhalten, bis andere umgezogen sind.
Die Anwendungsdatei schreiben
Geben Sie jeder Anwendung Verantwortliche, Kritikalität, RTO und RPO. Der Lauf behält sie wie geschrieben und setzt sie neben jede Einheit; er rechnet nichts daraus.
Die Pilotanwendung wählen
Wählen Sie eine Anwendung mittlerer Kritikalität mit einer repräsentativen Datenbank, nicht den einfachsten Bucket. Ein Pilot, der einen Datenbankumzug durchspielt, erprobt den Weg, den später die kritische Anwendung nimmt.
Die Gates teilen
Machen Sie aus den umgebungsweiten Gates für Bereitschaft und Rollback je eines pro Welle Ihres eigenen Plans und behalten Sie darin jeweils die Schrittfolge des Laufs bei. Tun Sie das in Ihrem eigenen Terminplan: Der Lauf behält je ein Gate dieser Art, auch nach einem neuen Lauf mit Ihren Antworten.
Schreibstopp-Fenster mit dem Fachbereich festlegen
Das Cloud Adoption Framework von Microsoft rät davon ab, Migrationen in kritischen Geschäftsphasen zu legen, und verlangt vor dem ersten Umzug einen getesteten Rollback-Plan.
Fragen, die Architekten stellen
Erzeugt StackToIT einen Terminplan?
Nein. Der Migrationsplan sagt selbst, dass eine Welle ein Ausgangspunkt für den Terminplan ist, kein Terminplan. Der Lauf ordnet Einheiten nach Abhängigkeit und legt die Schritte mit Verantwortlichen und Bedingungen aus; Termine, Fenster und Kapazität kommen von Ihnen.
Kann die Anwendungsdatei die Wellen umordnen?
In diesem Build nicht: Dieselbe Umgebung ergab mit und ohne Datei identische Einheitenwellen und dieselben 138 Schritte. Nutzen Sie die Datei, um festzuhalten, wer was verantwortet und welche RTO und RPO gelten, und schneiden Sie die Anwendungswellen selbst.
Welche Anwendung soll zuerst umziehen?
Der Lauf stellt keine Rangfolge auf. Das Cloud Adoption Framework von Microsoft schlägt risikoarme, eigenständige Workloads zuerst vor und ein bis zwei repräsentative komplexe Workloads in frühen Wellen. In der Umgebung oben spräche das für die weniger kritische Anwendung mit Datenbank; die kritische käme danach.
Warum stehen Buckets in der ersten Einheitenwelle, ihre Anwendung aber in der dritten?
Ein Bucket hängt von keiner Netzwerkeinheit ab und kann deshalb früh kopiert werden. Der Cutover seiner Verbraucher wartet weiterhin auf die eigene Welle der Anwendung; eine frühe Kopie verkürzt also das spätere Fenster, statt die Reihenfolge zu ändern.
Quellen
Ihr nächster Schritt: STACKIT.
Erzählen Sie uns von Ihrer Umgebung. Wir zeigen Ihnen, was StackToIT dafür liefert: Zielarchitektur, Terraform-Artefakte und einen strukturierten Migrationsplan.