Migrationsplan

Überblick: Dieses Modul

Der Migrationsplan ist der Übergang von Analyse zur konkreten Umsetzung. Er folgt auf Discovery und wird durch das Modul Design laufend mit umsetzbaren Details gefüllt.

Ziel ist es, die Erkenntnisse aus Discovery und Design in einen detaillierten, schrittweisen Migrationsplan zu überführen, den Delivery-Teams mit hoher Verlässlichkeit umsetzen können.

Damit bildet dieses Modul die Brücke zwischen Strategie und Ausführung und ist zentral für den Gesamterfolg der Migration.

Kernaktivitäten

Wellenbasierte Planung

Anwendungen in logische Migrationswellen gruppieren, basierend auf Abhängigkeiten, Geschäftskritikalität und technischer Komplexität.

Migrations-Runbooks

Detaillierte Schritt-für-Schritt-Runbooks je Welle oder Anwendung erstellen, inklusive Vorbereitung, Ausführung, Cutover, Rollback und Validierung.

Ressourcenplanung

Nötige Teams, Fähigkeiten, Werkzeuge und Experten je Welle festlegen, einschließlich Enablement- und Schulungsplanung.

Umsetzungs-Governance

Verbindliche Governance-Prozesse, Verantwortlichkeiten, Kommunikationsroutinen und Cutover-Kontrollen für die Wellenumsetzung etablieren.

Agilität als Grundprinzip

Migrationsplanung muss anpassungsfähig bleiben. Programme sollten frühe Wellen möglichst schnell starten und gleichzeitig Wellenschnitt und Reihenfolge kontinuierlich nachziehen, sobald neue Discovery- und Design-Ergebnisse vorliegen.

Runbooks sind lebende Dokumente. Nach jedem Cutover sollten Teams die Runbooks überarbeiten und verbessern. Mit steigender Runbook-Qualität steigt typischerweise auch die Migrationsgeschwindigkeit von Welle zu Welle.

Skalierung großer Migrationen in der Praxis

In großen Migrationsprogrammen liegt der Fokus auf skalierter Umsetzung. Typisch ist, mit kleinen Wellen zu starten (z. B. 5 Server/Woche) und den Durchsatz schrittweise zu steigern (z. B. auf 50-100 Server/Woche), abhängig von Restriktionen und Reifegrad.

Die ersten Wellen sind bewusst kleiner, damit Portfolio- und Migrations-Workstream ihre Prozesse stabilisieren, Annahmen validieren und Runbooks verbessern können. Dieser Lernzyklus ist ein zentraler Erfolgsfaktor in großen Migrationen.

Betriebsmodell der Migration Factory

In diesem Modul wird die Migration Factory typischerweise über vier Bausteine gesteuert:

Project Governance Rules

Prozesse und Werkzeuge zur Steuerung von Wellen, Kommunikation, Zeitplänen und Cutovers, damit Aufgaben in der richtigen Reihenfolge und zum richtigen Zeitpunkt ausgeführt werden.

Portfolio-Runbooks

Runbooks zur Priorisierung von Anwendungen, Planung von Wellen und Erhebung der nötigen Metadaten als Eingangsmaterial für die Umsetzung.

Migrations-Runbooks

Runbooks für die technische Umsetzung der Wellen, das Laden von Metadaten in Migrationswerkzeuge sowie Cutover und Validierung.

Best Practices und Health-Check-Matrix

Regelmäßiger Health-Check zur Fortschrittsbewertung, frühen Risikoerkennung und Stabilisierung der Auslieferung.

Datenfluss durch Portfolio- und Migrations-Workstream

Runbooks bilden den Datenfluss über zwei verbundene Workstreams:

• Portfolio-Workstream: Priorisiert Anwendungen und bereitet Metadaten für kommende Wellen auf.
• Migrations-Workstream: Führt Migrationen und Cutover gemäß freigegebenem Wellenplan aus.

Teams sind meist auf bestimmte Teile der Factory spezialisiert, während die Wellen durch beide Workstreams fließen. Um Engpässe zu vermeiden, sollten ausreichend vorbereitete Wellen vor der Ausführung bereitstehen. Ein bewährter Richtwert ist, den Portfolio-Workstream fünf Wellen vor dem Migrations-Workstream zu halten.

Klare Abgrenzung von Portfolio und Migration

Für Steuerung und Kapazitätsplanung ist die Unterscheidung zwischen Funktion und Team wichtig:

