Cloud-Migration für Legacy-Software: Lift & Shift vs. Modernize

Der Hosting-Vertrag läuft aus. Der alte Server im Keller wird nicht mehr gewartet. Oder die Geschäftsführung hat entschieden: Wir gehen in die Cloud. Die Entscheidung ist meist der leichte Teil. Schwierig wird es bei der Anwendung, die seit zwölf Jahren läuft und die niemand mehr richtig kennt.

Für die Cloud Migration von Legacy-Software gibt es zwei grundlegende Wege. Lift & Shift nimmt die Anwendung, wie sie ist, und stellt sie auf Cloud-Server. Modernize passt die Architektur an die Cloud an. Beide Wege funktionieren. Beide haben Fallen, die in Angeboten meist fehlen.

Dieser Artikel erklärt, wann welcher Weg passt. Und woran solche Projekte in der Praxis scheitern.

Was die beiden Begriffe bedeuten

Lift & Shift heißt übersetzt "anheben und verschieben". Ihre Anwendung läuft auf einem physischen Server oder einer virtuellen Maschine. Sie kopieren das System eins zu eins auf eine virtuelle Maschine beim Cloud-Anbieter. Der Code bleibt unverändert. Die Datenbank bleibt unverändert. Nur der Standort ändert sich. In der Fachsprache heißt dieser Weg auch "Rehosting".

Modernize, oft "Cloud-native Modernisierung" genannt, geht weiter. Die Anwendung wird umgebaut, damit sie die Bausteine der Cloud nutzt. Statt einer eigenen Datenbank auf dem Server nutzen Sie einen verwalteten Datenbankdienst. Statt einer großen Anwendung laufen mehrere kleinere Dienste in Containern. Statt fester Serverkapazität skaliert das System nach Bedarf.

Zwischen den beiden Polen gibt es Zwischenstufen. Das sogenannte Replatforming ändert die Anwendung nur punktuell, etwa durch den Wechsel auf eine verwaltete Datenbank. Die Details der einzelnen Migrationstypen beschreibt unser Artikel zu Anwendungsmigration: Typen, Phasen und Fallstricke.

Was passiert, wenn Sie den falschen Weg wählen

Der häufigste Fehler ist nicht die Wahl zwischen den beiden Wegen. Der häufigste Fehler ist, gar nicht bewusst zu wählen.

Wer ohne Analyse per Lift & Shift migriert, bekommt am Monatsende oft eine Überraschung. Der alte Server hat 200 Euro im Monat gekostet. Die gleichwertige Cloud-Maschine kostet 600 Euro. Dazu kommen Kosten für ausgehenden Datenverkehr, Backups und Speicher. Die Cloud ist bei unveränderten Anwendungen selten günstiger als ein gut ausgelasteter eigener Server. Sie ist flexibler. Das ist ein Unterschied.

Wer ohne Analyse in ein Modernize-Projekt startet, riskiert das Gegenteil. Das Projekt war für sechs Monate geplant. Nach zwölf Monaten läuft das alte System noch immer, und das neue ist halb fertig. Beide müssen gepflegt werden. Die Kosten laufen doppelt. Wir sehen das regelmäßig bei Legacy Software, deren Abhängigkeiten niemand vollständig dokumentiert hat.

Ein weiterer Punkt betrifft die Sicherheit. Eine Anwendung mit veralteter PHP-Version oder ungepatchtem Betriebssystem wird in der Cloud nicht sicherer. Sie ist nur an einem anderen Ort unsicher. Manche Cloud-Anbieter machen die Konfiguration sogar komplizierter. Ein falsch gesetztes Zugriffsrecht auf einem Speicherdienst reicht, und Kundendaten liegen öffentlich im Netz.

Wann Lift & Shift der richtige Weg ist

Lift & Shift passt, wenn der Zeitdruck echt ist. Das Rechenzentrum schließt in drei Monaten. Der Hoster kündigt den Vertrag. In solchen Fällen ist der schnelle Umzug richtig. Sie gewinnen Zeit und können später in Ruhe entscheiden, was aus der Anwendung wird.

Der Weg passt auch, wenn die Anwendung stabil läuft und sich wenig ändert. Ein internes Warenwirtschaftssystem mit 30 Nutzern braucht keine automatische Skalierung. Es braucht einen zuverlässigen Server und regelmäßige Backups. Beides bekommen Sie in der Cloud ohne Umbau.

Und der Weg passt, wenn Sie das System noch nicht gut genug kennen. Das klingt paradox. Aber ein Umbau setzt voraus, dass jemand die Anwendung versteht. Fehlt dieses Wissen, ist der unveränderte Umzug der geringere Schaden. Die Analyse kommt danach.

Die Fallen bei Lift & Shift

Die erste Falle sind versteckte Abhängigkeiten. Die Anwendung greift auf einen Netzlaufwerk-Pfad zu, den es in der Cloud nicht gibt. Ein Cronjob auf einem anderen Server ruft nachts eine Schnittstelle auf. Ein Drucker im Lager hängt an einer festen IP-Adresse. Solche Dinge stehen in keiner Dokumentation. Sie fallen am Tag nach der Migration auf.

Die zweite Falle ist die Lizenz. Manche Datenbanken und Betriebssysteme dürfen nicht ohne weiteres in der Cloud betrieben werden. Oder die Lizenz wird pro Prozessorkern berechnet, und die Cloud-Maschine hat mehr Kerne als der alte Server.

