Wenn Unternehmen ihre IT in die Cloud verlagern wollen, steht oft eine Frage im Raum: Wie schnell können wir das schaffen? Der Druck ist verständlich – alte Hardware wird teurer, Rechenzentren müssen erneuert werden, und der Wettbewerb ist längst digital unterwegs. In dieser Situation wirkt Lift and Shift wie die perfekte Lösung: Man nimmt die bestehenden Systeme, wie sie sind, und hebt sie einfach in die Cloud. Kein Umbau, keine Neuarchitektur, kein monatelanges Projekt.

Doch dieser vermeintlich einfache Weg hat seine Tücken. Denn was auf den ersten Blick wie eine pragmatische Abkürzung aussieht, kann sich langfristig als teure Sackgasse entpuppen.

“Ein schneller Umzug ist nicht automatisch ein Fortschritt.”

Die zentrale These dieses Artikels lautet: Lift and Shift kann ein sinnvoller erster Schritt sein – aber nur, wenn man sich bewusst ist, dass es keine Lösung ist, sondern ein Übergangszustand. Wer ohne klare Folgestrategie in die Cloud zieht, riskiert, die alten Probleme mitzunehmen und neue hinzuzufügen.

Das Grundprinzip: Was Lift and Shift bedeutet

Lift and Shift beschreibt eine Migrationsstrategie, bei der bestehende Anwendungen und Systeme ohne strukturelle Anpassungen in eine Cloud-Umgebung übertragen werden. Technisch gesprochen: Man nimmt die virtuellen Maschinen oder physischen Server, die bisher im eigenen Rechenzentrum liefen, und repliziert sie 1 in der Cloud – etwa als Azure VM oder AWS EC2-Instanz.

Ein klassisches Beispiel: Ein Unternehmen betreibt seit Jahren eine ERP-Software auf einem lokalen Windows-Server. Dieser Server wird nun als virtuelle Maschine in Microsoft Azure hochgeladen. Die Software selbst bleibt unverändert, die Datenbank läuft weiter wie bisher, und auch die Netzwerkstruktur wird so gut wie möglich nachgebildet.

Das Ziel ist klar: Man will schnell in die Cloud einsteigen, ohne die bestehende Infrastruktur grundlegend umbauen zu müssen. Für viele Unternehmen ist das der erste Schritt, um überhaupt Cloud-Erfahrung zu sammeln, ohne sich sofort in komplexe Architekturprojekte zu stürzen.

Stärken des Lift-and-Shift-Ansatzes

Es wäre unfair, Lift and Shift pauschal zu verurteilen. In bestimmten Szenarien kann dieser Ansatz durchaus sinnvoll sein – vor allem, wenn es um Geschwindigkeit und Risikominimierung geht.

Schnelle Migration mit geringer Anfangskomplexität
Der größte Vorteil liegt auf der Hand: Man kann innerhalb weniger Wochen oder sogar Tage operative Systeme in die Cloud verlagern. Für Unternehmen unter Zeitdruck – etwa wenn ein Rechenzentrumsvertrag ausläuft oder Hardware veraltet ist – kann das entscheidend sein.

Bestehende Prozesse bleiben unverändert
Da die Anwendungen nicht angepasst werden müssen, bleiben auch die Arbeitsabläufe der Mitarbeiter identisch. Es gibt keine Schulungen, keine Umgewöhnung, keine Angst vor Betriebsunterbrechungen. Das System läuft einfach weiter – nur eben woanders.

Erste Cloud-Erfahrungen ohne Technologiewechsel
Für Teams, die noch nie mit Cloud-Infrastruktur gearbeitet haben, bietet Lift and Shift einen sanften Einstieg. Man lernt, wie Cloud-Provider funktionieren, wie man Ressourcen verwaltet und Kosten überwacht – ohne sich gleichzeitig mit Microservices, Containerisierung oder Serverless-Architekturen auseinandersetzen zu müssen.

In dieser Hinsicht ist Lift and Shift weniger eine Strategie als ein Lernfeld: Man verschafft sich Zeit, um zu verstehen, was Cloud wirklich bedeutet.

Schwächen und versteckte Kosten

Doch genau hier beginnt das Problem. Denn was als Übergangslösung gedacht war, wird in der Praxis oft zum Dauerzustand. Und das hat Konsequenzen – vor allem finanzielle.

Dauerhafte Cloud-Serverkosten können massiv ansteigen
On-Premise-Server kosten Geld in der Anschaffung, aber danach vor allem Strom, Wartung und gelegentliche Hardware-Upgrades. Cloud-Server hingegen werden nach Nutzung abgerechnet – Stunde für Stunde, CPU für CPU, Speicher für Speicher. Was im ersten Monat noch überschaubar wirkt, kann sich über Jahre zu einem erheblichen Kostenfaktor entwickeln.

Besonders tückisch: Viele Unternehmen überdimensionieren ihre Cloud-Instanzen, weil sie nicht genau wissen, wie viel Rechenleistung sie wirklich brauchen. Ein Server, der lokal mit 16 GB RAM lief, wird „zur Sicherheit” in der Cloud mit 32 GB provisioniert – und läuft dann mit 20 Prozent Auslastung. Das summiert sich.

Fehlende Nutzung von Cloud-Native-Vorteilen
Die Cloud bietet enorme Möglichkeiten: automatische Skalierung bei Lastspitzen, serverlose Architekturen für ereignisgesteuerte Prozesse, verwaltete Datenbanken ohne Wartungsaufwand. Doch wer Lift and Shift betreibt, nutzt nichts davon. Man zahlt Cloud-Preise, arbeitet aber wie im eigenen Rechenzentrum.

Das ist, als würde man einen Sportwagen kaufen und ihn nur im ersten Gang fahren. Technisch funktioniert es – aber man verschenkt das Potenzial.

Technische Schulden bleiben erhalten
Jedes gewachsene System hat seine Altlasten: veraltete Software-Versionen, proprietäre Abhängigkeiten, monolithische Architekturen, die schwer zu warten sind. Lift and Shift löst keines dieser Probleme – es verlagert sie nur an einen anderen Ort. Die technische Schuld wächst weiter, nur dass man sie jetzt in der Cloud mit sich herumträgt.

Sicherheit, Wartung und Updates bleiben komplex
Auch wenn die Infrastruktur in der Cloud liegt, bleibt die Verantwortung für Betriebssystem-Updates, Sicherheitspatches und Backup-Strategien beim Unternehmen. Cloud-Provider übernehmen diese Aufgaben nur bei verwalteten Diensten – nicht bei einfachen virtuellen Maschinen. Das bedeutet: Der Administrationsaufwand sinkt nicht, er verändert nur seine Form.

Hinzu kommt ein oft unterschätztes Risiko: Wer seine On-Premise-Sicherheitskonzepte einfach in die Cloud überträgt, übersieht, dass die Bedrohungslandschaft dort eine andere ist. Netzwerksegmentierung, Identitätsmanagement und Zugriffskontrollen funktionieren in der Cloud nach anderen Regeln – und wer das ignoriert, öffnet ungewollt Sicherheitslücken.

---

Dieser Artikel ist der Auftakt zu einer Serie über Cloud-Migration. In den kommenden Teilen werden wir konkrete Szenarien durchspielen: Wann lohnt sich Lift and Shift trotzdem? Welche Alternativen gibt es? Und wie plant man eine Migration, die nicht nur schnell, sondern auch nachhaltig ist?

Denn die entscheidende Frage lautet nicht, ob man in die Cloud geht – sondern wie.