Stand: Oktober 2026
TL;DR – Cloud-Migration auf einen Blick
Eine Cloud-Migration überführt Workloads, Daten und Applikationen von On-Premise-Infrastrukturen in Cloud-Umgebungen. Ohne strategischen Fahrplan, FinOps-Disziplin und Change Management drohen Kostenexplosionen, Downtime und Compliance-Verstöße. Der AWS-Blog benennt fünf klassische Fallen, die Projekte ausbremsen (Best-Practice-Analyse). Bitkom hebt hervor, dass Governance und Exit-Strategien bereits vor dem ersten Workload-Transfer definiert sein müssen (Verbands-Leitfaden).
Dieser Artikel beleuchtet die acht kritischsten Stolpersteine – von blindem Lift-&-Shift über fehlende Dependency-Maps bis zum fehlenden Executive Buy-in – und liefert konkrete Gegenmaßnahmen für eine gelungene Migration.

Definition: Was ist Cloud-Migration?
Cloud-Migration bezeichnet den planvollen Umzug von IT-Ressourcen – Servern, Datenbanken, Applikationen und Daten – von lokaler Hardware in private, öffentliche oder hybride Cloud-Umgebungen. Ziel ist es, Skalierbarkeit, Agilität und Kosteneffizienz zu gewinnen. Der Prozess gliedert sich in Assessment, Planung, Migration, Validierung und anschließende Optimierung. Er folgt etablierten Strategien wie dem 6R-Modell (Rehost, Replatform, Refactor, Repurchase, Retire, Retain), das für jede Workload den passenden Migrationspfad vorgibt.
Ein strukturierter Ansatz beginnt mit einer Bestandsaufnahme aller Abhängigkeiten und Leistungsprofile. Danach entscheiden Teams, ob Anwendungen unverändert gehoben, leicht angepasst oder grundlegend neu architekturiert werden. LeanIX betont, dass eine transparente Dependency-Mapping die Basis für risikoarme Wellenplanung bildet. Analytics8 ergänzt, dass Governance-Regeln für Kosten, Sicherheit und Compliance bereits vor dem ersten Move definiert sein müssen.
Nach dem Cutover folgt die kontinuierliche Feinjustierung: Rightsizing von Instanzen, Automatisierung von Betriebsprozessen und Einbindung in FinOps-Reportings. Nur so lässt sich der Nutzen der Cloud dauerhaft realisieren. KI-gestützte Tools wie AWS Migration Hub Refactor Spaces oder Azure Migrate beschleunigen heute die Assessment-Phase durch automatisierte Dependency-Analyse und Refactoring-Vorschläge.
Wie funktioniert eine Cloud-Migration? – Schritt für Schritt
Eine strukturierte Cloud-Migration gliedert sich in fünf aufeinander aufbauende Phasen. Der Prozess beginnt mit Assessment & Discovery: Teams inventarisieren sämtliche Assets, kartieren Abhängigkeiten und bewerten die Business-Kritikalität jeder Anwendung. Automatisiertes Dependency-Mapping schafft hier Transparenz, wie Atlan in seiner Analyse zeigt.
In Phase zwei, Strategie & Target Architecture, legen Entscheider die Migrationsstrategie fest – meist entlang des 6R- oder 7R-Modells (Rehost, Replatform, Refactor, …). Gleichzeitig definieren sie die Landing Zone, Sicherheitsrichtlinien und Governance-Rahmen. AWS warnt davor, diesen Schritt zu überspringen, weil fehlende Zielarchitektur spätere Kostenexplosionen provoziert.
Phase drei, Pilot & Wave Planning, migriert zunächst niedrigschwellige Workloads. Learnings fließen in die Wellenplanung für Produktionssysteme ein, sodass Risiken schrittweise sinken.
Die vierte Phase, Migration & Cutover, nutzt automatisierte Werkzeuge für Rehost und Replatform. Blue-Green-Deployments ermöglichen Zero Downtime, validierte Rollback-Pläne sichern den Notfall ab.
Abschließend etabliert Optimize & Operate FinOps-Praktiken, Continuous Security und Platform Engineering für Self-Service. MaibornWolff betont, dass Go-Live nicht das Ende markiert, sondern den Start kontinuierlicher Optimierung einläutet. Internal Developer Platforms (IDPs) setzen Self-Service-Standards durch und verhindern Shadow IT – vorausgesetzt, Plattform-Teams bleiben dauerhaft betraut.
Fallstrick 1: Fehlender strategischer Fahrplan
Ohne Cloud-Readiness-Check und belastbaren Business-Case starten Migrationen planlos. Die Folge: technische Inkompatibilitäten, verzögerte Zeitpläne und Budgetüberschreitungen. Ein strukturierter Ansatz klassifiziert Workloads über 6R- oder 7R-Modelle, definiert Migrationswellen mit messbaren Meilensteinen und bindet Fachbereiche von Beginn an ein. AWS empfiehlt, Migration als Programm mit Governance-Struktur aufzusetzen, nicht als reines IT-Projekt.
Der AWS Cloud Operations Blog nennt fehlende Planung als häufigsten Grund für Stillstand. Wer ohne Zielbild migriert, verschiebt Probleme nur in die Cloud. Stattdessen sollte jede Welle einen eigenen Business-Case tragen, Abhängigkeiten vorab geklärt und Exit-Kriterien definiert sein.
Analysten von Talan betonen, dass ein Migrationsprogramm klare Rollen, Eskalationspfade und regelmäßige Steering-Committee-Reviews braucht. Nur so lassen sich Scope Creep und Ressourcenkonflikte früh erkennen. Der Fahrplan ist kein starres Dokument, sondern lebendiges Steuerungsinstrument – angepasst an Erkenntnisse aus jeder Welle.
Fallstrick 2: Kostenexplosion durch Blind-Lift-&-Shift
Wer On-Premise-Ressourcen eins zu eins in die Cloud hebt, kauft sich teure Überprovisionierung. Ein reines Rehosting ohne Right-Sizing lässt Instanzen laufen, die lokal noch tolerierbar waren, in der Cloud aber monatlich zu Buche schlagen. Analysen von Ideas2IT zeigen, dass genau dieser Blindflug die häufigste Ursache für Budgetüberschreitungen ist.
FinOps-Disziplin gehört daher vor den ersten Migrationswellen auf die Agenda. Tagging-Policies erzwingen Kostentransparenz pro Team und Applikation. Showback- und Chargeback-Modelle machen Verbrauch sichtbar und schaffen Anreize zum Sparen. Continuous Cost Monitoring deckt Zombie-Ressourcen und Idle-Instanzen in Echtzeit auf. Die BW-Tech-Analyse warnt ausdrücklich vor „Luftschlössern“ ohne Kostenkontrolle ab Tag 1.
Konkrete Hebel liegen auf der Hand: Right-Sizing passt Instanztypen an tatsächliche Last an. Reserved Instances und Savings Plans senken laufende Kosten um 30 bis 50 Prozent gegenüber On-Demand-Preisen. Invensis Learning empfiehlt, diese Mechanismen bereits im Migrationsplan zu verankern – nicht als nachträgliches Optimierungsprojekt. Wer Cloud-Kosten wie Projektkosten behandelt, verliert die Kontrolle. Wer sie wie Produktkosten steuert, behält sie im Griff.
Fallstrick 3: Downtime und Datenverlust
Ungeplante Ausfallzeiten und inkonsistente Datensätze zählen zu den kritischsten Risiken jeder Cloud-Migration. Wer Produktionssysteme ohne abgesicherten Cutover umstellt, riskiert Umsatzeinbußen und Reputationsschäden. Standardmaßnahmen für Zero-Downtime umfassen Blue-Green-Deployments und Canary-Releases, bei denen Traffic schrittweise auf die neue Umgebung umgelenkt wird. Automatisierte Validierungstests prüfen Funktionalität und Performance, bevor der Switch final erfolgt.
Ein validierter Rollback-Plan muss vor dem Cutover getestet sein – nicht erst im Fehlerfall. Atlassian betont, dass Rollback-Strategien unter realen Lastbedingungen durchgespielt werden müssen. Cortex weist darauf hin, dass viele Teams Rollback-Szenarien nur theoretisch dokumentieren, aber nie ausführen.
Bei Datenbank-Migrationen führt kein Weg an Change Data Capture (CDC) und paralleler Synchronisation vorbei. Quell- und Zielsystem laufen dabei simultan, CDC repliziert Änderungen in Echtzeit. Erst nach vollständigem Abgleich und Validierung erfolgt der finale Cutover. LeanIX empfiehlt, Migrationsfenster großzügig zu planen und Puffer für Nachlaufzeiten einzuplanen. Wer diese Disziplinen vernachlässigt, kauft sich technische Schulden, die sich nach dem Go-Live nur noch mit hohem Aufwand auflösen lassen.

