Warum die meisten Cloud Migrationen scheitern: Die Governance-Lücken, über die niemand spricht
Cloud-Migrationen scheitern nicht wegen schlechter Technologie, sondern wegen fehlender Governance. 75% überschreiten das Budget, 40% erleben Compliance-Vorfälle. Erfahren Sie die 5 kritischen Governance-Lücken, die Migrationen zum Scheitern bringen — und wie Sie ein Betriebsmodell aufbauen, das tatsächlich Wert liefert.
Fangen wir mit einer unbequemen Wahrheit an: Cloud-Infrastruktur war noch nie so gut wie heute. Die großen Anbieter garantieren 99,99% Verfügbarkeit. Die Werkzeuge sind ausgereift. Die Dokumentation ist umfangreich. Und trotzdem — 75% aller Cloud Migrationen überschreiten ihr Budget, ein erheblicher Teil läuft hinter dem Zeitplan, und 40% der Unternehmen berichten von Compliance-Vorfällen, die direkt auf Governance-Lücken während der Migration zurückzuführen sind.
Irgendetwas läuft hier grundlegend falsch. Und es liegt nicht an der Technologie.
Dieser Artikel beschäftigt sich mit dem Governance-Layer — dem Teil, den die meisten Anbieter nicht erwähnen, den die meisten Projektpläne überspringen, und den die meisten Unternehmen erst dann vermissen, wenn es zu spät ist. Egal ob Sie eine Migration planen, mittendrin stecken oder noch immer versuchen zu verstehen, warum eine abgeschlossene Migration nicht das geliefert hat, was versprochen wurde — es lohnt sich, das hier zu lesen, bevor Sie den nächsten Schritt machen.
Das Migrations-Paradox: Bessere Technologie, schlechtere Ergebnisse
Hier ist etwas, das viele Menschen verwirrt: Cloud-Infrastruktur funktioniert wirklich. Was früher Wochen gedauert hat, ist heute in Minuten bereitgestellt. Managed Services übernehmen ganze Kategorien von Komplexität, die früher Unmengen an Engineering-Zeit verschlungen haben. Die Plattformen sind stabil, die Dokumentation ist gut, und Support ist rund um die Uhr verfügbar.
Warum enden dann so viele Migrationen über Budget, hinter dem Zeitplan oder einfach... enttäuschend?
Ein Teil der Antwort liegt darin, was Cloud-Anbieter tatsächlich verkaufen. Sie verkaufen Kapazität — Rechenleistung, Speicher, Managed Services, globale Reichweite. Was sie nicht verkaufen, ist das Betriebsmodell, das Sie brauchen, um das alles zu betreiben. Diese Lücke — zwischen dem, was eingekauft wurde, und dem, was geplant wurde — ist der Ort, an dem Migrationen still und leise auseinanderfallen.
Denn die eigentliche Frage nach einer Migration lautet nie: "Hat die Technologie funktioniert?" Sie lautet: Wer ist jetzt für die Umgebung verantwortlich? Wer behält die Kosten im Blick? Wer ist zuständig, wenn eine Sicherheitskonfiguration abdriftet? Wen rufen Sie an, wenn um 2 Uhr nachts in sechs Monaten etwas nicht stimmt? Die meisten Migrationspläne beantworten das Was und das Wann in erschöpfenden Details. Das Wer und das Wie beantwortet kaum jemand.
Das nennt sich Governance. Und ihr Fehlen ist der häufigste Grund, warum Cloud Migrationen ihr Versprechen nicht einlösen — keine schlechte Architekturentscheidung, kein falscher Anbieter, kein zu knappes Budget. Einfach niemand, der sich überlegt hat, wie das Ganze nach Projektende eigentlich betrieben werden soll.
Die fünf Governance-Lücken, die Migrationen zum Scheitern bringen
Das sind keine Ausnahmefälle. Sie tauchen in Migrationen jeder Größe auf, in Unternehmen mit erfahrenen IT-Teams und realen Budgets. Es sind strukturelle Probleme — vorhersehbar, wiederholbar und mit der richtigen Vorbereitung vollständig vermeidbar.
1. Kein klares Verantwortungsmodell
Jede Migration hat ein Projektteam. Aber wenn die Migration abgeschlossen ist — wem gehört die Cloud-Umgebung eigentlich?
Diese Frage wird ständig auf später verschoben. Der Implementierungspartner ging davon aus, dass der IT-Betrieb übernimmt. Der IT-Betrieb nahm an, dass das Projektteam ordentliche Dokumentation übergibt. Die Finanzabteilung nahm an, dass die IT die Abrechnung übernimmt. Die Sicherheitsabteilung nahm an, dass die Basiskonfiguration stabil bleibt. Niemand hat irgendetwas davon schriftlich festgehalten. Wenn dann die Dinge anfangen zu driften — und das tun sie immer — ist niemand verantwortlich.
Kosten steigen unbemerkt. Konfigurationen ändern sich ohne Kontrolle. Die Umgebung, die beim Go-live sorgfältig eingerichtet wurde, sieht sechs Monate später völlig anders aus. Wenn niemand namentlich für Kostensteuerung, Sicherheitskonfiguration, Change Management und Lieferantenbeziehungen zuständig ist, läuft die Umgebung sich selbst — was gleichbedeutend damit ist, dass sie außer Kontrolle läuft.
Was stattdessen getan werden sollte: Bevor die Migration beginnt, das Betriebsmodell explizit definieren. Echte Namen an echte Verantwortlichkeiten knüpfen — wer genehmigt neue Services, wer verantwortet das Budget, wer trägt das Sicherheitsrisiko, wer managt die Lieferantenbeziehung. Aufschreiben. Nach 90 Tagen überprüfen.
2. Kostensteuerung als Nachgedanke
Der Business Case war klar: Die Migration würde die Infrastrukturkosten senken. Zwölf Monate später ist die Cloud-Rechnung 40% höher als die On-Premise-Infrastruktur zuvor.
Das passiert regelmäßig. Laut Flexera's State of the Cloud Report verschwenden Unternehmen im Durchschnitt 32% ihrer Cloud-Ausgaben. Die Ursachen sind fast immer dieselben: keine Tagging-Strategie, sodass niemand weiß, welches Team oder Projekt welche Kosten verursacht; VMs, die beim Launch überdimensioniert waren und nie angepasst wurden; On-Demand-Preise, die weiterlaufen, obwohl Reserved Instances nur einen Bruchteil kosten würden; Egress-Gebühren, die im ursprünglichen Modell niemand einkalkuliert hat.
Cloud-Abrechnung funktioniert anders als der Kauf von On-Premise-Hardware. Sie ist verbrauchsbasiert, variabel und ändert sich ständig. Man kann kein Budget festlegen und vierteljährlich nachschauen.
Was stattdessen getan werden sollte: Kostensteuerung als eigenständigen Workstream behandeln, nicht als nachgelagerte Aufgabe. Das bedeutet: eine Tagging-Taxonomie, die auf jede Ressource angewendet wird, bevor irgendetwas provisioniert wird; Budget-Alerts auf Account- und Projektebene; Right-Sizing-Reviews nach 30 und 90 Tagen; eine Committed-Use-Strategie für vorhersehbare Basislasten; und eine namentlich benannte Person — nicht "die IT" — deren tatsächliche Aufgabe das Cloud-Kostenmanagement umfasst.
3. Sicherheit beim Go-live konfiguriert, danach nie wieder angeschaut
Der Implementierungspartner hat während der Migration das Richtige getan: Firewall-Regeln, Identity and Access Management, Verschlüsselung. Alles war angemessen für die Umgebung zum Zeitpunkt des Go-live.
Das Problem ist, dass Cloud-Umgebungen nicht statisch bleiben. Neue Services werden gestartet. Nutzer werden hinzugefügt. Konfigurationen werden angepasst, um operative Probleme zu lösen. Anwendungen werden aktualisiert. IBMs Cost of a Data Breach Report zeigt konsequent, dass Fehlkonfigurationen zu den häufigsten Ursachen von Cloud-Sicherheitsvorfällen gehören — und die meisten dieser Fehlkonfigurationen entstehen nach dem initialen Setup, nicht während.
Sechs Monate später ist der Implementierungspartner längst weg. Die Person, die die Basiskonfiguration eingerichtet hat, ist möglicherweise nicht mehr im Team. Niemand prüft, ob die aktuelle Konfiguration noch dem beabsichtigten Sicherheitsniveau entspricht.
Was stattdessen getan werden sollte: Sicherheit muss als kontinuierlicher Prozess behandelt werden, nicht als Projektlieferable. Das bedeutet: Sicherheitsüberprüfung in den Change-Management-Prozess einbauen, Konfigurationen quartalsweise auditieren und jemanden damit beauftragen, Identity and Access Management regelmäßig zu überprüfen. Der Sicherheitsstatus sollte ein lebendes Dokument sein — kein Haken, der beim Go-live gesetzt wurde.
4. Lift-and-Shift ohne Architekturentscheidung
Lift-and-Shift ist aus einem einfachen Grund attraktiv: Es ist schnell. On-Premise-Workload nehmen, auf gleichwertige Cloud-Infrastruktur verschieben, Migration für abgeschlossen erklären. Das Problem: Es ist oft auch der schnellste Weg, am Ende mehr zu zahlen als vorher.
Workloads, die für On-Premise-Hardware entwickelt wurden, profitieren nicht automatisch von Cloud-Ökonomie. Eine große VM, die rund um die Uhr läuft, war sinnvoll, als die Hardware bereits eine Fixkost war. Dieselbe VM, die rund um die Uhr zu On-Demand-Cloud-Preisen läuft, kann erheblich teurer sein. Die echten Cloud-Vorteile — Elastizität, Auto-Scaling, Managed Services — greifen nur, wenn die Architektur darauf ausgelegt ist, sie zu nutzen.
Aber Replatforming oder Refactoring braucht Zeit und Fähigkeiten, die das Team möglicherweise nicht hat. Also wird Lift-and-Shift zum Standard für alles, die Kosteneinsparungen aus dem ursprünglichen Business Case bleiben aus, und alle fragen sich, was schiefgelaufen ist.
Was stattdessen getan werden sollte: Eine explizite, dokumentierte Entscheidung für jeden Workload treffen — Rehost, Replatform, Refactor oder Retire. Gartners 5 Rs Framework für Cloud Migration bietet einen strukturierten Ansatz dafür. Nicht alles sollte in die Cloud. Und nicht alles, was migriert wird, sollte auf die gleiche Weise migriert werden.
5. Kein Plan für den laufenden Betrieb nach Go-live
Migrationsprojekte haben ein Enddatum. Der Cloud-Betrieb nicht.
Der riskanteste Moment in den meisten Migrationen ist nicht die Umstellung selbst. Es ist die Woche nach dem Go-live, wenn das Projektteam sich auflöst und das Betriebsteam eine Umgebung erbt, die es nicht aufgebaut hat, nicht vollständig versteht und auf die es nicht wirklich vorbereitet wurde. Monitoring ist nicht für die neue Umgebung konfiguriert. Runbooks existieren nicht. Die Backup- und DR-Richtlinien wurden für On-Premise-Infrastruktur geschrieben und nicht aktualisiert. Niemand hat Recovery in der Cloud tatsächlich getestet.
Aus Projektsicht lief alles gut — pünktlich, im Budget. Die operativen Konsequenzen zeigen sich in den folgenden Monaten.
Was stattdessen getan werden sollte: Der Betrieb nach Go-live muss während der Migration geplant werden, nicht danach. Wissenstransfer, operative Dokumentation, Monitoring-Konfiguration, Alert-Schwellenwerte und DR-Tests sollten Migrationslieferables sein — keine Punkte, die auf einer Nachfolgeliste landen. Das Betriebsteam sollte von Anfang an Teil des Projekts sein, nicht erst bei der Übergabe mit der Umgebung konfrontiert werden.
Das Migrations-Betriebsmodell: Wie es richtig aussieht
Eine gut gesteuerte Migration ist nicht komplizierter als eine schlecht gesteuerte. Sie trifft einfach mehr Entscheidungen früher, statt Lücken später zu entdecken. Und für ein mittelständisches Unternehmen mit der richtigen Begleitung braucht das kein großes Team und kein mehrjähriges Programm.
Was ein vollständiges Betriebsmodell tatsächlich umfasst:
Governance-Layer. Entscheidungsrechte werden definiert, bevor die Migration beginnt. Wer genehmigt die Provisionierung neuer Services? Wer kontrolliert die Budgets? Wer trägt das Sicherheitsrisiko? Wer managt Lieferantenbeziehungen? Diese Entscheidungen müssen schriftlich existieren — so, dass das Betriebsteam sie tatsächlich nachschlagen kann, wenn das Projektteam weg ist.
Kosten-Layer. Eine Tagging-Taxonomie, die auf jede Ressource von Tag eins an angewendet wird. Budget-Alerts auf Account-, Projekt- und Teamebene. Right-Sizing-Reviews nach 30 und 90 Tagen. Eine Committed-Use-Strategie für vorhersehbare Basislasten. Eine namentlich benannte Person, die für das Cloud-Kostenmanagement verantwortlich ist.
Sicherheits-Layer. Basiskonfigurationen beim Go-live definiert und dokumentiert. Sicherheitsüberprüfung in den Change-Management-Prozess integriert — nicht nachträglich hinzugefügt. Konfigurationsaudits im Quartalsrhythmus. Identity and Access Management regelmäßig überprüft. Incident-Response-Verfahren in der Cloud-Umgebung getestet, bevor der Schalter umgelegt wird.
Architektur-Layer. Eine explizite Entscheidung für jeden Workload — Rehost, Replatform, Refactor oder Retire. Ein Workload-Inventar, das das Betriebsteam tatsächlich nutzen kann. Dokumentation darüber, was migriert wurde, warum, und was dabei außer Betrieb genommen wurde.
Betriebs-Layer. Monitoring und Alerting speziell für die Cloud-Umgebung konfiguriert — nicht von On-Premise übernommen. Runbooks geschrieben. Backup und DR getestet. Wissenstransfer abgeschlossen, bevor das Projektteam sich auflöst. Namentlich benannte Verantwortliche für jeden operativen Bereich.
Wer eine Migration plant oder überprüft, kann die eigene Situation gegen jeden dieser Layer messen und sehen, wo die Lücken sind. Genau das ist der Punkt.
Die versteckten Kosten des Scheiterns — und der ROI des Gelingens
Die Kostenschocks sind das, was Aufmerksamkeit bekommt. Aber Kostenüberschreitungen sind eigentlich nur das sichtbarste Symptom von Governance-Versagen — nicht das schädlichste.
Die tatsächlichen Kosten sehen so aus: Geschäftsergebnisse, die nach der Migration eintreten sollten, sind zwölf Monate später immer noch nicht eingetreten. Sicherheitsvorfälle durch Konfigurationsdrift, die laut Cloud Security Alliance und Gartner für 80% aller Cloud-Sicherheitsverletzungen verantwortlich sind. Compliance-Risiken durch DSGVO und — ab Oktober 2026 — NIS2. Ein IT-Team, das eine Umgebung geerbt hat, auf die es nicht vorbereitet war, und diese jetzt reaktiv betreibt und dabei ausbrennt. Im schlimmsten Fall die Kosten einer teilweisen Rückabwicklung einer Migration, für die bereits bezahlt wurde.
Das ist nicht theoretisch. Es ist einfach das, was passiert, wenn der Governance-Layer übersprungen wird.
Die andere Seite ist genauso real. Eine gut gesteuerte Migration — bei der das Betriebsmodell gemeinsam mit der technischen Architektur entworfen wird — liefert deutlich andere Ergebnisse. Signifikante IT-Kostensenkung. Infrastrukturverfügbarkeit im hohen Bereich. Umgebungen, die mit dem Unternehmen wachsen, statt es einzuschränken. Arbeitsplätze, die tatsächlich die Art und Weise unterstützen, wie Menschen heute arbeiten.
Diese Ergebnisse entstehen nicht durch die Wahl des richtigen Cloud-Anbieters. Die Plattform ist in beiden Szenarien dieselbe. Was sich unterscheidet, ist die Governance — die Betriebsmodell-Entscheidungen, die darüber bestimmen, ob die Migration tatsächlich Wert schafft oder nur dieselben Probleme in eine teurere Umgebung verlagert. Unternehmen, die das richtig machen, vermeiden nicht nur die beschriebenen Fehler. Sie bauen etwas auf, das sich mit der Zeit weiter verbessert.
Was jetzt zu tun ist
Sie haben jetzt ein Framework. Die Frage ist, wo Sie im Vergleich dazu stehen.
Wenn Sie eine Migration planen, bildet ein Cloud Readiness Assessment Ihre aktuelle IT-Landschaft, Ihr Betriebsmodell und Ihre Governance-Fähigkeiten gegen das obige Framework ab. Es ist der schnellste Weg, Lücken zu erkennen, bevor sie zu Problemen werden, die Sie unter Druck lösen müssen.
Wenn Sie mitten in einer Migration stecken, kann ein Governance-Review erkennen, welche Layer unvollständig sind, bevor Sie den Go-live erreichen. Governance-Lücken während einer Migration zu schließen, ist deutlich günstiger als danach.
Wenn Sie eine Migration abgeschlossen haben, die nicht geliefert hat, kann ein operatives Audit aufzeigen, was tatsächlich schiefgelaufen ist — ob es Kostenüberschreitungen, Sicherheitsdrift, Verantwortungslücken oder eine Kombination davon sind — und was nötig ist, um die Umgebung so zum Laufen zu bringen, wie es gedacht war.
Beginnen Sie mit einem kostenlosen 30-minütigen Gespräch. Bringen Sie Ihren Migrationsplan, Ihre aktuelle Cloud-Umgebung oder einfach Ihre Fragen mit. Wir sagen Ihnen, was wir sehen.