Cloud-Migration-Strategie: die Entscheidungen, die später teuer werden

Die teuersten Posten einer Cloud-Migration entstehen, bevor die erste Workload umzieht: bei der Wahl der Migrationsstrategie pro System, bei der Reihenfolge und beim Plan für den Betrieb nach dem Cutover. Wer eine Cloud-Migration-Beratung anfragt, bekommt häufig einen Zeitplan und eine Werkzeugliste. Die Entscheidungen, die drei Jahre später auf der Rechnung stehen, kommen darin oft gar nicht vor. Dieser Artikel geht sie der Reihe nach durch.

Warum die Endkosten vor der Migration festgelegt werden

Im Business Case einer Cloud-Migration steht meistens das Projektbudget im Mittelpunkt: die Monate des Umzugs, die externen Tagessätze, die Lizenzumstellung. Über die Lebensdauer der Systeme gerechnet ist das der kleinste Posten. Der größte ist der laufende Betrieb danach, und dessen Höhe wird durch Entscheidungen bestimmt, die vor dem ersten Umzug fallen.

Ein Beispiel macht das konkret. Ob eine Anwendung unverändert auf eine Cloud-VM gehoben wird oder vorher auf verwaltete Dienste umgebaut wird, verändert die monatliche Rechnung dieser Anwendung dauerhaft, in beide Richtungen. Die unveränderte VM läuft rund um die Uhr weiter, wie es der alte Server tat, und kostet entsprechend. Der Umbau kostet vorab Entwicklungszeit und senkt danach die Betriebskosten. Welcher Weg sich rechnet, hängt vom einzelnen System ab: von seiner Restlebensdauer, seiner Last, seinem Änderungsdruck. Genau diese Abwägung wird in vielen Projekten übersprungen, weil ein einziges Vorgehen für das ganze Portfolio beschlossen wird.

Wie groß der Hebel ist, zeigen die Branchenzahlen: Der jährliche State of the Cloud Report von Flexera weist seit Jahren aus, dass Unternehmen ihre Cloud-Ausgaben zu einem erheblichen Teil als verschwendet einschätzen, in der Größenordnung von einem Viertel bis einem Drittel. Diese Verschwendung entsteht selten im Rechenzentrum des Anbieters. Sie entsteht in Migrationsentscheidungen, die nie pro System getroffen wurden.

Die 6R sind eine Entscheidung pro System

Für die Frage, wie ein einzelnes System in die Cloud kommt, hat sich ein Raster aus sechs Optionen etabliert, die 6R:

• Rehost: das System unverändert auf Cloud-Infrastruktur heben (Lift-and-Shift). Schnell, aber die Kostenstruktur des alten Betriebs zieht mit um.
• Replatform: gezielte Anpassungen beim Umzug, etwa die Datenbank auf einen verwalteten Dienst umstellen, ohne die Anwendung neu zu bauen.
• Refactor: die Anwendung für die Cloud umbauen, bis hin zur Neuarchitektur. Teuer vorab, sinnvoll für Systeme mit hohem Änderungsdruck und langer Restlebensdauer.
• Repurchase: die Eigenentwicklung durch ein SaaS-Produkt ersetzen und die Daten migrieren statt der Software.
• Retire: das System abschalten. In gewachsenen Portfolios häufiger möglich, als die Inventarliste vermuten lässt.
• Retain: das System bewusst nicht migrieren und dort lassen, wo es läuft.

Jede dieser sechs Optionen hat ein eigenes Kostenprofil über die Zeit. Rehost ist im Projekt am billigsten und im Betrieb am teuersten; Refactor kehrt das Verhältnis um; Repurchase tauscht Entwicklungs- gegen Abonnementkosten und verlagert die Wartung zum Hersteller. Die Entscheidung pro System ist damit eine Rechnung über die Restlebensdauer, keine Geschmacksfrage.

Der verbreitete Fehler ist ein pauschales Rehost über das ganze Portfolio, weil es die Migration planbar und schnell macht. Für einzelne Systeme ist Rehost die richtige Antwort, etwa für stabile Anwendungen mit kurzer Restlebensdauer, bei denen sich jeder Umbau verbietet. Als Portfoliostrategie zieht es dagegen jede Altlast mit in die Cloud und verewigt sie dort zu laufenden Kosten. Ein überdimensionierter Server, der im eigenen Rechenzentrum abgeschrieben war, wird als überdimensionierte Cloud-VM jeden Monat neu bezahlt.

Die Triage pro System ist Arbeit: eine Bestandsaufnahme des Portfolios, pro Anwendung eine Einordnung nach Geschäftswert, Änderungsdruck, technischem Zustand und Abhängigkeiten, daraus die Zuordnung zu einem der sechs Wege. Für ein mittleres Portfolio ist das eine Frage von Wochen, keine Formalität und kein Jahresprojekt. Verglichen mit den Betriebskosten, die eine falsche Pauschalentscheidung über Jahre erzeugt, ist es die günstigste Phase des gesamten Vorhabens.

