In den ersten beiden Teilen dieser Serie haben wir die Mechanik von Lift and Shift analysiert und einen wirtschaftlichen Vergleich mit cloud-nativen Ansätzen gezogen. Doch es gibt Anwendungsfälle, bei denen die Entscheidung komplexer wird – nicht nur aus technischen oder finanziellen Gründen, sondern wegen regulatorischer Anforderungen, Compliance-Vorgaben oder strategischer Unsicherheiten.

In diesem abschließenden Teil schauen wir uns einen besonders heiklen Bereich an: Steuer-, Dokumenten- und Datenmanagementsysteme. Außerdem klären wir die zentrale Frage: Ist Lift and Shift eine Übergangslösung – oder eine Sackgasse?

“Das Dach ist modern, aber die Leitungen sind dieselben.”

Sonderfall: Steuer-, Dokumenten- und Datenmanagementsysteme

Nicht jede Anwendung lässt sich einfach in die Cloud heben. Besonders kritisch wird es bei Systemen, die unter strengen rechtlichen und regulatorischen Anforderungen stehen: Steuerarchive, Dokumentenmanagementsysteme (DMS), GoBD-konforme Buchhaltungssoftware oder langfristige Datenhaltung mit revisionssicherer Archivierung.

Warum diese Systeme besonders sind

Diese Anwendungen müssen nicht nur funktionieren – sie müssen nachweisbar, unveränderbar und langfristig verfügbar sein. Dazu kommen Anforderungen wie:

• Audit-Trails: Jede Änderung, jeder Zugriff, jede Löschung muss protokolliert und nachvollziehbar sein.
• Data Residency: Daten dürfen oft nicht in beliebigen Rechenzentren gespeichert werden, sondern müssen physisch in Deutschland oder der EU liegen.
• Versionierung und Unveränderlichkeit: Dokumente müssen in ihrer ursprünglichen Form erhalten bleiben – keine nachträglichen Änderungen, keine Komprimierung, keine Formatumwandlungen.
• Langzeitarchivierung: Manche Dokumente müssen zehn Jahre oder länger vorgehalten werden – und zwar so, dass sie auch in Zukunft lesbar bleiben.

Warum Lift and Shift hier oft scheitert

Wenn man ein solches System einfach auf eine Azure-VM oder AWS-EC2-Instanz hebt, bleiben all diese Anforderungen bestehen – aber man verliert die Kontrollmöglichkeiten, die man lokal hatte.

Ein Beispiel: Ein Steuerarchiv lag bisher auf einem dedizierten Server mit Hardware-basierter WORM-Speicherung (Write Once, Read Many). In der Cloud wird daraus eine VM mit angehängtem Storage – aber die Garantie, dass niemand die Daten nachträglich ändern kann, hängt jetzt an Zugriffsberechtigungen und Logging-Mechanismen, die man selbst konfigurieren muss.

Hinzu kommt: Viele ältere DMS- oder Archivierungslösungen sind nicht für Cloud-Umgebungen konzipiert. Sie erwarten lokale Dateisysteme, bestimmte Netzwerkstrukturen oder proprietäre Datenbankformate. Wenn man diese Systeme in die Cloud zwingt, entstehen oft Kompatibilitätsprobleme – ohne dass man gleichzeitig die Vorteile der Cloud nutzen kann.

Das Ergebnis: Lift and Shift bringt in diesen Fällen oft keine Cloud-Vorteile, sondern nur neue Risiken. Man zahlt Cloud-Preise, hat aber weniger Kontrolle als vorher – und muss zusätzlich sicherstellen, dass alle Compliance-Anforderungen weiterhin erfüllt sind.

Die bessere Alternative: Cloud-native oder hybride Lösungen

Statt ein altes System zu verlagern, sollte man prüfen, ob es moderne, cloud-native Alternativen gibt. Viele Anbieter entwickeln heute Lösungen, die speziell für Cloud-Umgebungen konzipiert sind und Compliance-Anforderungen von Grund auf mitbringen:

• Revisionssichere Archivierung mit Azure Blob Storage Immutable Storage: Microsoft bietet Speicheroptionen, die nachträgliche Änderungen technisch verhindern – mit Audit-Logs, Versionierung und garantierter Data Residency.

• Dokumentenmanagementsysteme als SaaS: Moderne DMS-Lösungen wie M-Files, DocuWare oder SharePoint Online sind cloud-nativ gebaut und erfüllen GoBD-, DSGVO- und ISO-Anforderungen – oft besser als selbst betriebene Legacy-Systeme.

• Hybride Architekturen: Sensible Daten bleiben lokal oder in einer Private Cloud, während weniger kritische Prozesse in der Public Cloud laufen. So kombiniert man Sicherheit mit Flexibilität.

Der entscheidende Punkt: Compliance ist kein Add-on, das man nachträglich einbaut. Sie muss in die Architektur eingewoben sein – und das gelingt mit modernen Cloud-Diensten oft besser als mit migrierten Legacy-Systemen.

Übergang oder Sackgasse?

Lift and Shift wird oft als „pragmatischer erster Schritt” verkauft. Doch die Realität zeigt: Aus dem vermeintlichen Übergangszustand wird häufig ein Dauerzustand. Und das ist problematisch.

Warum Lift and Shift selten eine Strategie ist

Der Grund ist simpel: Sobald ein System in der Cloud läuft und „funktioniert”, sinkt die Dringlichkeit, es zu modernisieren. Die Budgets werden anderweitig verplant, das Team konzentriert sich auf neue Projekte, und die Cloud-VM bleibt, wie sie ist – Jahr für Jahr.

