Lift-and-Shift ist nicht gleich Lift-and-Shift

Zwei Wege in die Google Cloud

Cloud-Migrationen werden häufig unter einem gemeinsamen Begriff zusammengefasst: Lift-and-Shift.

In der Praxis zeigt sich jedoch schnell, dass sich dahinter sehr unterschiedliche Vorgehensweisen verbergen können. Denn nicht jedes System bietet dieselben Voraussetzungen, nicht jede Ausgangslage erlaubt denselben Modernisierungsgrad, und nicht jedes Projekt verfolgt identische Ziele.

In zwei Cloud-Migrationsprojekten, die wir begleitet haben, war der grundlegende Ansatz zwar derselbe: Bestehende Systeme sollten in die Google Cloud Platform (GCP) überführt werden. Die konkrete Umsetzung unterschied sich jedoch deutlich. Während in einem Projekt ein hoher Shift-Anteil möglich war, stand im anderen die stabile und planbare Migration einer über Jahre gewachsenen Systemlandschaft im Vordergrund.

Beide Projekte machen deutlich: Erfolgreiche Cloud-Migration bedeutet nicht, ein festes Schema anzuwenden. Entscheidend ist, den passenden Ansatz für die jeweilige technische und organisatorische Realität zu wählen.

Projekt 1: Vom bisherigen IaaS-Anbieter in eine moderne GCP-Zielarchitektur

Ausgangssituation

Im ersten Projekt sollte ein bestehender IaaS-Anbieter abgelöst und die Anwendung in die Google Cloud migriert werden. Ziel war es, den Übergang möglichst reibungslos zu gestalten, Risiken für den laufenden Betrieb zu minimieren und gleichzeitig die Chance zu nutzen, die Zielarchitektur wirtschaftlicher und zukunftsfähiger aufzustellen.

Unser Vorgehen

Obwohl das Projekt formal einem Lift-and-Shift-Ansatz folgte, war schnell erkennbar, dass ein reines 1:1-Verschieben der bestehenden Strukturen nicht den größtmöglichen Nutzen bringen würde. Deshalb haben wir den Migrationsansatz bewusst um einen starken Shift-Anteil ergänzt.

Ein zentraler Schritt war die Aufteilung eines Deployment-Monolithen in einzelne Services. Dadurch konnte die Anwendung modularer betrieben, aktualisiert und perspektivisch besser skaliert werden. Im nächsten Schritt wurden die Services in Containern paketiert, um eine konsistente und portable Betriebsgrundlage für die Cloud zu schaffen.

Darauf aufbauend wurde die Zielarchitektur konsequent auf Managed Services über alle Schichten hinweg ausgerichtet. Statt das bestehende Betriebsmodell unverändert in die Cloud zu übertragen, wurden geeignete Cloud-Services für WebApp, Service-Layer, Datenbank und File Storage genutzt. Genau dieser hohe Shift-Anteil war der eigentliche Hebel des Projekts: Die Anwendung wurde nicht nur migriert, sondern zugleich in ein deutlich effizienteres Betriebsmodell überführt.

Das Ergebnis

Die Migration konnte ohne wahrnehmbaren Ausfall umgesetzt werden. Für die Endanwender verlief der Übergang praktisch lautlos – ein wesentlicher Erfolgsfaktor bei produktionskritischen Systemen.

Darüber hinaus brachte die neue Zielarchitektur einen klaren wirtschaftlichen Effekt: Die Betriebskosten konnten um rund 50 Prozent reduziert werden. Das Projekt zeigt, wie wirkungsvoll Lift-and-Shift sein kann, wenn eine Migration gezielt mit Architektur- und Betriebsoptimierungen verbunden wird.

Projekt 2: Migration aus dem Rechenzentrumsbetrieb in die GCP

Ausgangssituation

