Zum Inhalt

Einen Workload auf die Plattform migrieren

Diese Seite beschreibt einen phasenweisen Weg, einen Workload aus einer älteren Umgebung (On-Premises, einer älteren landing zone oder einer anderen Cloud) in einen Spoke auf der Plattform zu verlagern. Die Hauptverantwortung für die Migration bleibt beim Workload-Team. Das Plattform-Team hilft beim Spoke, beim Netzwerk und bei den Standardänderungen und berät beim Design. Es migriert deine Anwendung nicht für dich, es sei denn, ihr habt das separat vereinbart.

Die Phasen sind ein Leitfaden. Deine Organisation kann Schritte ergänzen, zum Beispiel Genehmigungen, Change-Fenster oder ein Migrationsboard. Frag dein Plattform-Team, welche gelten. Wer das Plattform-Team ist, steht unter Betriebsmodelle.

flowchart LR
    subgraph team["Once per team"]
        A["1. Onboarding"] --> B["2. Workload identification"]
    end
    subgraph wl["Once per workload"]
        C["3. Design"] --> D["4. Spoke deployment"] --> E["5. Workload deployment"]
        E --> F["6. Data and cut-over"] --> G["7. Decommission legacy"] --> H["8. Evaluate"]
    end
    B --> C

Beginne mit einem kleinen Workload mit geringem Risiko, um den Prozess kennenzulernen (crawl). Nimm dir den nächsten mit dem Gelernten vor (walk). Plane die großen oder kritischen Workloads zuletzt (run).

Die Phasen

# Phase Was das Team tut Was das Plattform-Team tun kann
1 Onboarding An der Einführung teilnehmen, die Verantwortlichkeiten und Einschränkungen lesen und die Rollen in deinem Team benennen. Die Plattform und ihren Support vorstellen. Siehe Onboarding.
2 Workload-Identifikation Deine Workloads, ihre Abhängigkeiten und Owner auflisten. Pro Workload eine Business-Impact-Analyse (BIA) durchführen und die Klassifizierung festlegen. Bei Zuordnung und Ownership beraten.
3 Design Die aktuelle Architektur mit den Regeln der Plattform vergleichen. Die Änderungen dokumentieren, die du vornehmen musst (private endpoints, Identität, Tagging, Policies). Die Migrationsstrategie und den Cut-over planen. Das Design prüfen. Dir helfen, den IP-Bereich und die benötigten Firewallregeln zu planen.
4 Spoke-Deployment Den Spoke anfragen. Konnektivität und Zugriff auf den Spoke prüfen. Den Spoke erstellen.
5 Workload-Deployment Den Workload mit deinen pipelines und deinem Code in den Spoke deployen. Die Firewallregeln und, für Web-Apps, den Application-Gateway-Eintrag anfragen. Zuerst in dev und tst testen. Die Standardänderungen durchführen.
6 Daten und Cut-over Die Daten migrieren. Ihre Integrität prüfen. Benutzer validieren lassen. Den Verkehr umschalten (zum Beispiel den DNS-Eintrag), wenn du bereit bist. Einen Rollback-Pfad behalten, bis du das Ergebnis verifiziert hast. Bei Cut-over-Plan und Risiken beraten.
7 Altumgebung außer Betrieb nehmen Prüfen, dass nichts mehr von der alten Umgebung abhängt. Zugriffe entziehen und die alten Ressourcen sicher löschen. Siehe die Checkliste unten.
8 Auswerten Den Verlauf reflektieren, Lessons Learned festhalten und deine eigenen Verfahren anpassen. Feedback zur Plattform geben. Das Feedback sammeln.

Kümmere dich früh um das Netzwerk

Die meisten Verzögerungen entstehen durch Netzwerkzugriffe, die zu spät angefragt wurden: Adressbereiche, Firewallregeln zu anderen Systemen und On-Premises-Konnektivität. Sammle in Phase 2 alle Verbindungen des Workloads und frage die Regeln vor dem Cut-over an, pro Umgebung. Regeln zwischen alter und neuer Umgebung können für die Dauer der Migration nötig sein.

Checkliste für Phase 7: die alte Umgebung abschalten

  • Alle Abhängigkeiten anderer Systeme von der alten Umgebung sind verlagert oder entfernt.
  • Die Daten sind migriert, und Backups oder ein Archiv bestehen so lange, wie deine Aufbewahrungsregeln es verlangen.
  • DNS-Einträge, Zertifikate, Firewallregeln und Monitoring, die auf die alte Umgebung zeigen, sind entfernt oder verlagert.
  • Der Zugriff von Personen und Service Accounts auf die alte Umgebung ist entzogen.
  • Die alten Ressourcen sind gelöscht, und die alte subscription ist gekündigt, wenn sie leer ist. Ist die alte Umgebung selbst ein Spoke auf dieser Plattform, folge Spoke löschen.
  • Das Kosten-Reporting zeigt die alten Kosten nicht mehr. Halte die Einsparungen fest, wenn deine Organisation sie nachverfolgt.