Cloud-Migration in 10 Phasen: Von der Assessment-Phase bis zum Betrieb

Stand: Oktober 2026

Definition: Was ist Cloud-Migration?

Cloud-Migration bezeichnet den strukturierten Prozess, bei dem Organisationen Anwendungen, Daten und IT-Infrastrukturen aus eigenen Rechenzentren in Cloud-Umgebungen überführen – sei es in Public-, Private- oder Hybrid-Modelle. Anders als eine reine Lift-and-Shift-Verschiebung, die Workloads unverändert in virtuelle Maschinen hebt, umfasst echte Migration die methodische Neuausrichtung von Architektur, Betriebsmodell und Governance.

Etablierte Rahmenwerke großer Hyperscaler gliedern diesen Wandel in klar definierte Phasen. Das AWS-Phasenmodell unterscheidet Assess, Mobilize, Migrate und Operate, während NetApp die Schritte Prepare, Plan, Migrate, Operate und Optimize nennt. Beide Ansätze betonen, dass Assessment und Planung den Erfolg maßgeblich bestimmen – unvollständige Bestandsaufnahmen führen später zu versteckten Abhängigkeiten, Kostenüberschreitungen und Performance-Problemen.

Für Enterprise-Umgebungen hat sich ein granulares 10-Phasen-Modell bewährt, das die Hauptschritte weiter unterteilt: von der Initiierung über Discovery, Strategiewahl nach den 7 Rs bis hin zu kontinuierlichem FinOps und Resilience-Engineering im Betrieb. Migration endet nicht beim Cutover; sie geht in permanente Optimierung über, bei der Kosten, Sicherheit und Nachhaltigkeit fortlaufend justiert werden.

Wie funktioniert Cloud-Migration in 10 Phasen?

1. Initiierung & Zieldefinition: Business Case rechnen, Stakeholder alignen, Scope und KPIs festlegen. Übergabe: unterzeichneter Projektauftrag mit messbaren Zielen.
2. Discovery & Assessment: CMDB bereinigen, Dependency Mapping automatisieren, Cloud-Readiness jeder Applikation bewerten. Übergabe: vollständiges Portfolio mit Abhängigkeitsgraph und Risikoeinstufung. Google Cloud empfiehlt dafür eine mehrwöchige Analysephase bei Rechenzentrums-Migrationen.
3. Migrationsstrategie & 7-Rs-Zuordnung: Je Workload Rehost, Replatform, Refactor, Repurchase, Relocate, Retain oder Retire wählen. Übergabe: Migrationsplan mit R-Strategie pro Asset.
4. Mobilisierung & Landing Zone: Governance-Rahmen, Security-Baseline, CI/CD-Pipelines und Identitätsmodell aufbauen. Übergabe: betriebsbereite Landing Zone nach Provider-Best-Practices.
5. Pilot-Migration & Validierung: Niedrigrisiko-Workload end-to-end migrieren, Runbooks und Rollback-Verfahren testen. Übergabe: validierte Migrations-Runbooks und Lessons Learned.
6. Wave-Migration (Low-Risk): Standard-Applikationen wellenweise überführen, Automatisierung skalieren. Übergabe: migrierte Low-Risk-Systeme im produktiven Betrieb.
7. Wave-Migration (Business-Critical): Kernanwendungen mit minimalem Downtime (Blue/Green, Database Sync) schwenken. Übergabe: alle Business-Critical-Workloads produktiv in der Cloud.
8. Cutover & Go-Live: DNS-Umschaltung, On-Prem-Decommissioning, finale Datenabgleichsprüfung. Übergabe: reiner Cloud-Betrieb ohne Legacy-Abhängigkeiten.
9. Operate & FinOps: Observability, Cost-Visibility, Anomaly Detection und Security-Posture-Management etablieren. Übergabe: stabiles Betriebsmodell mit FinOps-Dashboard. Aktuelle 2026-Trends integrieren FinOps bereits ab Tag 1 statt nachträglich.
10. Optimize & Continuous Improvement: Rightsizing, Resilience-Tests (Chaos Engineering), Sustainability-Metriken und Platform-Engineering-Fähigkeiten ausbauen. Übergabe: kontinuierlicher Optimierungszyklus mit messbarem Business Value.

Beispiele aus der Praxis: Typische Migrationsszenarien