Fallstrick 4: Inkompatible Altlasten und technische Schulden
Legacy-Monolithen mit harten Abhängigkeiten und veralteten Datenbank-Architekturen brechen bei ungeprüfter Migration oft zur Laufzeit. Wer Anwendungen 1:1 in die Cloud hebt, überträgt technische Schulden nur auf teurere Infrastruktur. Ein Application Portfolio Assessment deckt kritische Pfade auf: welche Services eng gekoppelt sind, wo Shared-Nothing-Architekturen fehlen und welche Datenbanken keine horizontale Skalierung zulassen.
Dependency Mapping gehört vor den ersten Migrations-Wellen. Es zeigt Laufzeit-Beziehungen zwischen Modulen, Datenbanken und externen Schnittstellen. Ohne diese Transparenz entstehen nach dem Cutover Fehler, die in Testumgebungen nicht auftreten – etwa durch veränderte Latenzprofile oder fehlende Transaktionsgarantien bei verteilten Systemen.
Drei Strategien bewähren sich: Replatform durch Containerisierung schafft Portabilität ohne Code-Umbau. Refactor auf Microservices löst Domänengrenzen technisch auf – aufwendig, aber nachhaltig. Datenbank-Modernisierung auf Distributed SQL (etwa PostgreSQL-kompatible Cluster) ersetzt monolithische RDBMS, die in der Cloud zur Flaschenhals werden. Consist empfiehlt, Modernisierungsschritte fest in den Migrationsplan einzubauen statt sie auf „später“ zu verschieben. Wer technische Schulden vor dem Go-Live abbaut, vermeidet teure Nachbesserungen im laufenden Betrieb.
Fallstrick 5: Skills Gap im eigenen Team
Fehlende Cloud-Kompetenz bremst Migrationsprojekte massiv aus. 70 % der Organisationen nennen mangelndes Fachwissen als größtes Hindernis, wie Analysen von Cortex, IT-Matchmaker und IT-Daily übereinstimmend zeigen.
Gegensteuern lässt sich über drei Hebel. Erstens: strukturiertes Upskilling mit anerkannten Zertifizierungen der großen Hyperscaler – AWS, Azure und GCP bieten passende Pfade für Architekten, Entwickler und Betriebsteams. Zweitens: erfahrene Migrationspartner einbinden, die nicht nur Werkzeuge liefern, sondern Wissen aktiv in die Organisation tragen. Drittens: ein internes Cloud Center of Excellence (CCoE) aufbauen, das Standards setzt, Governance definiert und als Kompetenzanker dient.
Entscheidend: Knowledge Transfer muss fester Vertragsbestandteil jeder Partner-Vereinbarung sein. Nur so bleibt das Know-how nach Projektabschluss im Haus und verhindert erneute Abhängigkeit bei Folgevorhaben. Ein Handelskonzern scheiterte 2023 an der Kubernetes-Migration, weil interne Teams Helm-Charts und Operators nicht beherrschten – externe Experten übernahmen, doch nach Vertragsende fehlte das Wissen für Day-2-Operations.
Fallstrick 6: Sicherheit, Compliance und Exit-Strategie als Nachgedanke
Wer Sicherheit und Compliance erst nach dem Go-Live adressiert, baut technische Schulden ein, die sich später nur mit hohem Aufwand auflösen lassen. Regulatorische Rahmenwerke wie die DSGVO, die NIS2-Richtlinie, DORA für den Finanzsektor sowie der BSI C5-Kriterienkatalog verlangen Compliance-by-Design. Landing Zones müssen daher vor der Migration mit Policy-as-Code, Verschlüsselung, Identity & Access Management und durchgängigem Audit-Logging bereitstehen.
Ein häufig übersehener Aspekt ist die Exit-Strategie. Data Portability und Vendor-Lock-in-Vermeidung durch offene Standards wie Kubernetes, Terraform oder OpenTofu gehören auf den Verhandlungstisch, bevor Verträge unterschrieben werden. Data Dynamics weist darauf hin, dass fehlende Portabilität spätere Wechsel wirtschaftlich unrentabel macht. Cloud Computing Insider warnt davor, Compliance-Themen als nachgelagerte Aufgabe zu sehen. PrivacyXperts betont, dass Cloud-Transformation mehr ist als ein Serverumzug – Governance und Exit-Planung müssen von Beginn an mitgedacht werden. Wer diese Punkte erst im Betrieb angeht, riskiert Bußgelder, Reputationsschaden und teure Neuarchitektur.
Fallstrick 7: Fehlendes Executive Buy-in und Change Management
Ohne Rückhalt im Top-Management fehlen Budget, Mandat und querschnittsübergreifende Kooperation. Ein quantifizierter Business-Case mit ROI schafft die Entscheidungsgrundlage; regelmäßige Steering-Committee-Updates halten den Kurs sichtbar. Ein Kommunikationsplan für Fachbereiche übersetzt technische Meilensteine in Business-Nutzen und baut Akzeptanz auf.
Cutover betont, dass Change Management – Schulungen, Stakeholder-Mapping, Widerstandsmanagement – genauso kritisch ist wie die technische Migration selbst. AWS warnt davor, organisatorische Trägheit zu unterschätzen: Wer nur Server verschiebt, ohne Prozesse und Rollen anzupassen, reproduziert alte Silos in der neuen Umgebung. Ein strukturierter Ansatz identifiziert Betroffene früh, bindet Multiplikatoren ein und plant Widerstandsszenarien ein.
Erfolgreiche Programme behandeln Migration als Change-Initiative mit Sponsoring auf C-Level, nicht als reines IT-Projekt. Cutover nennt fünf Hebel, um Scheitern zu vermeiden, darunter klare Governance und kontinuierliche Kommunikation. AWS listet fehlendes Executive Sponsoring als Top-Risiko und empfiehlt messbare Ziele sowie regelmäßige Reviews. Eine Analyse zeigt, dass kulturelle Hürden oft technische überwiegen – wer sie ignoriert, scheitert am Go-Live. Ein Logistikdienstleister stoppte 2024 seine Azure-Migration nach sechs Monaten, weil der CFO den Business-Case nicht freigab – Fachbereiche blockierten anschließend den Zugriff auf Testdaten.
Fallstrick 8: Migration als Projekt mit Enddatum verstehen
Der Go-Live markiert nicht das Finale, sondern den Beginn des eigentlichen Cloud-Betriebs. Wer das Budget mit dem Cut-over schließt, verliert den ROI aus den Augen. Analytics8 beschreibt Migration als Programm, das Continuous Cost Optimization, Security Posture Management und Platform Engineering dauerhaft finanziert. FinOps, SecOps und Application Modernisierung verlangen Produkt-Denken statt Projektabrechnung.
Kosten explodieren oft Monate nach dem Umzug, weil Teams Instanzen nicht right-sizen, Storage-Klassen ungeprüft lassen oder Zombie-Ressourcen vergessen. Ein BW-Tech-Beitrag warnt vor genau diesem „Luftschloss“-Effekt: Ohne fortlaufende Governance wachsen Rechnungen still und leise. Tagging-Policies, Showback-Modelle und automatisierte Rightsizing-Loops gehören in den laufenden Betrieb, nicht in den Migrationsplan.
Sicherheit verhält sich analog. Compliance-Rahmenwerke wie NIS2 oder DORA fordern kontinuierliche Nachweise. Policy-as-Code in der Landing Zone reicht nicht; Threat Detection, Patch-Management und Zero-Trust-Segmentierung brauchen dedizierte Kapazitäten. MaibornWolff betont, dass Internal Developer Platforms (IDPs) Self-Service-Standards durchsetzen und Shadow IT verhindern – aber nur, wenn Plattform-Teams dauerhaft betreut werden.
Fazit: Migration endet nie. Sie geht in ein Betriebsmodell über, das Kosten, Sicherheit und Entwicklerproduktivität als permanente Optimierungsziele behandelt. Budget und Mandat dafür müssen vor Tag 1 stehen.