Die Reihenfolge ist eine Kostenentscheidung

Sobald pro System eine Strategie feststeht, folgt die zweite Weichenstellung: in welcher Reihenfolge migriert wird. Sie wird oft als Terminplanung behandelt. Tatsächlich ist sie eine Kostenentscheidung mit zwei Mechanismen.

Der erste ist der Parallelbetrieb. Vom ersten Umzug bis zur Abschaltung der alten Umgebung bezahlen Sie beide Welten gleichzeitig: das Rechenzentrum mit seinen Fixkosten und die wachsende Cloud-Rechnung. Jeder Monat, den diese Phase länger dauert, ist ein Monat doppelter Infrastruktur. Eine Reihenfolge, die das Rechenzentrum früh in großen Blöcken leert, verkürzt diese Phase; eine, die aus jedem Rack ein wenig mitnimmt, verlängert sie und hält die Fixkosten der alten Umgebung bis zum Schluss hoch.

Der zweite Mechanismus sind Abhängigkeiten. Anwendungen, die intensiv miteinander sprechen, gehören in dieselbe Migrationswelle. Wird ein eng gekoppeltes Paar getrennt, läuft sein Datenverkehr monatelang zwischen Rechenzentrum und Cloud hin und her, mit der Latenz und den Übertragungskosten, die das erzeugt. In der Praxis heißt das: Vor der Wellenplanung steht eine Abhängigkeitsanalyse, welche Systeme ein Cluster bilden, und die Welle schneidet entlang der Clustergrenzen.

Ein Sonderfall verdient eigene Aufmerksamkeit: große Datenbestände. Daten haben Gewicht. Wo die Daten liegen, dorthin ziehen die Anwendungen, die auf ihnen arbeiten, und ein zentraler Datenbestand, der zu früh oder zu spät umzieht, zwingt allen abhängigen Systemen seinen Zeitplan auf. Die Migration der großen Bestände gehört deshalb als eigener Punkt in die Wellenplanung, mit realistischen Annahmen zu Übertragungsdauer und Übergangsbetrieb.

Für die erste Welle gilt dieselbe Logik wie bei jeder schrittweisen Ablösung: ein Vorhaben von mittlerem Gewicht und überschaubarer Verflechtung, an dem das Team Landing Zone, Netzanbindung und Berechtigungsmodell unter realen Bedingungen erprobt. Die geschäftskritischen Cluster kommen, wenn diese Grundlagen sich bewährt haben.

Betrieb nach dem Cutover: die Verantwortung braucht einen Namen

Der Cutover beendet das Migrationsprojekt. Den Betrieb beendet er nicht, er verändert ihn grundlegend, und dieser Punkt wird in der Planung am häufigsten unterschätzt.

Im eigenen Rechenzentrum waren die Kosten träge: Ein Server war gekauft, seine Kosten standen fest, ob er ausgelastet war oder nicht. In der Cloud sind die Kosten eine Funktion des täglichen Verhaltens. Eine vergessene Testumgebung, eine zu groß gewählte Instanz, ein Datenexport, der jede Nacht läuft und den niemand mehr braucht: All das erscheint auf der nächsten Rechnung. Ohne eine Stelle, die diese Rechnung liest, versteht und handelt, wächst sie. Die Disziplin dafür hat einen Namen, FinOps, und sie braucht vor dem Cutover einen Verantwortlichen, ein Tagging-Konzept, das Kosten den Teams zuordnet, und Budgetalarme, die anschlagen, bevor der Monat vorbei ist.

Dasselbe gilt für die Sicherheit. Cloud-Anbieter arbeiten nach dem Modell der geteilten Verantwortung: Der Anbieter sichert die Infrastruktur, den Betrieb darauf sichert der Kunde, von der Konfiguration über das Berechtigungsmodell bis zum Patching der eigenen Systeme. Wer den Betrieb nach dem Cutover mit derselben Mannschaft und denselben Abläufen weiterführt wie vor der Migration, hat eine Lücke: Die Handgriffe sind andere, die Fehlerbilder sind andere, und die Werkzeuge des alten Rechenzentrums greifen nicht mehr.

Die Konsequenz für die Planung ist unbequem und einfach zugleich. Das Betriebsmodell nach der Migration, mit benannten Verantwortlichen für Kosten, Berechtigungen und Patching, gehört in den Projektumfang der Migration selbst. Ein Projekt, das mit dem Cutover endet und den Betrieb der Linie überlässt, die nie gefragt wurde, hat seinen teuersten Teil nicht geplant.