Ein mittelständischer Fertigungsbetrieb verlagert seine SAP-ERP-Landschaft in eine Hybrid-Cloud. Die Assessment-Phase dauert vier bis acht Wochen, um Abhängigkeiten zwischen Modulen, Schnittstellen und Individualentwicklungen zu kartieren. CloudMagazin beschreibt dieses Vorgehen als typisch für Unternehmen, die Kernsysteme nicht per Big Bang verschieben wollen.

Ein regulierter Finanzdienstleister migriert über 200 Workloads mit einem Wave-Ansatz. Pilotwellen validieren Automatisierung und Compliance-Checks, bevor geschäftskritische Systeme folgen. Die AWS-Migrationsstrategie nennt Governance, Security-Hub-Integration und BaFin-konforme Landzonen als Voraussetzung für diese Staffelung.

Eine E-Commerce-Plattform löst ihren Monolithen auf und replatformet auf Kubernetes. KI-gestütztes Dependency Mapping erkennt Laufzeitbeziehungen, die statische Analysen übersehen. Container-Images, Helm-Charts und Service-Mesh-Konfiguration entstehen automatisiert, sodass Entwicklungsteams nach Cutover sofort Self-Service-Deployments nutzen.

Phase 1 – Initiierung & Zieldefinition

Die Initiierung legt das Fundament für die gesamte Migration. Zunächst entsteht der Business Case: Er quantifiziert erwartete Einsparungen, Skalierungsvorteile und Risiken. Ohne belastbare Zahlen blockieren Budgetentscheider das Vorhaben.

Parallel formiert sich das Stakeholder-Alignment. IT, Fachbereiche, Security und Legal sitzen ab Tag 1 am Tisch. Security prüft Schutzbedarfsfeststellungen, Legal klärt Datenhoheit und Auftragsverarbeitung. Fehlt eine Stimme, drohen späte Eskalationen.

Der Scope grenzt Applikationen, Datenbestände und Zielregionen ein. Ein „Alles auf einmal“ scheitert an Abhängigkeiten. Stattdessen priorisieren Teams nach Business Value und technischer Entkopplbarkeit.

KPIs machen Fortschritt messbar: Kosten pro Workload, Latenzziele, Compliance-Quote, Time-to-Market für neue Services. Diese Metriken steuern spätere Go/No-Go-Entscheidungen.

Das AWS-Mobilize-Framework beschreibt diese Phase als Aufbau der Governance-Struktur: RACI-Matrix, Steuerungskreis, Eskalationspfade. Der ParkPlace-Projektplan konkretisiert Woche 1 bis 6 mit Stakeholder-Interviews, Requirements-Engineering und der Etablierung eines Cloud-Center-of-Excellence. Wer hier Kürzungen vornimmt, zahlt in späteren Phasen Zinsen.

Phase 2 – Discovery & Assessment

Eine lückenlose Bestandsaufnahme bildet das Fundament jeder Migration. Automatisierte Tools scannen die CMDB, erfassen Server, Datenbanken und Middleware und legen die Basis für das spätere Dependency Mapping. Hyperscaler-Dienste wie AWS Application Discovery Service oder Azure Migrate erkennen Netzwerkflüsse, Shared Storage und Authentifizierungsketten, die in Dokumentationen oft fehlen. Ergänzend bewertet die Applikations-Portfolio-Analyse jede Workload nach technischer Eignung, organisatorischer Bereitschaft und finanzieller Tragfähigkeit – die drei Dimensionen der Cloud-Readiness.

Der kritischste Erfolgsfaktor bleibt die Vollständigkeit: Unentdeckte Abhängigkeiten verursachen während des Cutover Performance-Einbrüche und Kostenüberschreitungen. Dauer der Phase: bei rein automatisierter Erfassung ein bis zwei Wochen, im mittelständischen Umfeld mit manuellen Interviews und Validierungsschleifen vier bis acht Wochen (CloudMagazin, Konfuzio). LeanIX empfiehlt, das Assessment nicht als Punktaufnahme zu verstehen, sondern als kontinuierlichen Prozess – jede neue Anwendung, jede Änderung im Bestand löst eine Neubewertung aus. So bleibt das Migrationsziel auch bei wachsender Komplexität steuerbar.

Phase 3 – Migrationsstrategie & 7-Rs-Zuordnung