Im zweiten Projekt ging es um die Überführung einer bestehenden Anwendung aus einem Rechenzentrumsbetrieb in die GCP. Die Systemlandschaft war über einen langen Zeitraum gewachsen und brachte entsprechend hohe technische Schulden mit sich. Zudem basierte die Lösung in Teilen auf veralteten Technologie- und Software-Versionen. Dadurch war die Migration technisch anspruchsvoll, zugleich war ein verlässlicher und planbarer Übergang in die Cloud das zentrale Ziel.

Unser Vorgehen

Unter diesen Rahmenbedingungen bestand keine realistische Möglichkeit, das System bereits während der Migration umfassend zu modernisieren. Der Schwerpunkt lag daher bewusst stärker auf dem Lift als auf dem Shift.

Konkret bedeutete das, dass große Teile der bestehenden Anwendung zunächst möglichst nah am Bestand in der GCP auf IaaS-Basis weiterbetrieben wurden. Dort, wo es sinnvoll und mit vertretbarem Aufwand möglich war, haben wir jedoch gezielt Managed Services eingesetzt – insbesondere für File Storage und Datenbank. So ließ sich der operative Aufwand reduzieren, ohne die Migration selbst unnötig zu verkomplizieren oder zusätzliche Risiken einzuführen.

Dieses Vorgehen war eine bewusste Abwägung: so viel Veränderung wie sinnvoll, aber nicht mehr als für eine sichere und fristgerechte Migration vertretbar war.

Das Ergebnis

Die Software konnte fristgerecht migriert werden. Damit wurde das zentrale Projektziel erreicht: ein kontrollierter und verlässlicher Übergang in die Cloud.

Gleichzeitig wurde eine tragfähige Grundlage für die zukünftige Weiterentwicklung geschaffen. Auch wenn eine unmittelbare Kostenersparnis gegenüber dem bisherigen Rechenzentrumsbetrieb nur begrenzt realisiert werden konnte, eröffnet die neue Umgebung heute deutlich bessere Möglichkeiten für die schrittweise Modernisierung des Systems.

Gerade bei gewachsenen Anwendungslandschaften liegt der Mehrwert einer Migration nicht immer in kurzfristigen Einsparungen. Häufig entsteht der eigentliche Nutzen dadurch, dass technische Abhängigkeiten reduziert und neue Entwicklungsperspektiven geschaffen werden.

Was beide Projekte zeigen

Beide Vorhaben wurden unter dem Begriff Lift-and-Shift umgesetzt – und dennoch hätten die Vorgehensweisen unterschiedlicher kaum sein können.

Im ersten Projekt war genügend Spielraum vorhanden, um die Zielarchitektur gezielt weiterzuentwickeln und konsequent auf Managed Services zu setzen. Das Ergebnis war eine nahezu unsichtbare Migration mit deutlicher Kostensenkung.

Im zweiten Projekt standen andere Rahmenbedingungen im Vordergrund. Hier bestand die eigentliche Leistung darin, eine anspruchsvolle Ausgangssituation sicher in die Cloud zu überführen, ohne das Vorhaben durch parallele Modernisierungsschritte unnötig zu belasten. Der unmittelbare Nutzen lag weniger in sinkenden Infrastrukturkosten als in einer belastbaren Basis für die nächsten Entwicklungsschritte.

Fazit

Lift-and-Shift ist kein Standardrezept, sondern ein strategischer Rahmen. Wie viel Lift und wie viel Shift sinnvoll ist, hängt immer von der Ausgangslage ab: von Architektur, technischer Reife, Zeitrahmen, Betriebsanforderungen und Projektrisiken.

Erfolgreich ist eine Cloud-Migration nicht dann, wenn möglichst viel oder möglichst wenig verändert wird. Erfolgreich ist sie dann, wenn sie zur Realität des Systems passt, Risiken beherrschbar hält und den größtmöglichen Nutzen für das Unternehmen schafft – sei es durch geringere Betriebskosten, einen stabileren Betrieb oder neue Spielräume für die Weiterentwicklung.

Jetzt teilen: