Gantt-Diagramm Cloud-Migration mit Wellen und Cutover
Editierbares Gantt-Diagramm für die Cloud-Migration: Inventur, Abhängigkeiten, parallel gebaute Landing Zone, Migrationswellen, Cutover-Probe, Hypercare und Stilllegung mit Abhängigkeiten und Meilensteinen.
Was ist Gantt-Diagramm Cloud-Migration mit wellen und cutover?
Eine Cloud-Migration besteht aus mehreren Projekten mit einer gemeinsamen Frist. Inventur und Planung entscheiden, was umzieht und in welcher Reihenfolge. Die Landing Zone, also Netzwerk, Identität und Logging, in denen die Workloads landen, kann gleichzeitig gebaut werden. Die Wellen verschieben dann Workloads in Gruppen, und die Quellumgebung lässt sich erst abschalten, wenn die letzte Welle eine Weile produktiv gelaufen ist. Ein Plan, der all das als eine Folge aufführt, übertreibt die Dauer. Ein Plan, der es als unabhängig behandelt, verbirgt die Stellen, an denen eines auf das andere wartet.
Diese Vorlage hat vier Phasen: Erfassen und planen, Landing Zone aufbauen, In Wellen migrieren sowie Cutover und Stilllegung. „Anwendungs- und Serverinventur“ ist die einzige Startaufgabe. „Abhängigkeiten abbilden“ beginnt drei Arbeitstage nach dem Start der Inventur, weil die ersten Ergebnisse genügen, um Verbindungen nachzuverfolgen, und „Migrationsstrategie je Workload“ folgt darauf. Von dort teilt sich der Plan. „Wellenplan und Cutover-Fenster“ führt zum Meilenstein „Migrationsplan freigegeben“, während „Landing-Zone-Design“ beginnt, sobald die Strategie bekannt ist, und parallel zum Wellenplan läuft.
In der Landing Zone folgen „Netzwerk und Konnektivität aufbauen“ (10 Arbeitstage) und „Identität, Sicherheit und Logging einrichten“ (8) beide auf das Design, und die zweite beginnt zwei Arbeitstage nach dem Start des Designs. „Landing Zone bereit“ wartet auf beide. „Welle 1: Pilotmigration“ kann erst beginnen, wenn sowohl „Migrationsplan freigegeben“ als auch „Landing Zone bereit“ erledigt sind; hier rutschen Pläne dieser Art am häufigsten: Der Papierkram ist fertig, das Ziel nicht, oder umgekehrt. „Pilot-Erkenntnisse in Runbooks einarbeiten“ liegt zwischen dem Pilot und „Welle 2: Kern-Workloads“, und „Welle 3: übrige Workloads“ beginnt fünf Arbeitstage nach dem Start von Welle 2, sodass die letzte Welle die Kernwelle überlappt.
Nach den Wellen müssen „Performance- und Failover-Tests“ und Welle 3 beide abgeschlossen sein, bevor die „Letzte Cutover-Probe“ stattfindet, danach folgen das „Cutover-Fenster“, „Hypercare“ (10 Arbeitstage) und „Quellserver außer Betrieb nehmen“. „Quellumgebung stillgelegt“ ist der abschließende Meilenstein. Alle Dauern sind Beispielwerte. Ein reales Systemumfeld hat Workloads, die nicht zusammen umziehen können, Lizenzen mit eigenen Enddaten und Änderungssperren, die dieses Diagramm nicht kennt; ersetzen Sie also Dauern und Wellenaufteilung durch Ihre eigenen. Ein Zeitplan plant die Arbeit. Er macht eine Migration nicht sicher, geschützt oder wirtschaftlich und ersetzt nicht die Runbooks, Testergebnisse und Freigaben, die Ihr Änderungsprozess verlangt. Zur Prozessseite siehe den Deployment-Prozess unter /de/templates/software-deployment-prozess, den Wiederherstellungsprozess unter /de/templates/disaster-recovery-prozess-it und den Änderungsprozess unter /de/templates/it-change-management-prozess.
Was dieses Flussdiagramm abdeckt
In dieser Vorlage
- Vier Phasen, Erfassen und planen, Landing Zone aufbauen, In Wellen migrieren sowie Cutover und Stilllegung, mit 19 Aufgaben und drei Meilensteinen: „Migrationsplan freigegeben“, „Landing Zone bereit“ und „Quellumgebung stillgelegt“.
- Eine Start-Start-Überlappung in der Inventur: „Abhängigkeiten abbilden“ beginnt drei Arbeitstage nach dem Start von „Anwendungs- und Serverinventur“, noch vor deren Ende.
- Eine Landing Zone neben der Planung: „Landing-Zone-Design“ folgt auf „Migrationsstrategie je Workload“ und läuft parallel zu „Wellenplan und Cutover-Fenster“, wobei „Identität, Sicherheit und Logging einrichten“ zwei Arbeitstage nach dem Designstart beginnt.
- Ein Zusammenlauf, der die erste Welle sperrt: „Welle 1: Pilotmigration“ wartet auf „Migrationsplan freigegeben“ und „Landing Zone bereit“, danach kommt „Pilot-Erkenntnisse in Runbooks einarbeiten“ vor „Welle 2: Kern-Workloads“.
- Überlappende Wellen und ein sicherer Abschluss: „Welle 3: übrige Workloads“ beginnt fünf Arbeitstage nach dem Start von Welle 2, und „Quellserver außer Betrieb nehmen“ wartet auf die 10-tägige „Hypercare“.
Wann Sie diese Vorlage verwenden sollten
- Sie verlagern Server oder Anwendungen zu einem Cloud-Anbieter und müssen zeigen, wann Planung, Landing Zone, jede Welle und der Cutover liegen.
- Sie müssen einem Lenkungskreis oder den Anwendungsverantwortlichen erklären, warum Welle 1 erst beginnen kann, wenn die Landing Zone bereit ist, was der Plan auch sagt.
- Man fragt Sie, wie lange die Quellumgebung eingeschaltet bleiben muss, etwa wegen eines Vertragsendes für Rechenzentrum oder Hosting.
- Sie möchten testen, was mit dem Stilllegungstermin passiert, wenn der Netzwerkaufbau oder eine Welle länger dauert als geplant.
Der Plan, Aufgabe für Aufgabe
Alle Aufgaben des Diagramms mit ihrer Dauer in Arbeitstagen und dem, worauf sie warten. Eine Abhängigkeit ist eine Schrittnummer; SS bedeutet Start-zu-Start, FF Ende-zu-Ende, +n eine Verzögerung in Arbeitstagen.
| # | Aufgabe | Gruppe | Arbeitstage | Abhängig von |
|---|---|---|---|---|
| 1 | Anwendungs- und Serverinventur | Erfassen und planen | 8 | |
| 2 | Abhängigkeiten abbilden | Erfassen und planen | 6 | 1SS+3 |
| 3 | Migrationsstrategie je Workload | Erfassen und planen | 4 | 2 |
| 4 | Wellenplan und Cutover-Fenster | Erfassen und planen | 4 | 3 |
| 5 | Migrationsplan freigegeben | Erfassen und planen | Meilenstein | 4 |
| 6 | Landing-Zone-Design | Landing Zone aufbauen | 6 | 3 |
| 7 | Netzwerk und Konnektivität aufbauen | Landing Zone aufbauen | 10 | 6 |
| 8 | Identität, Sicherheit und Logging einrichten | Landing Zone aufbauen | 8 | 6SS+2 |
| 9 | Landing Zone bereit | Landing Zone aufbauen | Meilenstein | 7, 8 |
| 10 | Welle 1: Pilotmigration | In Wellen migrieren | 8 | 5, 9 |
| 11 | Pilot-Erkenntnisse in Runbooks einarbeiten | In Wellen migrieren | 3 | 10 |
| 12 | Welle 2: Kern-Workloads | In Wellen migrieren | 15 | 11 |
| 13 | Welle 3: übrige Workloads | In Wellen migrieren | 12 | 12SS+5 |
| 14 | Performance- und Failover-Tests | In Wellen migrieren | 6 | 12 |
| 15 | Letzte Cutover-Probe | Cutover und Stilllegung | 2 | 13, 14 |
| 16 | Cutover-Fenster | Cutover und Stilllegung | 2 | 15 |
| 17 | Hypercare | Cutover und Stilllegung | 10 | 16 |
| 18 | Quellserver außer Betrieb nehmen | Cutover und Stilllegung | 8 | 17 |
| 19 | Quellumgebung stillgelegt | Cutover und Stilllegung | Meilenstein | 18 |
So funktioniert es
Die Dauern für Inventur und Planung ersetzen
Setzen Sie die Dauern von „Anwendungs- und Serverinventur“, „Abhängigkeiten abbilden“ und „Migrationsstrategie je Workload“ nach der Größe Ihres Bestands. Behalten Sie die Start-Start-Verknüpfung, wenn das Nachverfolgen vor dem Ende der Inventur beginnen kann.
Die Landing Zone neben dem Plan aufbauen
Lassen Sie „Landing-Zone-Design“ und „Wellenplan und Cutover-Fenster“ als parallele Aufgaben stehen. Fügen Sie Aufgaben für alles andere hinzu, was das Ziel braucht, etwa gemeinsame Dienste, und verknüpfen Sie sie mit „Landing Zone bereit“.
Welle 1 von beiden Seiten abhängig machen
„Welle 1: Pilotmigration“ hängt von „Migrationsplan freigegeben“ und „Landing Zone bereit“ ab. Verlängern Sie den Netzwerkaufbau und sehen Sie, welche Seite den Pilotstart bestimmt.
Die Wellen an Ihre Workloads anpassen
Benennen Sie die Wellenaufgaben um oder duplizieren Sie sie für Ihre eigenen Workload-Gruppen. Nutzen Sie einen Versatz an der Start-Start-Verknüpfung, wo eine spätere Welle beginnen kann, während eine frühere noch läuft.
Cutover, Hypercare und Stilllegung ergänzen
Setzen Sie „Hypercare“ auf die Zeit, die Sie die Quelle als Rückfallebene behalten wollen. Prüfen Sie das Datum von „Quellumgebung stillgelegt“ gegen jedes Vertrags- oder Lizenzende, das Sie einhalten müssen.
Verantwortliche eintragen, teilen und exportieren
Tragen Sie das verantwortliche Team unter Personen ein, Vermerke wie Runbook-Verweise in die Aufgabennotizen, teilen Sie das Diagramm mit den Anwendungsverantwortlichen und exportieren Sie ein PDF für die Änderungsakte.
Häufig gestellte Fragen
Wählt dieses Diagramm eine Migrationsstrategie für mich?
Nein. Es plant die Arbeit. In der Aufgabe „Migrationsstrategie je Workload“ entscheiden Sie für jeden Workload, ob er unverändert umzieht, angepasst oder ersetzt wird. Das Diagramm zeigt nur, was auf diese Entscheidung wartet.
Kann ich um das Vertragsende eines Rechenzentrums herum planen?
Vergleichen Sie das Enddatum von „Quellumgebung stillgelegt“ mit dem Datum, das Sie brauchen. Ist es später, ändern Sie eine Dauer oder Abhängigkeit und beobachten Sie, wie sich das Datum verschiebt. Ein fester Start ist für wirklich feste Termine gedacht, etwa eine Änderungssperre, und das Diagramm markiert einen, der mit einer Abhängigkeit kollidiert.
Sind die Arbeitstage echte Kalendertage?
Sie laufen von Montag bis Freitag. Das Diagramm hat keinen Feiertagskalender; fügen Sie daher eine Aufgabe hinzu oder verlängern Sie eine Dauer, wo ein Feiertag oder eine Sperrzeit liegt.
Wie unterscheidet sich das vom Datenmigrations-Diagramm?
Dieses verschiebt Workloads und Umgebungen. Das Datenmigrations-Diagramm unter /de/templates/gantt-diagramm-datenmigration deckt Profiling, Mapping, Testladungen und den Abgleich der Daten selbst ab. Ein großes Programm kann beide nutzen.
Wo finde ich das Flussdiagramm zur selben Arbeit?
Der Deployment-Prozess unter /de/templates/software-deployment-prozess und der Wiederherstellungsprozess unter /de/templates/disaster-recovery-prozess-it zeichnen die Entscheidungen und Übergaben. Für einen breiteren Programmplan siehe /de/templates/gantt-diagramm-implementierungsplan.