• Portfolio: Fachliche und technische Vorbereitung einer Welle, inklusive Priorisierung, Abhängigkeitsklärung, Scope-Schnitt, Datenqualität und Readiness-Nachweis.
• Portfolio Team: Rollen, die Portfolio-Arbeit ausführen und verantworten (z. B. Programmleitung, Domain-Owner, Architekt:innen, Application-Owner und Governance).
• Migration: Operative Umsetzung der freigegebenen Welle mit Runbook-Ausführung, Change-/Cutover-Steuerung, Validierung, Stabilisierung und dokumentiertem Abschluss.
• Migration Team: Rollen, die technische Migration durchführen und absichern (z. B. Factory-Engineers, Plattform-Team, Netzwerk/Security, Test und Betriebsübergabe).

Beide Teams sind eng gekoppelt, übernehmen aber unterschiedliche Lieferobjekte:

• Portfolio Team liefert: Freigegebene Wellenzuschnitte, priorisierte Backlogs, vollständige Metadaten und umsetzungsfähige Eingangspakete.
• Migration Team liefert: Erfolgreiche Cutovers, validierte Zielzustände, Lessons Learned und verbesserte Runbook-Versionen für Folgewellen.

Dynamisches Wellenmuster in der Umsetzung

Ein typisches Muster ist:

• Portfolio-Taktung: Etwa 1-2 Wochen je Welle für Vorbereitung.
• Migrations-Taktung: Etwa 3-4 Wochen je Welle für Umsetzung und Cutover.
• Wellenpuffer: Ein Puffer von fünf Wellen zwischen Portfolio- und Migrations-Workstream.

Bevor die Migrationsumsetzung in den Regelbetrieb übergeht, wird typischerweise ein initialer Wellenpuffer aufgebaut. Ab dem Start der Ausführung laufen beide Workstreams parallel weiter, und der Puffer verhindert Lieferengpässe.

Phasen- und Modulmodell in der Wellenplanung

Die folgende Darstellung zeigt das operative Zielbild mit unserem Phasen- und Modulmodell: Der Planungsanteil liegt im Modul Migrationsplan (Design and Mobilize), die Ausführung läuft im Migrationsmodul in versetzten Wellen.

In diesem Modell sind die Phasengrenzen bewusst überlappend aufgebaut:

• Design and Mobilize startet mit der Wellenplanung und bleibt bis zum Ende der Planung von Welle 8 aktiv (bis Woche 3).
• Migrate startet bereits in Woche 3 und läuft über die verbleibende Zeitachse weiter.
• Pilotwelle und Anpassungen: Welle 1 ist als kürzere Pilotwelle zur Erstvalidierung ausgelegt; danach folgen gezielte Factory-Setup-Anpassungen in den ersten produktiven Wellen.

Der detaillierte Setup-Umfang ist im eigenen Kapitel beschrieben: Migration Factory Setup.

Seitlich wischen, um das ganze Diagramm zu sehen

Das Muster bleibt bewusst dynamisch: Portfolio-Arbeit erzeugt einen stabilen Vorlauf, während Migration die Wellen mit Runbooks, Cutover und Validierung umsetzt.

Migration-Factory-Prozess im Modulfluss

Der Migrationsplan verbindet Discovery- und Design-Ergebnisse mit Umsetzungs-Governance, Wellenplanung und runbook-basierter Delivery. Der Prozess koppelt Portfolio- und Migrations-Workstream eng über Governance, Runbooks und kontinuierliche Verbesserung.

Wellenplanung als dynamische Zeitachse

Wellenplanung ist kein statischer Terminplan. Sie ist eine operative Zeitachse, die für Stakeholder transparent und für neue Erkenntnisse anpassbar bleiben muss. Maßgeblich sind dabei Taktung, Überlappung der Workstreams und eine klare Pufferlogik.

Iterative Planungslogik in der Praxis

1. Aktuelle Discovery- und Design-Ergebnisse sowie Restriktionen und Annahmen bestätigen.
2. Wellenzuschnitt, Reihenfolge und Staffing auf Basis des aktuellen Stands aktualisieren.
3. Aktuelle Welle mit freigegebenen Migrations- und Cutover-Runbooks ausführen.
4. Cutover-Ergebnisse, Störungen und Zeitabweichungen auswerten.
5. Governance-Kontrollen und Runbooks verbessern und in kommende Wellen übernehmen.
6. Health-Status und Wellenpuffer prüfen und in die nächste Iteration gehen.

Ergebnisse dieses Moduls

Der Migrationsplan sollte mindestens folgende Ergebnisse liefern:

• Freigegebener Wellenplan: Sequenzierte Migrationswellen mit abhängigkeitsbewusster Gruppierung.
• Ausführbare Runbooks: Versionierte Runbooks je Welle/Anwendung mit Validierung und Rollback.
• Ressourcen- und Skill-Plan: Besetzungs- und Fähigkeitsplanung je Welle.
• Governance-Taktung: Rahmen für Entscheidungen, Kommunikation und Cutover-Steuerung.
• Backlog für kontinuierliche Verbesserung: Nachverfolgbare Verbesserungen aus jeder Welle.