Die dritte Falle ist die Latenz. Wenn Ihre Anwendung mit Systemen im Büro spricht, etwa mit einer Telefonanlage oder einer Maschinensteuerung, wird jeder Aufruf langsamer. Was auf dem Server im Nebenraum eine Millisekunde dauerte, dauert jetzt zwanzig. Bei tausend Aufrufen pro Vorgang merkt das jeder Nutzer.

Wann Modernize der richtige Weg ist

Modernize lohnt sich, wenn die Anwendung über den Standort hinaus ein Geschäftsproblem hat. Sie ist zu langsam bei vielen gleichzeitigen Nutzern. Jede Änderung dauert Wochen, weil alles mit allem verwoben ist. Deployments sind riskant und passieren deshalb nur nachts am Wochenende.

Der Weg lohnt sich auch, wenn die Last stark schwankt. Ein Shop mit dem zehnfachen Umsatz im Dezember bezahlt mit einer festen Maschine elf Monate lang für Kapazität, die er nicht braucht. Eine Anwendung, die nach Bedarf skaliert, kostet im Januar einen Bruchteil.

Und er lohnt sich, wenn ohnehin größere Änderungen anstehen. Ein Sprachwechsel, ein Framework-Upgrade, eine neue Schnittstelle für einen Großkunden. Wer die Anwendung sowieso anfasst, kann die Cloud-Anpassungen im selben Zug erledigen.

Die Fallen bei Modernize

Die größte Falle heißt Vollständigkeit. Das Team will alles auf einmal richtig machen: Microservices, Kubernetes, automatische Tests, neue Datenbank. Das Ergebnis ist ein Projekt ohne Zwischenstand. Nach einem Jahr gibt es nichts, was man produktiv nehmen könnte.

Die zweite Falle ist die Herstellerbindung. Wer die Anwendung eng an die Dienste eines Anbieters koppelt, etwa an dessen Warteschlangen oder Funktionsdienste, kommt dort schwer wieder weg. Sie können diese Dienste trotzdem nutzen. Wichtig ist, dass Sie die Kopplung bewusst wählen und dokumentieren.

Die dritte Falle ist das Team. Cloud-native Architekturen brauchen anderes Wissen als ein klassischer Serverbetrieb. Wer nach dem Umbau niemanden hat, der Container, Netzwerkrichtlinien und Monitoring versteht, hat ein modernes System ohne Betreuung. Das ist schlechter als ein altes System mit Betreuung.

Der Mittelweg, der in der Praxis meistens gewinnt

Die meisten Legacy-Anwendungen, die wir betreuen, gehen weder den einen noch den anderen Weg in Reinform. Sie gehen in Etappen.

Etappe eins ist der Umzug mit minimalen Änderungen. Die Anwendung kommt in einen Container, die Datenbank wird auf einen verwalteten Dienst umgestellt. Der Code bleibt weitgehend unverändert. Wie das konkret aussieht, zeigt unser Beitrag zur Container-Migration für Legacy-Anwendungen. Dieser Schritt dauert in der Regel wenige Wochen. Danach läuft das System in der Cloud, und die Kündigungsfrist des alten Hosters ist kein Thema mehr.

Etappe zwei ist die Analyse im laufenden Betrieb. Jetzt sehen Sie echte Zahlen: Welche Teile der Anwendung verursachen Last? Wo entstehen die Kosten? Welche Funktionen nutzt überhaupt noch jemand? Diese Daten hatten Sie auf dem alten Server nicht.

Etappe drei ist der gezielte Umbau. Der Teil der Anwendung, der Last verursacht, wird herausgelöst und skalierbar gemacht. Der Rest bleibt, wie er ist. Das ist die Cloud-Modernisierung, die tatsächlich Geld spart, weil sie nur dort ansetzt, wo es sich rechnet.

Dieser Ablauf passt in die größere Frage, welche Strategie für Ihr System überhaupt sinnvoll ist. Einen Überblick über die Optionen gibt unser Artikel Software modernisieren: Wege und Strategien. Und wer sich fragt, ob die Cloud überhaupt der richtige Ort ist, findet im Vergleich Managed Hosting vs. eigener Server eine ehrliche Gegenüberstellung.

Was Sie vor dem Start klären sollten

Drei Fragen entscheiden über den Weg. Wie viel Zeit haben Sie wirklich? Ein hartes Datum spricht für Lift & Shift als ersten Schritt. Was soll die Migration lösen? Ein Standortproblem braucht einen Umzug, ein Architekturproblem braucht einen Umbau. Und wer kennt das System? Ohne dieses Wissen ist jeder Umbau ein Blindflug.

Dazu kommt eine ehrliche Bestandsaufnahme. Welche Systeme sprechen mit der Anwendung? Welche Lizenzen sind betroffen? Welche Daten dürfen aus rechtlichen Gründen nur in bestimmten Regionen liegen? Bei personenbezogenen Daten entscheidet die DSGVO über die Wahl der Cloud-Region, nicht die Technik.

Fazit

Die Cloud Migration von Legacy-Software ist kein Selbstzweck. Lift & Shift ist schnell und sicher planbar, spart aber selten Geld und behebt keine Altlasten. Modernize behebt Altlasten, kostet aber Zeit und setzt voraus, dass jemand das System versteht. In der Praxis funktioniert meist der Weg in Etappen: erst umziehen, dann messen, dann gezielt umbauen.

Wir helfen bei allen drei Etappen. Wir schauen zuerst, was sich in Ihrer Anwendung über die Jahre angesammelt hat, und legen dann den Weg fest. Unsere Leistung Migration von Legacy-Systemen beschreibt, wie wir dabei vorgehen.

Sprechen Sie uns an. Das Erstgespräch ist kostenlos.