Migration Wave Planning: Workloads richtig sequenzieren

Eine Cloud-Migration ist kein Big-Bang-Ereignis — sie ist eine Serie sorgfältig geplanter Wellen. Wer hundert Applikationen gleichzeitig migriert, riskiert Chaos; wer ohne Strategie sequenziert, verschwendet Monate mit unnötigen Abhängigkeitsproblemen. Wave Planning ist die Kunst, ein Workload-Portfolio so zu strukturieren, dass jede Migrationswelle planbar, testbar und rückrollbar bleibt.

Dieser Artikel beschreibt, wie Storm Reply in Road.MAP-Projekten Wave-Pläne für Enterprise-Portfolios von 50 bis über 2.000 Workloads erstellt — welche Kriterien zählen, welche Werkzeuge helfen und welche Fehler die meisten Projekte machen.

Warum Wave Planning über Erfolg oder Misserfolg entscheidet

Die häufigste Ursache für Verzögerungen in Migrationsprojekten ist nicht die Technik — es ist schlechte Sequenzierung. Teams starten mit Applikationen, die komplexe On-Premises-Abhängigkeiten haben, entdecken dies erst beim Cutover und verlieren Wochen mit Nacharbeiten.

Gutes Wave Planning löst dieses Problem vor dem ersten Cutover: durch vollständige Abhängigkeitskartierung, risikobasierte Priorisierung und eine klare Reihenfolge, die Infrastruktur-Grundlagen vor Applikationen und Low-Risk-Workloads vor geschäftskritischen Systemen platziert.

Die vier Dimensionen der Workload-Priorisierung

Im Road.MAP-Prozess bewertet Storm Reply jeden Workload entlang von vier Dimensionen, bevor er einer Welle zugeordnet wird:

Dimension	Bewertungskriterien	Einfluss auf Wellenposition
Technische Komplexität	Anzahl Abhängigkeiten, Datenbanktyp, OS-Version, Netzwerk-Anforderungen	Hoch = spätere Wellen; Einfach = frühe Wellen
Business-Kritikalität	Umsatzrelevanz, SLA-Anforderungen, Nutzeranzahl, Regulatorik	Kritisch = mittlere Wellen nach Prozesserprobung
Migrationsstrategie	Rehost, Replatform, Refactor — Aufwand pro Strategie	Rehost = früh; Refactor = spät oder Post-Migration
Abhängigkeitsgraph	Vor- und nachgelagerte Applikationen, Datenbank-Shared-Services, gemeinsame Infrastruktur	Fundamente zuerst, abhängige Systeme danach

Der Road.MAP Wave-Planning-Prozess in fünf Schritten

1. Abhängigkeitsgraph erstellen: Auf Basis der Discovery-Daten (AWS Application Discovery Service oder Agenten) wird ein vollständiger Abhängigkeitsgraph erstellt. Jede Applikation ist ein Knoten; Kommunikationsbeziehungen sind Kanten. Tools wie Migration Hub visualisieren diesen Graphen.
2. Cluster bilden: Applikationen, die kommunizieren und eng miteinander verknüpft sind, werden zu Migrationsclustern zusammengefasst. Ein Cluster migriert in einer Welle — nie aufgeteilt auf mehrere.
3. Wellen priorisieren: Die vier Dimensionen (Komplexität, Kritikalität, Strategie, Abhängigkeit) werden gewichtet und ergeben eine Wellenzuordnung. Welle 1 enthält immer Infrastrukturkomponenten und einfache Workloads ohne Abhängigkeiten — als Prozess-Testlauf.
4. Ressourcen planen: Jede Welle erhält eine Zeitplanung: Replikationsstart (T-4 Wochen), Test-Cutover (T-2 Wochen), Produktions-Cutover (T-0), Hypercare-Ende (T+4 Wochen). Personalengpässe werden sichtbar und umgeplant.
5. Go/No-Go-Kriterien definieren: Vor jedem Cutover müssen messbare Kriterien erfüllt sein: erfolgreicher Test-Cutover, Monitoring aktiv, Rollback-Plan unterschrieben, Kommunikation an Stakeholder gesendet. Kein Cutover ohne grünes Licht.

