Anwendungsmigration in die Cloud: die sieben Wege und wann welcher passt

Eine Anwendungsmigration in die Cloud ist selten eine einzelne Entscheidung. Ein gewachsenes Portfolio umfasst Dutzende bis Hunderte Anwendungen, und für jede davon gibt es einen eigenen passenden Weg: Rehost, Replatform, Refactor, Repurchase, Retire, Retain oder Relocate. Dieser Artikel erklärt die sieben Wege konkret, ordnet sie nach Systemtyp ein und beschreibt die zwei Fehlgriffe, die Migrationsprogramme am zuverlässigsten aus der Spur bringen: alles zu rehosten oder alles zu refactoren.

Warum es sieben Wege gibt

Die Einteilung geht auf eine Gartner-Klassifikation von 2010 zurück, die fünf Migrationsstrategien unterschied. AWS hat sie später auf sieben erweitert, und diese Fassung hat sich als gemeinsames Vokabular durchgesetzt. Der Wert der Liste liegt weniger in den Begriffen selbst als in dem Denkmodell dahinter: Eine Migration ist eine Portfolio-Entscheidung. Wer für jede Anwendung denselben Weg wählt, hat die Entscheidung nicht getroffen, sondern übersprungen.

In der Praxis beginnt jede ernsthafte Migration deshalb mit einer Bestandsaufnahme. Welche Anwendungen existieren, wer nutzt sie, welche Abhängigkeiten haben sie untereinander, welche Lizenzen und welche Daten hängen daran. Diese Inventur ist unbequem, weil sie in gewachsenen Landschaften Wochen dauern kann und Dinge zutage fördert, die niemand mehr auf dem Schirm hatte. Sie ist trotzdem der Teil, an dem sich der Rest des Programms entscheidet: Erst auf dieser Grundlage lässt sich pro Anwendung ein Weg zuordnen, ein Aufwand schätzen und eine Reihenfolge planen. Die sieben Wege im Einzelnen.

Rehost: umziehen, wie es ist

Rehost, oft Lift-and-Shift genannt, verschiebt eine Anwendung unverändert in die Cloud. Die virtuelle Maschine, die im eigenen Rechenzentrum lief, läuft danach als Instanz beim Cloud-Anbieter. Am Code, an der Architektur und meist auch am Betriebssystem ändert sich nichts.

Der Vorteil ist Geschwindigkeit. Rehost ist der Weg mit dem geringsten Umbauaufwand pro Anwendung, er lässt sich weitgehend automatisieren und eignet sich für große Stückzahlen. Wenn ein Rechenzentrumsvertrag ausläuft oder Hardware am Ende ihres Lebenszyklus steht, ist Rehost oft der einzige Weg, der im Zeitfenster liegt.

Der Preis ist ebenso konkret: Die Anwendung nimmt alle ihre Eigenschaften mit, auch die schlechten. Eine überdimensionierte VM bleibt überdimensioniert, ein wartungsintensiver Betrieb bleibt wartungsintensiv. Cloud-Instanzen werden nach Verbrauch abgerechnet, und eine eins zu eins umgezogene Landschaft verbraucht in der Regel mehr, als sie müsste. Ohne anschließendes Rightsizing liegt die Cloud-Rechnung deshalb häufig über den bisherigen Betriebskosten. Rehost ist ein legitimer erster Schritt, aber kein Endzustand.

Passend für: Anwendungen mit begrenzter Restlebensdauer, Standardsoftware ohne Cloud-Version, große VM-Bestände unter Zeitdruck.

Replatform: gezielte Anpassungen beim Umzug

Replatform behält die Architektur der Anwendung bei, tauscht aber einzelne Komponenten gegen verwaltete Cloud-Dienste. Die selbst betriebene Datenbank wird zu einem Managed-Database-Dienst, der eigene Applikationsserver wandert in einen Container, der selbst gepflegte Load Balancer wird durch den des Anbieters ersetzt.

Das ist der Mittelweg: mehr Aufwand als Rehost, deutlich weniger als ein Umbau der Architektur. Der Gewinn liegt im Betrieb. Jede Komponente, die der Anbieter verwaltet, ist eine Komponente weniger, die das eigene Team patchen, sichern und überwachen muss. Gerade bei Datenbanken ist dieser Effekt groß, weil Backup, Replikation und Versionspflege dort viel Betriebszeit binden.

Die Grenze von Replatform: Strukturelle Probleme der Anwendung bleiben bestehen. Ein Monolith, der sich nicht horizontal skalieren lässt, kann auch auf einer verwalteten Plattform nicht horizontal skalieren. Wer mehr erwartet, braucht den nächsten Weg.

Passend für: Anwendungen, die noch Jahre laufen sollen und deren Betriebsaufwand heute zu hoch ist, insbesondere datenbanklastige Systeme.

Refactor: die Anwendung neu zuschneiden