Das Problem dabei: Die technischen Schulden wachsen weiter. Die Software altert, die Wartungskosten steigen, und irgendwann steht man vor derselben Frage wie vor der Migration – nur dass man jetzt zusätzlich Cloud-Kosten trägt.

Die entscheidenden Fragen

Unternehmen, die Lift and Shift in Erwägung ziehen, sollten sich ehrlich fragen:

Wird diese Anwendung in 3–5 Jahren noch Bestand haben?
Wenn die Antwort „nein” ist, kann Lift and Shift eine sinnvolle Übergangslösung sein – um Zeit zu gewinnen, bis eine Ablösung steht. Wenn die Antwort „ja” ist, sollte man direkt in eine moderne Architektur investieren.

Gibt es bereits Anbieter, die cloud-native Alternativen entwickeln?
Viele Softwarehersteller migrieren ihre Produkte selbst in die Cloud oder bieten SaaS-Varianten an. Manchmal ist es strategisch klüger, auf die native Cloud-Version zu warten, statt die On-Premise-Variante selbst zu migrieren.

Erzeugt die Zwischenlösung eine dauerhafte Abhängigkeit?
Wenn man Lift and Shift betreibt und danach jahrelang nichts ändert, verfestigt sich die Architektur. Mitarbeiter gewöhnen sich daran, Prozesse werden darauf aufgebaut, und die Migrationskosten steigen mit jedem Jahr. Dann ist die vermeintliche Übergangslösung zur Sackgasse geworden.

Metapher: Der Umzug in eine alte Wohnung in einem neuen Haus

Lift and Shift ist wie der Umzug in eine alte Wohnung, die in einem modernen Hochhaus eingebaut wurde. Das Gebäude ist neu, die Fassade glänzt, und das Dach ist dicht. Aber innen hat man noch die alten Leitungen, die verkalkten Rohre und die zugigen Fenster. Man wohnt in einem neuen Haus – aber der Komfort ist derselbe wie vorher.

Cloud-Native hingegen ist der Einzug in eine komplett neue Wohnung: moderne Ausstattung, intelligente Heizung, schnelles Internet, effiziente Infrastruktur. Der Umzug ist aufwändiger – aber man lebt besser.

Wann Warten strategischer ist als Investieren

Es gibt Situationen, in denen die beste Strategie darin besteht, gar nicht zu migrieren – sondern zu warten.

Wenn die Software ein Auslaufmodell ist
Manche Anwendungen haben keine Zukunft. Der Hersteller entwickelt nicht mehr weiter, die Technologie ist überholt, und es ist absehbar, dass das System in wenigen Jahren ersetzt wird. In diesem Fall ist es oft klüger, die bestehende Infrastruktur minimal zu halten und Ressourcen in die Ablösung zu investieren – statt Geld in eine Migration zu stecken, die ohnehin nur temporär ist.

Wenn der Markt noch keine ausgereiften Alternativen bietet
In manchen Nischenbereichen gibt es noch keine wirklich überzeugenden cloud-nativen Lösungen. Hier kann es sinnvoll sein, abzuwarten, bis der Markt nachzieht – statt mit halbgaren Eigenentwicklungen oder unausgereiften SaaS-Tools zu experimentieren.

Wenn die Organisation noch nicht bereit ist
Cloud-Native erfordert nicht nur technische Kompetenz, sondern auch ein Umdenken in Prozessen, Verantwortlichkeiten und Arbeitsweisen. Wenn das Team noch nicht soweit ist, kann ein übereilter Umbau mehr schaden als nutzen. Manchmal ist es besser, zunächst Wissen aufzubauen, Pilotprojekte zu starten und erst dann die kritischen Systeme anzugehen.

Aber: Warten darf keine Ausrede sein
Warten ist nur dann strategisch, wenn klar ist, wohin die Reise geht. Wer wartet, ohne einen Plan zu haben, verschiebt nur das Problem – und macht es größer.

Zusammengefasst: Die Architektur bestimmt die Zukunft

Lift and Shift kann helfen, kurzfristig handlungsfähig zu bleiben. Es verschafft Zeit, reduziert Risiken und ermöglicht einen schnellen Cloud-Einstieg. Aber es ist keine Lösung – es ist ein Aufschub.

Wer langfristig denkt, muss cloud-native Architekturen einplanen – auch wenn der Weg dorthin komplexer ist. Denn die Zukunft der IT liegt nicht in immer größeren Servern oder schnelleren Prozessoren. Sie liegt in intelligenten Architekturen, die Skalierung, Sicherheit und Wartung automatisch übernehmen.

In Zukunft wird Effizienz durch Architektur bestimmt, nicht durch Rechenleistung.

Das bedeutet: Unternehmen müssen sich entscheiden, ob sie die Cloud nur als neuen Standort für alte Systeme nutzen wollen – oder als Plattform für moderne, resiliente und wartungsarme Anwendungen.

Die Frage lautet nicht mehr: „Gehen wir in die Cloud?” Die Frage lautet: „Wie nutzen wir die Cloud richtig?”

Und die Antwort darauf beginnt nicht mit einer VM – sondern mit einer Strategie.

---

Diese Serie hat gezeigt: Lift and Shift ist weder gut noch schlecht – es ist eine Wahl, die Konsequenzen hat. Wer sie trifft, sollte wissen, worauf er sich einlässt. Und wer eine Alternative sucht, findet sie heute leichter als je zuvor.

Die Cloud ist kein Selbstzweck. Sie ist ein Werkzeug – und wie jedes Werkzeug entfaltet sie ihre Wirkung nur, wenn man sie richtig einsetzt.