Jeder Workload erhält jetzt eine individuelle Migrationsstrategie. Das etablierte 7-Rs-Framework bietet sieben Optionen: Rehost (Lift-and-Shift) verschiebt VMs unverändert, Replatform (Lift-Tinker-Shift) nimmt gezielte Optimierungen vor, Refactor/Re-architect baut Applikationen cloud-nativ um. Repurchase ersetzt Legacy-Software durch SaaS-Alternativen, Relocate migriert VMware-Cluster auf VMware Cloud without conversion. Retain belässt Systeme on-premises – etwa bei Latenz- oder Compliance-Anforderungen – und Retire schaltet nicht mehr genutzte Workloads ab.

Die Zuordnung folgt harten Kriterien: Business Value, technische Machbarkeit, Risikoprofil und regulatorische Vorgaben. Ein ERP-System mit hoher Anpassungstiefe landet oft bei Refactor, ein statischer Webserver bei Rehost, ein veraltetes CRM bei Repurchase. TierPoint stellt die Matrix als Entscheidungsbaum dar, der Abhängigkeiten und Time-to-Value gegenüberstellt. Küstermann Media ergänzt praxisnahe Bewertungsschemata für Mittelstands-Umgebungen, bei denen oft hybride Pfade (Retain + Replatform) dominieren.

Wichtig: Die Strategieentscheidung ist nicht final. Während der Wave-Planung (Phase 4) können Workloads zwischen Kategorien wandern, sobald Testmigrationen realistische Aufwände liefern. Dokumentation der Begründung pro Workload schafft Nachvollziehbarkeit für Stakeholder und Audit.

Phase 4 – Mobilisierung & Landing Zone

Die AWS-Mobilize-Phase bereitet die Zielumgebung vor, bevor erste Workloads wandern. Kernstück ist die Landing Zone: eine vorgefertigte, gouvernierte Multi-Account-Struktur, die Identität, Netzwerk, Sicherheit und Betrieb trennt.

Im Identity-Bereich legt AWS Control Tower oder ein eigenes Konto-Modell die Organisations-Einheiten (OUs) fest – etwa für Security, Shared Services, Workloads und Sandbox. Service Control Policies (SCPs) setzen Guardrails durch, die beispielsweise öffentliche S3-Buckets oder unverschlüsselte EBS-Volumes verbieten. Das Netzwerk nutzt Transit Gateway für Hub-and-Spoke-Topologien; VPC Peering ergänzt direkte Verbindungen zwischen benachbarten Accounts.

Observability startet am Tag eins: CloudTrail-Logs fließen zentral in ein Audit-Konto, CloudWatch-Metriken und Alarmierungen decken Basis-SLIs ab. CI/CD-Pipelines (CodePipeline, GitHub Actions, GitLab) deployen Infrastruktur als Code – Terraform-Module oder CloudFormation StackSets rollen Standards wiederholbar aus.

Parallel baut die Organisation Kompetenzen auf. SIGS betont, dass Skills, Prozesse und Kultur synchron wachsen müssen: DevOps-Training, angepasstes Change Management und Incident-Response-Playbooks gehören zur Mobilisierung genauso wie die technische Basis. Wer hier spart, zahlt später in Schatten-IT und Compliance-Lücken.

Phase 5 – Pilot-Migration & Validierung

In Phase 5 führt das Team einen End-to-End-Test der Migrationsfabrik durch. Dazu wählt es eine repräsentative, risikoarme Workload – etwa eine Dev/Test-Umgebung oder eine interne Web-Applikation – und migriert diese vollständig in die Zielumgebung. Der Pilot prüft nicht nur die technischen Werkzeuge, sondern auch die operativen Runbooks, die Rollback-Pläne und die Kommunikation zwischen den beteiligten Teams.

Die Validierung erfolgt entlang harter Kriterien: Funktionalität der Applikation, Performance-Baselines im Vergleich zum On-Premise-Betrieb, Security-Posture (Netzwerksegmentierung, IAM, Verschlüsselung) und Cost-Transparenz durch Tagging und Monitoring. Erst wenn alle Schwellenwerte eingehalten sind, gibt das Migrationsbüro die nächste Welle frei. Northflank weist darauf hin, dass Piloten oft versteckte Abhängigkeiten oder Lizenzfragen offenlegen, die im reinen Assessment unsichtbar blieben.