Refactor, auch Rearchitect genannt, verändert die Anwendung selbst. Der Monolith wird in Dienste zerlegt, Zustandshaltung und Skalierung werden für die Cloud neu entworfen, Teile der Logik wandern in verwaltete Bausteine wie Warteschlangen, Funktionen oder Event-Plattformen.

Das ist der teuerste und riskanteste Weg, und der einzige, der die Eigenschaften der Anwendung grundlegend verbessert: elastische Skalierung, unabhängige Deployments, kürzere Release-Zyklen. Genau deshalb ist die Auswahl entscheidend. Refactor lohnt sich für die Systeme, mit denen sich das Unternehmen im Markt unterscheidet und deren Weiterentwicklung an der bestehenden Architektur scheitert. Für ein internes Verwaltungssystem, das seit Jahren stabil dieselbe Aufgabe erfüllt, lohnt es sich fast nie.

Ein Refactoring muss außerdem kein Big-Bang sein. Bewährt hat sich das schrittweise Herauslösen: Neue Funktionalität entsteht als eigenständiger Dienst neben dem Altsystem, das über eine saubere Übersetzungsschicht angebunden bleibt und Stück für Stück schrumpft. Wie dieser Weg im Detail aussieht, beschreibt unser Artikel über die Ablösung von Altsystemen ohne Big-Bang.

Passend für: geschäftskritische Eigenentwicklungen mit hohem Änderungsbedarf oder Skalierungsproblemen.

Repurchase: durch Standardsoftware ersetzen

Repurchase ersetzt eine selbst betriebene oder selbst entwickelte Anwendung durch ein SaaS-Produkt. Das selbst gehostete CRM wird zu einem Cloud-CRM, die Eigenentwicklung für Personalprozesse zu einer HR-Suite, der lokal installierte E-Mail-Server zu einem Cloud-Dienst.

Technisch ist das oft die einfachste Migration, weil keine eigene Anwendung umgebaut wird. Der Aufwand liegt woanders: in der Datenübernahme und in der Prozessanpassung. Ein SaaS-Produkt bildet Standardprozesse ab. Jede Sonderlocke, die über Jahre in die Eigenentwicklung gewachsen ist, muss entweder über Konfiguration nachgebaut werden oder entfallen. Das ist häufig gesund, weil viele dieser Sonderfälle ihren Grund verloren haben, aber es ist eine organisatorische Arbeit, die im Projektplan stehen muss.

Passend für: Anwendungen ohne differenzierenden Charakter, für die ein etablierter SaaS-Markt existiert, typischerweise CRM, HR, Kollaboration, Buchhaltung. Umgekehrt gilt: Wo die Anwendung den eigenen Prozess trägt und kein Standardprodukt ihn abbildet, bleibt die Individualsoftware-Entwicklung der tragfähigere Weg.

Retire: abschalten

Retire ist der Weg, der in Migrationsplänen am seltensten vorkommt und am meisten spart. Jede Bestandsaufnahme eines gewachsenen Portfolios fördert Anwendungen zutage, die niemand mehr nutzt: das Reporting-Tool, dessen Empfängerkreis das Unternehmen verlassen hat, die Parallel-Anwendung aus einem abgebrochenen Projekt, die Systemkopie, die nach einem Test nie abgebaut wurde.

Diese Anwendungen zu migrieren wäre reine Verschwendung. Sie werden dokumentiert, ihre Daten werden nach Aufbewahrungspflicht archiviert, dann werden sie abgeschaltet. Jede stillgelegte Anwendung reduziert nicht nur Migrationsaufwand, sondern dauerhaft Betriebskosten, Lizenzkosten und Angriffsfläche.

Passend für: alles, was die Bestandsaufnahme als ungenutzt oder redundant ausweist. Die Disziplin liegt darin, diese Frage für jede Anwendung ernsthaft zu stellen.

Retain: bewusst dort lassen

Retain bedeutet, eine Anwendung vorerst nicht zu migrieren. Das ist kein Scheitern, sondern in bestimmten Fällen die richtige Entscheidung:

• Latenz und Nähe: Systeme, die direkt an Maschinen, Produktionsanlagen oder lokale Messtechnik gekoppelt sind, gehören oft physisch in deren Nähe.
• Lizenzmodelle: Manche Altsoftware ist so lizenziert, dass der Betrieb in der Cloud unwirtschaftlich oder vertraglich ausgeschlossen ist.
• Regulatorik und Datenresidenz: Im DACH-Raum gibt es Datenbestände, deren Verarbeitungsort vertraglich oder regulatorisch festgelegt ist. Das lässt sich in der Cloud meist abbilden, aber wenn die Prüfung dafür noch aussteht, ist Retain die sauberere Zwischenlösung als eine Migration mit offenen Compliance-Fragen.
• Kurze Restlaufzeit: Eine Anwendung, deren Ablösung ohnehin beschlossen ist, migriert man nicht mehr.

Wichtig ist, dass Retain eine dokumentierte Entscheidung mit Wiedervorlage bleibt. Eine Anwendung, die ohne Begründung im alten Rechenzentrum stehen bleibt, ist kein Retain, sondern ein blinder Fleck.