Wellenarchitektur: Typische Struktur für ein 300-App-Portfolio

Welle 0 — Infrastruktur & Foundation

Shared Services, Active Directory, DNS, Monitoring-Agenten, Backup-Services. Keine Geschäftsapplikation — nur das technische Fundament. Dauer: 2–4 Wochen.

Welle 1 — Piloten (Low Risk)

5–15 nicht-kritische Applikationen ohne externe Abhängigkeiten. Ziel: Prozesse validieren, Team schulen, Confidence aufbauen. Dauer: 4–6 Wochen inkl. Hypercare.

Wellen 2–N — Skalierung

Iterative Migration der restlichen Applikationen in Clustern von 20–50 Servern pro Welle. Kritische Systeme ab Welle 3–4, wenn Prozessreife bewiesen. Durchschnittliche Wellenfrequenz: alle 4–6 Wochen.

Abschlusswelle — Legacy & Grenzfälle

Die letzten 5–10 % des Portfolios: Applikationen mit besonderen Anforderungen, die individuelle Lösungen brauchen. Oft enthalten: Mainframe-Schnittstellen, proprietäre Hardware-Abhängigkeiten.

Häufige Wave-Planning-Fehler und wie Road.MAP sie verhindert

Drei Muster beobachten Storm-Reply-Berater in fast jedem Migrationsprojekt, das ohne strukturiertes Wave Planning startet:

Fehler 1: Kritische Applikationen in frühen Wellen. Der Druck, schnell sichtbare Fortschritte zu zeigen, verleitet dazu, wichtige Systeme früh zu migrieren — bevor Prozesse eingespielt sind. Road.MAP verhindert dies durch die explizite Regel: Welle 1 enthält ausschließlich Low-Risk-Workloads.

Fehler 2: Cluster aufteilen. Applikationen, die miteinander kommunizieren, werden aus Ressourcengründen auf verschiedene Wellen verteilt. Das Ergebnis: Netzwerk-Latenz zwischen On-Premises und AWS, Timeouts, manuelle Workarounds. Road.MAP-Regel: Cluster bleibt immer zusammen.

Fehler 3: Keine Hypercare eingeplant. Nach dem Cutover fehlen Ressourcen für Support. Jeder Workload erhält in Road.MAP vier Wochen Hypercare-Budget — explizit im Wave-Plan und in der Ressourcenplanung.

Häufig gestellte Fragen zum Wave Planning

Wie viele Applikationen sollten in einer Migrationswelle enthalten sein?

Die optimale Wellengröße hängt von Teamgröße und Applikationskomplexität ab. Als Richtwert gilt: 10–30 Server pro Welle bei einem dreiköpfigen Migration-Factory-Team. Erste Wellen sollten bewusst kleiner sein (5–10 Server), um Prozesse einzuspielen und Vertrauen aufzubauen.

Was passiert, wenn eine Welle nicht abgeschlossen werden kann?

Jede Welle im Road.MAP-Framework verfügt über einen Rollback-Plan. Kann eine Applikation nicht erfolgreich migriert werden, wird sie aus der Welle herausgenommen und in der nächsten Welle neu eingeplant — nach Analyse der Ursache. Die übrigen Applikationen der Welle sind davon nicht betroffen.

Wie wird der Wave-Plan bei Änderungen im Portfolio aktualisiert?

Wave-Pläne sind lebende Dokumente. Im Road.MAP-Prozess gibt es wöchentliche Wave-Review-Meetings, in denen neue Erkenntnisse aus abgeschlossenen Wellen in die Planung der Folgewellen einfließen. Das Tool AWS Migration Hub dient als zentrale Statusübersicht.

Wie geht Road.MAP mit SAP-Migrationen im Wave-Plan um?

SAP-Systeme (ECC, S/4HANA, BW) werden aufgrund ihrer Komplexität und Kritikalität immer als eigener Cluster behandelt und in mittlere bis späte Wellen eingeplant. Storm Reply verfügt über SAP-on-AWS-Zertifizierungen und spezifische SAP-Runbooks im Road.MAP-Framework.