Exit-Kosten gehören in den Business Case von Tag eins

Jede Migrationsentscheidung legt zugleich fest, was ein späterer Wechsel kosten würde: zu einem anderen Anbieter, zurück ins eigene Rechenzentrum oder zu einem europäischen Souveränitätsangebot. Diese Exit-Kosten stehen auf keiner Rechnung, solange niemand wechselt, und genau deshalb fehlen sie in den meisten Business Cases.

Zwei Posten bestimmen sie. Der erste sind die Daten: Ausgehender Datenverkehr kostet bei den großen Anbietern Geld, und bei Datenbeständen im dreistelligen Terabyte-Bereich wird der Auszug zu einem eigenen Projekt mit eigenem Budget. Der zweite Posten sind die proprietären Dienste. Jede Nutzung eines anbieterspezifischen Dienstes, von der serverlosen Funktion bis zur hauseigenen Datenbank, ist ein Stück Anwendung, das beim Wechsel neu gebaut werden muss. Das Gegenmittel sind offene Standards an den Stellen, wo sie wenig kosten: offene Datenformate, containerisierte Workloads, Infrastrukturdefinitionen in werkzeugneutraler Form.

Wichtig ist die Abwägung, kein Reflex. Verwaltete proprietäre Dienste sind oft die betriebswirtschaftlich richtige Wahl, weil sie Betriebsaufwand ersetzen. Die Entscheidung sollte nur bewusst fallen, mit dem Wechselpreis auf dem Tisch, statt sich aus Bequemlichkeit zu ergeben.

Für Unternehmen im europäischen Raum kommt eine regulatorische Entwicklung dazu: Der EU Data Act, anwendbar seit September 2025, verpflichtet Cloud-Anbieter, den Anbieterwechsel vertraglich und technisch zu erleichtern, und baut die Wechselentgelte stufenweise ab. Das senkt die künstlichen Hürden. Die strukturellen Kosten eines Wechsels, der Umbau proprietär gebauter Anwendungen, bleiben davon unberührt; sie entstehen weiterhin in den Architekturentscheidungen der Migration.

Was bewusst nicht migriert wird

Die letzte Entscheidung ist die am seltensten dokumentierte: welche Systeme nicht in die Cloud gehen. Ein Migrationsplan ohne Retire-Liste und ohne Retain-Liste ist unvollständig.

Retire zuerst: Vor dem Umzug ist der beste Moment, den ein Portfolio je bekommt, um Ballast abzuwerfen. Anwendungen, deren letzte fachliche Nutzung Jahre zurückliegt, Duplikate aus Zukäufen, Berichtssysteme, deren Empfänger das Unternehmen verlassen haben: Jedes abgeschaltete System ist eine Migration, die nichts kostet, und eine Cloud-Rechnung, die nie entsteht. Wer das Portfolio ungesiebt migriert, bezahlt den Umzug und danach den Betrieb von Systemen, die niemand vermisst hätte.

Retain ist die zweite Kategorie, und sie ist eine legitime Strategieentscheidung. Gründe gibt es mehrere: Systeme mit Lizenzmodellen, die in der Cloud unwirtschaftlich werden; Anwendungen, die an Maschinen oder Standorte gebunden sind und deren Latenzanforderungen gegen einen entfernten Betrieb sprechen; Bestände, deren Datenresidenz- oder Compliance-Anforderungen der gewählte Anbieter nicht abdeckt; Altsysteme, deren Ablösung ohnehin ansteht und für die sich ein Zwischenumzug nicht mehr lohnt. Entscheidend ist, dass der Verbleib begründet und festgehalten wird. Ein dokumentiertes Retain ist eine Architekturentscheidung, die beim nächsten Strategiezyklus überprüft werden kann. Ein stilles Retain ist ein vergessenes System, das in keiner Planung mehr auftaucht und in fünf Jahren als Überraschung wiederkehrt.

Am Ende steht damit fast immer ein hybrides Zielbild, in dem Cloud-Workloads und verbliebene Systeme nebeneinander betrieben werden. Auch das ist eine Konsequenz der frühen Entscheidungen: Netzanbindung, Identitätsmanagement und Monitoring müssen beide Welten abdecken, und zwar von der ersten Welle an.

Migrationsentscheidungen vor dem Start prüfen

DNA Solutions begleitet Unternehmen bei Cloud-Migrationen von der Portfolioanalyse bis zum Betrieb: Bestandsaufnahme und 6R-Einordnung pro System, Wellenplanung entlang der Abhängigkeiten, Aufbau des Betriebsmodells für die Zeit nach dem Cutover und Architekturentscheidungen mit offenem Blick auf die Exit-Kosten. Wenn Ihre Migration ansteht oder bereits läuft und die Entscheidungen dieses Artikels noch offen sind: Sprechen Sie uns an.