Cloud-Migration in 8 Schritten: Von der Bestandsaufnahme bis zum Go-Live

Stand: Oktober 2026

TLDR: Kurzdefinition

Eine Cloud-Migration überführt IT-Ressourcen, Anwendungen und Daten aus lokalen Rechenzentren oder legacy Hosting-Umgebungen in eine Cloud-Infrastruktur. Der geplante Übergang berücksichtigt technische Abhängigkeiten, organisatorische Prozesse und Kostenstrukturen, um Betriebskosten zu senken, Skalierbarkeit zu erhöhen und Innovationszyklen zu beschleunigen. Ein strukturiertes Vorgehen gliedert sich in Assessment, Planung, Durchführung und kontinuierliche Optimierung.

Hyperscaler wie Google Cloud definieren dafür ein fünfphasiges Rahmenmodell: Prepare, Plan, Migrate, Operate und Optimize. Bereits in der Planungsphase müssen Governance, Landing Zones und FinOps verankert werden — nicht nachträglich. Pilotmigrationen und User-Acceptance-Tests reduzieren Risiken vor dem produktiven Cutover erheblich. Google Cloud beschreibt diesenLifecycle als iterativen Prozess, bei dem Post-Migration nicht das Projektende markiert, sondern den Übergang in dauerhaftes Monitoring, Rightsizing und Security-Hardening einleitet. Aktuelle Erhebungen zeigen: Bereits ≥ 50 % der Anwendungs-Workloads bei KMUs laufen in der Public Cloud, weitere Migrationen sind für die kommenden 12 Monate geplant.

Definition von Cloud-Migration

Cloud-Migration bezeichnet den strukturierten Transfer von Workloads, Daten und Anwendungen aus on-Premise‑ oder Legacy-Umgebungen in öffentliche, private oder hybride Cloud-Infrastrukturen. Der Prozess geht weit über das reine Verschieben virtueller Maschinen hinaus. Er erfordert die Anpassung bestehender Architekturen, die Einbindung cloud-nativer Dienste sowie die Etablierung von Sicherheits‑ und Governance-Rahmenwerken, die Compliance und Betriebssicherheit über den gesamten Lebenszyklus gewährleisten.

Als Entscheidungsrahmen für einzelne Workloads hat sich das 6R/7R-Modell durchgesetzt: Rehost (Lift-and-Shift), Replatform (geringe Anpassungen), Refactor (Neu-Architektur), Repurchase (SaaS-Alternative), Relocate (VM-Migration ohne Änderung), Retain (Verbleib on-Premise) und Retire (Stilllegung). Ergänzend nutzen Hyperscaler und Beratungen das Phasenmodell Prepare → Plan → Migrate → Operate → Optimize, das strategische Planung, technische Umsetzung und kontinuierliche Verbesserung trennt. AWS fasst diese Phasen in seinem Leitfaden zur Cloud-Migration zusammen und betont, dass Governance-Strukturen, Landing Zones und FinOps bereits in der Plan-Phase verankert werden müssen.

Ein systematischer Einstieg gelingt über eine vollständige Bestandsaufnahme: Infrastruktur, Applikationen, Abhängigkeiten und Datenflüsse werden erfasst, bevor Migrationsziele und ‑strategien festgelegt werden. Computech beschreibt in seiner Übersicht zu Strategien und Schritten, wie Assessment-Ergebnisse direkt in die Wahl der passenden R-Strategie einfließen. Damit wird Cloud-Migration zum steuerbaren Transformationsprojekt statt zu einer reinen Infrastruktur-Verlagerung. Mehrere Anbieter veröffentlichen 2026 explizit 8-Schritt-Checklisten als neuen Standard, die Governance, FinOps und Rollback explizit ausweisen.

Wie funktioniert Cloud-Migration?

Die Migration in die Cloud folgt einem bewährten Phasenmodell, das sich bei Hyperscalern und Beratungen durchgesetzt hat: Prepare, Plan, Migrate, Operate, Optimize. Dieser Rahmen stellt sicher, dass technische Abhängigkeiten früh erkannt, Rollback-Optionen vorbereitet und Governance-Regeln vor dem ersten Workload-Shift greifen.

In der Prepare-Phase steht die Bestandsaufnahme im Mittelpunkt. Teams erfassen Infrastruktur, Anwendungen, Datenströme und Abhängigkeiten – oft automatisiert durch Discovery-Tools. Ohne dieses Inventar lassen sich weder Migrationsstrategien noch Cutover-Pläne fundiert ableiten. NetApp beschreibt diesen Schritt als Grundlage für jede nachfolgende Entscheidung in seinem Leitfaden zu Strategie, Herausforderungen und Schritten. Alle untersuchten Methoden beginnen universell mit diesem Assessment-Schritt.