Alle Erkenntnisse – von fehlerhaften Skripten bis zu Prozesslücken – fließen unmittelbar in eine aktualisierte Automatisierung ein. Runbooks werden geschärft, IaC-Templates korrigiert, Testfälle erweitert. Google Cloud beschreibt den Piloten als Vertrauensanker für Stakeholder: Ein erfolgreicher Cutover schafft die nötige Akzeptanz, um spätere, geschäftskritische Wellen mit reduziertem Widerstand zu fahren. Gleichzeitig etabliert das Team die Governance-Strukturen für Change-Management und Incident-Response, die im produktiven Betrieb tragen müssen.

Phase 6 – Wave-Migration: Low-Risk Workloads

Die ersten Migrationswellen adressieren Workloads mit geringer Business-Kritikalität. Dazu zählen Batch-Verarbeitung, Entwicklungsumgebungen, File-Server sowie Legacy-Anwendungen ohne harte SLAs. Ein Migration Factory standardisiert den Ablauf durch Infrastructure-as-Code und Automatisierung, sodass mehrere Wellen parallel laufen. Ziel ist maximaler Durchsatz bei validierter Migrationsgeschwindigkeit.

Die Wellenplanung orientiert sich an Abhängigkeiten und Risiko-Clustern. AWS empfiehlt, Dependencies früh zu kartieren und Workloads in logische Gruppen zu clustern. So lassen sich Schnittstellen isolieren und Rollback-Szenarien pro Wave definieren. Automatisierte Tests nach jedem Cutover sichern die Qualität, bevor die nächste Welle startet.

Teams sammeln in dieser Phase operative Erfahrung: Monitoring, Incident-Response und Cost-Transparenz werden unter Realbedingungen erprobt. Erkenntnisse fließen direkt in die Planung der nachfolgenden Business-critical Waves ein. Die Factory skaliert dabei horizontal – neue Automatisierungsmodule werden ergänzt, manuelle Schritte eliminiert. So steigt die Geschwindigkeit von Welle zu Welle, ohne das Risiko zu erhöhen.

Phase 7 – Wave-Migration: Business-Critical Workloads

In der siebten Welle rücken hochverfügbare Kernanwendungen in den Fokus – ERP-Systeme, CRM-Plattformen und geschäftskritische Datenbanken. Diese Workloads tolerieren kaum Ausfallzeiten und erfordern präzise Planung. Typische Strategien sind Replatforming auf Managed Services, Refactoring in Container-Umgebungen sowie Blue/Green-Deployments für kontrollierte Cutover. Für Datenbanken nutzen Teams Database Migration Services mit Change Data Capture, um Near-Zero-Downtime zu erreichen. Ein Readiness-Check nach zehn Kriterien deckt Lücken in Lizenzierung, Customizing, Schnittstellen und Performance vor dem Umzug auf.

Die Validierung verschärft sich gegenüber früheren Wellen massiv. Automatisierte Performance-Tests unter Last simulieren produktive Spitzen. Chaos-Engineering-Experimente prüfen Failover-Verhalten und Datenkonsistenz bei Infrastrukturausfällen. Compliance-Prüfungen nach BSI-Grundschutz oder BaFin-Vorgaben werden in die Pipeline integriert – Policy-as-Code stellt sicher, dass regulatorische Anforderungen bei jedem Deployment greifen. Ein detaillierter Leitfaden beschreibt Testverfahren und Dokumentationspflichten für regulierte Branchen.

Rollback-Pläne müssen vor Wave-Start freigegeben sein. Schnittstellen zu Altsystemen bleiben über API-Gateways oder Service-Meshes konsistent. Monitoring-Dashboards zeigen Business-KPIs in Echtzeit, nicht nur Infrastruktur-Metriken. Erst wenn alle Gates – Performance, Sicherheit, Compliance, Business-Akzeptanz – grün signalisieren, erfolgt der finale DNS-Switch. Die Welle schließt mit einem Go/No-Go-Review ab, das Lessons Learned in die nachfolgenden Wellen einspeist.

Phase 8 – Cutover & Go-Live

Der finale Umschnitt erfordert präzise Choreografie. Das Laufbuch regelt Minute für Minute: DNS-Umschaltung, Stopp der Datenbank-Replikation, Start der Applikationen in der Cloud. Rollback-Trigger sind vorab definiert – etwa bei fehlgeschlagenen Smoke-Tests oder Latenzüberschreitungen. Eine Kommunikationsmatrix weist jedem Stakeholder seinen Kanal und Eskalationspfad zu.