Passend für: Systeme mit harten Standortgründen, ungeklärten Compliance-Fragen oder kurzer Restlaufzeit.

Relocate: die Umgebung als Ganzes verschieben

Relocate verschiebt nicht einzelne Anwendungen, sondern eine komplette Virtualisierungsumgebung auf die Infrastruktur eines Cloud-Anbieters. Das bekannteste Beispiel ist der Umzug einer VMware-Landschaft auf ein VMware-Angebot in der Cloud: Die VMs laufen danach unverändert weiter, samt bestehender Werkzeuge, Netzkonfiguration und Betriebsprozesse.

Der Reiz liegt im Tempo. Große VM-Bestände lassen sich auf diesem Weg schneller bewegen als mit jeder anderen Methode, weil weder Anwendungen noch Betriebsabläufe angefasst werden. Dafür bleibt der Nutzen begrenzt: Man betreibt dieselbe Umgebung auf gemieteter statt eigener Hardware, mit denselben Lizenzkosten für die Virtualisierungsschicht. Relocate ist deshalb vor allem ein Zwischenschritt, etwa wenn ein Rechenzentrum zu einem festen Termin geräumt werden muss und die eigentliche Modernisierung erst danach beginnt.

Passend für: große virtualisierte Bestände unter hartem Termindruck, als erste Etappe vor Replatform oder Refactor.

Entscheidungskriterien pro Systemtyp

Die Zuordnung folgt in der Praxis wiederkehrenden Mustern:

• Standardsoftware mit SaaS-Alternative: Repurchase prüfen, bevor über einen Umzug nachgedacht wird.
• Standardsoftware ohne Cloud-Version: Rehost, solange der Hersteller den Betrieb auf Cloud-Instanzen unterstützt, sonst Retain.
• Stabile Eigenentwicklungen mit wenig Änderungsbedarf: Rehost oder Replatform. Der Umbau einer Anwendung, die niemand mehr ändern muss, hat keinen Business Case.
• Geschäftskritische Eigenentwicklungen mit hohem Änderungsbedarf: Refactor, schrittweise und mit sauberer Entkopplung vom Altbestand.
• Datenbanklastige Systeme: Replatform auf verwaltete Datenbankdienste, weil dort der größte Betriebsgewinn liegt.
• Ungenutzte und redundante Anwendungen: Retire, konsequent und früh im Programm, damit sie in keiner Migrationswelle mehr auftauchen.
• Systeme mit Standort- oder Compliance-Bindung: Retain mit dokumentierter Begründung und Wiedervorlagetermin.

Quer zu diesen Mustern liegt die Frage der Reihenfolge. Bewährt hat sich, mit unkritischen Anwendungen zu beginnen, um Werkzeuge, Netzanbindung und Betriebsprozesse zu erproben, und die geschäftskritischen Systeme erst zu bewegen, wenn der Migrationspfad eingespielt ist.

Die zwei typischen Fehlgriffe

Alles rehosten. Der häufigste Fehler entsteht aus Termindruck: Das gesamte Portfolio wird per Lift-and-Shift verschoben, die Optimierung auf später vertagt, und dieses Später kommt nicht. Das Ergebnis ist das alte Rechenzentrum auf fremder Hardware, mit einer monatlichen Rechnung, die über den früheren Kosten liegt, und ohne einen der Vorteile, für die die Migration begründet wurde. Wenn Rehost aus Zeitgründen der richtige erste Schritt ist, gehört die anschließende Optimierungswelle mit Budget und Termin in denselben Beschluss.

Alles refactoren. Der Gegenfehler entsteht aus Anspruch: Jede Anwendung soll cloud-native werden. Das Programm wächst auf Jahre an, bindet die besten Leute, und der Business Case stirbt an der Laufzeit, weil der Nutzen erst am Ende ankommt. Refactoring ist ein knappes Gut und gehört ausschließlich in die Systeme, deren Umbau messbaren Geschäftswert hat.

Beiden Fehlgriffen liegt dasselbe Muster zugrunde: eine Pauschalentscheidung, wo eine Portfolio-Entscheidung nötig gewesen wäre. Die sieben Wege sind genau das Werkzeug, um diese Pauschalisierung zu vermeiden.

Anwendungsmigration mit DNA Solutions planen

DNA Solutions begleitet Unternehmen im DACH-Raum bei der Anwendungsmigration in die Cloud: von der Bestandsaufnahme des Portfolios über die Zuordnung der Migrationswege pro Anwendung bis zur Planung und Umsetzung der Migrationswellen. Wo Altsysteme den Takt vorgeben, greift dieselbe Arbeit in die Legacy-Modernisierung über. Wir wählen den Weg nach Kritikalität, Restlebensdauer und Änderungsbedarf des einzelnen Systems und halten die Optimierung nach dem Umzug im selben Plan fest wie den Umzug selbst. Wenn Sie vor einer Migration stehen oder eine begonnene Migration neu ordnen wollen: Sprechen Sie uns an.