Die Plan-Phase übersetzt das Inventar in konkrete Architekturentscheidungen. Hier wählen Verantwortliche pro Workload zwischen Rehost (Lift-and-Shift), Replatform (leichte Anpassungen) oder Refactor (Neuarchitektur). Parallel entstehen Landing Zones mit Identitätsmanagement, Netzwerksegmentierung und Security-Baselines. Akamai betont, dass Governance und FinOps bereits hier verankert werden müssen, nicht nachträglich in seiner Strategie-Übersicht. Cloud-Adoption-Frameworks (Microsoft CAF, AWS CAF) definieren Identitäten, Netzwerk, Security-Baselines und Kostenkontrolle vor der ersten Migration.

Während Migrate die eigentliche Überführung pilotiert, starten Teams mit niedrig kritischen Workloads, validieren über User-Acceptance-Tests und proben Rollback-Szenarien. Bei größeren Vorhaben dauert diese Testphase oft mindestens einen Monat. Erst nach erfolgreichem Cutover geht es in Operate: Monitoring, Incident-Response und Skill-Building stabilisieren den Betrieb. Die abschließende Optimize-Phase dreht sich um Rightsizing, Kostenkontrolle und kontinuierliche Verbesserung – ein permanenter Zyklus, kein Projektende.

Pilotmigration & Testwellen

Bevor kritische Systeme produktiv gehen, validiert eine Pilotmigration die gewählte Strategie an repräsentativen Workloads. Teams migrieren zunächst weniger geschäftskritische Anwendungen in die Zielumgebung. Dieser Schritt deckt versteckte Abhängigkeiten auf, die im Assessment übersehen wurden.

Im Rahmen der Testwellen führen Fachbereiche User-Acceptance-Tests (UAT) durch. Sie prüfen, ob Funktionen, Performance und Bedienbarkeit den Anforderungen genügen. Parallel erstellen Betriebsteams Performance-Benchmarks unter realistischer Last. Ein weiterer Fokus liegt auf Rollback-Szenarien: Wie schnell lässt sich der Ausgangszustand wiederherstellen, falls die Migration scheitert oder Dateninkonsistenzen auftreten?

Automatisierte Testskripte protokollieren jeden Migrationsschritt und vergleichen Soll‑ mit Ist-Werten. So lassen sich Abweichungen früh erkennen, bevor sie in die Produktion durchschlagen. Die Dokumentation der Testergebnisse bildet gleichzeitig die Entscheidungsgrundlage für den Go-Live-Freigabeprozess.

Für größere Kunden dauert diese Testphase mindestens einen Monat. In diesem Zeitraum sichern Projektverantwortliche Datenkonsistenz über alle Schnittstellen hinweg, testen Anwendungsverträglichkeit bei parallelem Betrieb und schulen das Betriebspersonal an den neuen Prozessen. Erst nach erfolgreichem Abschluss aller Testwellen startet die schrittweise Roll-out-Phase, bei der weitere Anwendungen in definierten Wellen folgen. Pilotmigrationen und Testwellen sind Pflicht vor Go-Live und reduzieren Risiken signifikant.

Ein strukturierter Leitfaden von Groenewold IT Solutions empfiehlt, die Pilotmigration als Generalprobe zu verstehen. Wer hier Kürzungen vornimmt, riskiert Ausfälle im Produktivbetrieb und aufwändige Nachbearbeitung. Die Investition in gründliche Tests zahlt sich durch planbare Go-Live-Termine und stabile Übergänge aus.

Datenmigration & Cutover

Der Datentransfer bildet regelmäßig den Flaschenhals einer Cloud-Migration. Latenz, begrenzte Bandbreite und die Notwendigkeit konsistenter Datenstände während des finalen Wechsels beeinflussen den Geschäftsbetrieb massiv. Deshalb etablieren Teams Staging-Umgebungen, in denen Daten zunächst synchronisiert und validiert werden, bevor der produktive Cutover erfolgt.