Validierung läuft mehrstufig. Automatisierte Smoke-Tests prüfen Kern-APIs und Datenbankverbindungen. Synthetic Monitoring simuliert Nutzerpfade über mehrere Regionen. Business-Transaktionsprüfungen bestätigen, dass Bestellprozesse, Abrechnung und Reporting fehlerfrei durchlaufen. Erst nach grünem Signal aller Tests erteilt das Stakeholder-Gremium das formale Sign-off.

Trend Micro empfiehlt, das Cutover-Wochenende mit großzügigem Zeitpuffer zu planen und Sicherheitsrichtlinien vorab in der Zielumgebung zu validieren. ParkPlace Technologies betont, dass ein detaillierter Projektplan mit klaren Meilensteinen und Verantwortlichkeiten das Risiko ungeplanter Ausfallzeiten minimiert. Beide Anbieter raten, Rollback-Szenarien unter Realbedingungen zu proben, bevor der produktive Verkehr umgeschaltet wird.

Phase 9 – Operate & FinOps

Der Betrieb beginnt nicht nach der Migration, sondern mit dem ersten Cutover. FinOps zieht dabei in die Planungsphase vor – Shift-Left Cost Visibility macht Kosten bereits im IaC-Code sichtbar, Anomaly Detection warnt vor Abweichungen in Echtzeit, Rightsizing passt Instanztypen kontinuierlich an tatsächliche Last an. Security Posture Management (CSPM) prüft Konfigurationen permanent gegen Benchmarks wie CIS und korrigiert Drifts automatisiert. Observability vereint Logs, Metriken und Traces in einer Plattform, sodass SRE-Teams Latenzspitzen oder Fehlerquoten ohne Toolwechsel korrelieren.

Incident Response nutzt cloud-native Runbooks: EventBridge, Lambda und Systems Manager orchestrieren Containment, Forensik und Recovery ohne manuelle Konsolenarbeit. Change Management läuft über GitOps – jede Infrastrukturänderung durchläuft Pull-Request, Policy-Check und Canary-Deployment. Compliance-as-Code prüft DSGVO-, BSI- und branchenspezifische Regeln direkt in der Pipeline; Non-Compliance blockiert den Merge. NetApp und Computech betonen, dass Operate und Optimize keine Endphasen sind, sondern sich überlappende Kreisläufe: Kosten, Sicherheit, Performance und Compliance werden fortlaufend gemessen, bewertet und justiert – Tag für Tag.

Phase 10 – Optimize & Continuous Improvement

Die zehnte Phase versteht sich nicht als Abschluss, sondern als permanenter Optimierungszyklus. FinOps wandert dabei vollständig in den operativen Alltag: Rightsizing von Compute- und Storage-Ressourcen, der gezielte Einsatz von Reserved Instances und Savings Plans sowie der Abbau von Zombie-Assets senken die laufenden Kosten messbar. Parallel treibt Architecture Modernization die Ablösung von Lift-and-Shift-Workloads durch Serverless-Bausteine und Managed Services voran – weniger Betriebsaufwand, höhere Skalierbarkeit.

Green Cloud etabliert sich als neuer KPI-Horizont. Die großen Hyperscaler liefern über ihre Sustainability-Dashboards CO₂-Fußabdrücke pro Workload; diese Metriken fließen in Kapazitätsentscheidungen und Reporting ein. Resilience Engineering ergänzt den Betrieb durch Game Days und automatisierte Failure Injection, um Ausfallszenarien unter Realbedingungen zu validieren – statt reaktiver Incident-Response wird proaktive Härtung zur Routine.

Ein strategischer Nachnutzen der Migration ist der Aufbau Internal Developer Platforms (IDP) mit Golden Paths. Standardisierte Self-Service-Pfade für Deployment, Observability und Compliance beschleunigen Feature-Delivery und entlasten Plattform-Teams. Laut ADEVS-Ausblick 2026 werden KI-gestützte Optimierungsempfehlungen und Sustainability-KPIs künftig fester Bestandteil dieses Zyklus. Organisatorisch gelingt der Übergang nur, wenn Skills, Prozesse und Kultur parallel zur Technik mitwachsen – ein Punkt, den der SIGS-Beitrag zur Mobilisierungsphase als Erfolgsfaktor hervorhebt.