Beispiele aus der Praxis: Typische Migrationsszenarien
Ein mittelständischer Fertigungsbetrieb migriert sein SAP-ERP per Lift & Shift nach Azure. Right-Sizing der VM-Größen und eine FinOps-Governance mit Tagging-Policies verhindern Kostenüberraschungen. Bestehende MES-Systeme bleiben on-premise und werden über ExpressRoute hybrid angebunden – Latenzkritische Steuerungsdaten verlassen das Werk nicht.
Ein Finanzdienstleister baut seinen Monolithen zu Kubernetes-Microservices auf AWS um. Compliance-by-Design sichert BaFin-Anforderungen und DSGVO-Konformität bereits in der Landing Zone ab. Ein Blue-Green-Cutover mit automatisierten Smoke-Tests ermöglicht den produktiven Wechsel ohne Downtime. Datenbank-Migration läuft über CDC-Replikation, Rollback-Plan ist vorab validiert.
Die öffentliche Verwaltung setzt auf Multi-Cloud mit OpenTofu für Portabilität zwischen Anbietern. Eine BSI C5-konforme Landing Zone stellt Auditierbarkeit her. Exit-Klauseln im Vertrag regeln Datenrückführung, Formatvorgaben und Übergangszeiträume – Vendor-Lock-in wird technisch und rechtlich adressiert.




