Techniken wie Datenbank-Replikation, Log-Shipping oder spezialisierte Migrations-Dienste ermöglichen einen kontrollierten Übergang mit minimaler Downtime. Der AWS Database Migration Service repliziert Änderungen kontinuierlich in die Zielumgebung, während Azure Data Box bei großen Volumen den physischen Versand verschlüsselter Datenträger übernimmt. Beide Ansätze verkürzen das finale Cutover-Fenster auf Stunden statt Tage. Datenmigration ist der performance-kritischste Teil und erfordert eigenen Migrationsplan mit Staging-Bereichen.

Der Migrationsplan muss Zugriffsrechte, Verschlüsselungsstandards und Backup-Strategien bereits vor dem ersten Sync festlegen. Rollback-Szenarien gehören ebenso dazu wie Validierungsskripte, die Referenzzahlen in Quelle und Ziel vergleichen. Erst nach erfolgreichem Testlauf in der Staging-Zone erfolgt der DNS-Umschlag für die produktiven Systeme.

Eine saubere Trennung zwischen Migrations- und Betriebsphase verhindert, dass Altlasten in die Cloud mitgenommen werden. Automatisierte Prüfungen ersetzen manuelle Stichproben und schaffen Nachweise für Auditoren.

Governance, Landing Zones & FinOps

Bevor die erste Workload migriert wird, müssen Governance-Strukturen stehen. Identitäts- und Zugriffsmanagement, Netzwerk-Segmentierung, Security-Baselines und Compliance-Checks bilden das Fundament. Diese Vorgaben münden in sogenannte Landing Zones – vordefinierte, sichere Cloud-Umgebungen, die konsistent für alle weiteren Migrationen dienen. Ein Cloud-Adoption-Framework liefert hierfür Blaupausen, die Identitäten, Netzwerk-Topologien und Sicherheitsrichtlinien vorgeben.

Parallel etabliert ein FinOps-Framework Kosten-Transparenz. Budget-Alerts, Tagging-Policies und automatisiertes Rightsizing verhindern Überraschungen bei der Monatsrechnung. Wer diese Disziplinen erst nachträglich nachzieht, zahlt mit Nachbesserungen und unkontrollierten Ausgaben. Ein strukturierter Migrationsplan bindet Governance, Landing Zones und FinOps daher bereits in der Planungsphase ein. Governance, Landing Zones und FinOps gehören in die Planungsphase, nicht nachträglich.

Landing Zones standardisieren Tenant-Strukturen, Subscription-Modelle und Baseline-Policies. Teams erhalten vorab genehmigte Umgebungen, statt jeweils individuelle Architekturen zu verhandeln. FinOps schafft dabei die Feedback-Schleife: Nutzungskosten fließen zurück in Architekturentscheidungen, Rightsizing wird zum kontinuierlichen Prozess statt Einmalaktion. So bleibt die Migration nicht nur technisch sauber, sondern wirtschaftlich steuerbar.

Post-Migration: Operate & Optimize

Nach dem Go-Live endet das Vorhaben nicht, sondern geht in einen dauerhaften Betriebs‑ und Optimierungszyklus über. Kontinuierliches Monitoring über Dienste wie CloudWatch, Azure Monitor oder Google Operations liefert laufend Daten zu Performance, Verfügbarkeit und Sicherheitslage. Auf Basis dieser Telemetrie nehmen Teams Rightsizing vor, bauen Überkapazitäten ab und verbessern die Kosteneffizienz. Gleichzeitig spielen sie Security-Patches ein, refaktorisieren Architekturbausteine und schulen die Belegschaft in cloud-nativen Praktiken. Nur so lassen sich die erwarteten Vorteile der Migration langfristig sichern.

Erfahrene Anbieter trennen deshalb strikt zwischen reiner Migration und anschließender Transformation. LeanIX beschreibt diesen Übergang als eigenen Reifegrad, in dem Governance, FinOps und Automatisierung eng verzahnt werden. Analytics8 betont, dass ohne fortlaufende Optimierung die ursprünglichen Business-Cases oft verfehlt werden – Kosten driften nach oben, Sicherheitslücken entstehen, technische Schulden wachsen. Post-Migration markiert nicht das Projektende, sondern den Start dauerhafter Prozesse: Monitoring, Rightsizing, Security-Hardening, Skill-Building.

Ein strukturierter Operate-Prozess umfasst daher: automatisierte Alarmierung bei Anomalien, regelmäßige Kosten-Reviews mit Tagging-Policies, Patch-Management nach Zero-Trust-Prinzipien sowie kontinuierliche Weiterbildung für Entwickler und Betriebsmannschaften. Wer diese Disziplinen als wiederkehrende Sprints organisiert, hält die Cloud-Landschaft stabil, sicher und wirtschaftlich – statt sie nach dem Cutover sich selbst zu überlassen.

Best-Practice-Checkliste für die Cloud-Migration

Eine aktuelle 8‑Schritt-Checkliste verdichtet die Projekterfahrung hunderter Migrationen auf einen handlungsleitenden Fahrplan. Der Leitfaden von Smart IMS und die Praxisdokumentation von Epta IT zeigen dabei denselben Kern: technische und organisatorische Arbeitspakete müssen verzahnt laufen, nicht nacheinander.

1. Bestandsaufnahme & Dependency-Mapping. Erfassen Sie Server, Applikationen, Datenbanken und deren Abhängigkeiten automatisiert. Ohne vollständiges Inventar bleiben Risiken im Blindflug.
2. Ziel-Cloud-Modell und Service-Auswahl. Entscheiden Sie pro Workload zwischen IaaS, PaaS oder SaaS. Die Entscheidung folgt Business-Zielen, nicht Vendor-Präferenzen.
3. Migrationsstrategie nach 6R/7R. Ordnen Sie jede Anwendung einem Muster zu: Rehost, Replatform, Refactor, Repurchase, Relocate, Retain, Retire. Hybridpfade sind erlaubt.
4. Landing Zones aufsetzen. Definieren Sie Identitätsmanagement, Netzwerktopologie, Security-Baselines und Tagging-Konventionen vor dem ersten Workload.
5. Pilotmigration mit Rollback-Test. Migrieren Sie ein repräsentatives, geringes Risiko tragendes System. Validieren Sie Funktion, Performance und Rückfallplan unter Realbedingungen.
6. Datenmigration planen und stagen. Nutzen Sie Staging-Bereiche, Change-Data-Capture und abgestimmte Cutover-Fenster. Datenkonsistenz wiegt schwerer als Geschwindigkeit.
7. Governance & FinOps etablieren. Implementieren Sie Policy-as-Code, Cost-Allocation-Tags und automatisierte Budget-Alarme ab Tag eins.
8. Betrieb, Monitoring, Optimierung. Nach Go-Live folgen Rightsizing, Security-Hardening und Skill-Building. Migration endet nicht beim Cutover.

Die Checkliste skaliert: Kleinere Vorhaben verdichten Schritte, Enterprise-Umgebungen iterieren über Wellen. Entscheidend bleibt die Durchgängigkeit – jede Lücke im Prozess wird später teurer geschlossen.

Beispiele aus der Praxis

Ein mittelständischer Fertigungsbetrieb migrierte sein ERP-System in drei klar getrennten Wellen. Zunächst verlegte das Team die Datenbank über einen abgeschlossenen Replikationspfad in eine verwaltete SQL-Instanz. Anschließend rehostete es die Anwendungsserver auf virtuelle Maschinen in der Zielumgebung. Im dritten Schritt refactorte es die Benutzerschnittstellen, um cloud-native Services wie Managed Identity und Serverless-Funktionen zu nutzen. Eine frühzeitig eingeführte Landing Zone mit vordefinierten Security-Baselines und Netzwerksegmentierung sicherte die Konformität nach ISO 27001 während des gesamten Prozesses. Ein begleitendes FinOps-Framework schaffte Transparenz über Ressourcennutzung und senkte die monatlichen Cloud-Kosten um 30 Prozent. Das Vorgehen dokumentiert IITS Consulting in einer Referenzarchitektur für hybride Migrationspfade. Ein Telco-Referenzprojekt half Infrastrukturkosten um 50 % zu halbieren bei 99,98 % Verfügbarkeit.

Ein Klinikverbund aus dem Gesundheitswesen wählte einen datenzentrischen Ansatz: Patientendaten wanderten schrittweise in ein spezialisiertes Data-Warehouse-Modell, das auf Spalten-Speicherung und Partitionierung setzt. Die Auswertungsgeschwindigkeit für analytische Abfragen vervierfachte sich gegenüber der On-Premises-Lösung. Gleichzeitig erhöhten Verschlüsselung im Transfer und at-rest die Datensicherheit auf einem Niveau, das die Anforderungen der DSGVO und des BDSG erfüllt. Amexus beschreibt dieses Szenario als Blaupause für regulierte Branchen, bei denen Compliance und Performance gleichgewichtet werden müssen.

Beide Fälle belegen: Wellenförmige Migrationen mit klarer Governance-Struktur und frühzeitiger Kostenkontrolle reduzieren Risiken und schaffen messbare operative Vorteile.