Cloud-Migration von Legacy-Anwendungen: Ablauf und typische Fehler

Bei der Cloud-Migration einer Legacy-Anwendung wird eine Altanwendung aus dem eigenen Rechenzentrum in eine Cloud-Umgebung verlagert: unverändert (Rehost), mit gezielten Anpassungen oder als Neuentwicklung. Der Ablauf umfasst vier Schritte: Bestand prüfen, Strategie je Anwendung wählen, Daten und Betrieb absichern und schrittweise migrieren. Die häufigsten Fehler sind ein fehlendes Audit, unterschätzte Abhängigkeiten und vernachlässigte Anwenderschulungen.

Kennen Sie den Fall, dass eine Produkteinführung bevorsteht, aber aufgrund eines veralteten Servers verschoben werden muss? So etwas tritt immer wieder auf, denn oft wird die unternehmerische Agilität durch eine Legacy-Anwendung (eine Altanwendung, siehe Legacy-System) gebremst. Die Folgen sind höhere Betriebskosten und – was fast noch schlimmer ist – beunruhigende Sicherheitsrisiken. Cloud-Computing bietet dagegen Skalierbarkeit, Ausfallsicherheit und schnelleren Zugang zu Innovationen. Entsprechend sehen viele Modernisierungsprojekte heute eine teilweise oder vollständige Migration in die Cloud vor. Unternehmen, die eine solche Umstellung weiter aufschieben, riskieren strategische Nachteile, durch die möglicherweise ihre Wettbewerbsfähigkeit sinkt.

Welche Legacy-Anwendungen kann man in die Cloud verlagern?

Bei einer Legacy-Anwendung kann es sich um ein veraltetes ERP-System, eine „selbst gebastelte“ Geschäftsanwendung, ein intern entwickeltes CRM-Tool und vieles mehr handeln. Auch heute trifft man in Informationssystemen noch immer auf

• statische Websites, die mit klassischen ASP-Skripts erstellt wurden,
• HR-Software, die für nicht mehr existente Betriebssysteme entwickelt wurde,
• ein Data Warehouse, das auf proprietären Datenbankmanagementsystemen basiert.

Solche Lösungen sind zwar noch in der Lage, kritische Geschäftsprozesse abzuwickeln, da sie jedoch aus einem fragmentierten, teilweise schlecht dokumentierten Quellcode und einer monolithischen Architektur bestehen, sind sie nur begrenzt skalierbar. Die gute Nachricht: Meist ist eine Migration in eine – öffentliche, private oder hybride – Cloud-Infrastruktur möglich, vorausgesetzt, die Cloud-Readiness ist gegeben. Manchmal gibt es allerdings Systemabhängigkeiten, Lizenzauflagen oder Kosten für den Ersatz eines externen Bestandteils, die eine Transformation komplex machen.

Bevor Sie also ein solches Projekt starten, sollten Sie die Legacy-Anwendung optimieren und unnötige Codezeilen entfernen. Das reduziert Sicherheitslücken und vereinfacht die Wartung. Die Herausforderung besteht darin, den Geschäftswert zu erhalten und gleichzeitig eine zukunftsorientierte Modernisierung der Systeme einzuleiten. Auch die Mitarbeiter sollten auf den Umgang mit neuen, cloudbasierten Diensten vorbereitet werden.

Cloud-Migration oder Modernisierung: Was ist der Unterschied?

Die beiden Begriffe werden oft synonym verwendet, beschreiben aber verschiedene Dinge. Eine Cloud-Migration verändert, wo eine Anwendung läuft: Sie wird aus dem eigenen Rechenzentrum in eine Cloud-Umgebung verlagert. Eine Modernisierung verändert, wie die Anwendung aufgebaut ist: Code, Architektur, Schnittstellen und Benutzeroberfläche werden auf einen aktuellen Stand gebracht.

In der Praxis greifen beide ineinander. Ein reines Rehosting ist eine Migration ohne Modernisierung, ein Refactoring oder Rebuild verbindet beides. Welcher Weg sinnvoll ist, hängt vom Zustand der Anwendung, vom Budget und von der Dringlichkeit ab. Wie Sie eine Altanwendung unabhängig vom Betriebsort verbessern, lesen Sie in unserem Artikel Legacy-Anwendung modernisieren.

Der Druck, Altanwendungen cloudfähig zu machen, wächst: Laut dem Bitkom Cloud Report 2025 nutzen 90 % der Unternehmen in Deutschland Cloud-Anwendungen, und im Schnitt laufen bereits 47 % ihrer IT-Anwendungen in der Cloud. Gleichzeitig nennen 67 % ein vertrauenswürdiges Herkunftsland des Anbieters als zwingende Voraussetzung. Datenstandort und Anbieterwahl gehören deshalb von Anfang an in die Migrationsplanung.

1. Schritt: Das bestehende System prüfen und die Umsetzbarkeit bewerten

Ein gewissenhaftes Audit ist das A und O für eine gelungene Migration. Beginnen Sie damit, die Softwarearchitektur zu erfassen:

• Versionen der Betriebssysteme
• externe Abhängigkeiten
• Datenbankpläne
• Netzwerkprotokolle
• Hardware-Infrastruktur
• Dienstleistungsniveau

Durch eine detaillierte Analyse erkennen Sie veraltete Bestandteile, überflüssige Codezeilen und Module, die potenzielle Sicherheitsrisiken beinhalten.

Stellen Sie anschließend diese Informationen den realen Anforderungen des Geschäftsbetriebs gegenüber. Welche Features unterstützen die strategischen Prozesse? Wie oft werden sie genutzt? Wann treten Spitzenlasten auf? Ziel ist es, genau zu unterscheiden, welche Teile der Legacy-Software unverzichtbar sind und welche Teile des Codes gelöscht werden können oder neu geschrieben werden müssen. Bewerten Sie darüber hinaus die Wartungskosten, die technischen Schulden sowie das Risiko, das mit der Nichteinhaltung gesetzlicher Auflagen (z. B. DSGVO, branchenspezifische Vorschriften) verbunden ist.

Auf Grundlage dieser Gegenüberstellung erkennen Sie kritische Punkte und können die Cloud-Readiness einschätzen, bevor Sie die Prioritäten für den Backlog der IT-Modernisierung festlegen. Diese umfassende Betrachtung ermöglicht eine Einschätzung des notwendigen Budgets für die Transformation, sodass CIO und Unternehmensleitung die notwendigen finanziellen Abwägungen treffen können.

2. Schritt: Die richtige Migrationsstrategie finden

Ist die Diagnose erstellt, geht es im nächsten Schritt darum, für jede Anwendung die passende Vorgehensweise zu definieren. Dabei bietet das sogenannte 6-R-Modell eine verlässliche Orientierung: Rehost, Refactor, Revise, Rebuild, Replace und Retire. Jede dieser Optionen erfordert einen anderen Aufwand, eine andere Projektdauer und ist mit mehr oder weniger hohen Kosten verbunden.

Steht nur wenig Zeit zur Verfügung, kann die Rehost-Strategie eine gute Lösung sein: Die Anwendung wird in eine IaaS-Umgebung (Infrastructure as a Service), z. B. Azure, verlagert, ohne den Code zu verändern. Das geht schnell, allerdings migrieren Sie auch die technischen Schulden. Bei der Refactor-Strategie wird der Quellcode überarbeitet, REST-APIs werden bereitgestellt und die Dienste für eine Microservice-Architektur entkoppelt.

Der Migrationsansatz Revise passt ressourcenintensive Module an, zum Beispiel das Reporting, um die Vorteile des Cloud-Computings zu nutzen, ohne die Software komplett neu schreiben zu müssen. Bei Rebuild wird die Anwendung dagegen in einer DevOps-Umgebung cloudnativ neu entwickelt.

Bei Replace wird das bestehende System durch eine SaaS-Lösung ersetzt, was eine einfachere Wartung, aber auch veränderte Geschäftsprozesse zur Folge hat. Bei der Variante Retire wird die Anwendung komplett stillgelegt, die Daten werden archiviert. Unternehmen kombinieren in der Regel mehrere „R-Strategien“, um Budget, Fristen und den Modernisierungsgrad im Gleichgewicht zu halten. Die Entscheidung sollte aber immer gut durchdacht und auf keinen Fall spontan gefällt werden.

5 R, 6 R oder 7 R: Welche Migrationsstrategien gibt es?

Je nach Quelle ist von fünf, sechs oder sieben „R“ die Rede. Die Grundidee ist überall dieselbe: Für jede Anwendung wird einzeln entschieden, wie viel sich bei der Migration ändern soll. AWS unterscheidet zum Beispiel sieben Strategien:

• Retire: die Anwendung abschalten und die Daten archivieren,
• Retain: die Anwendung vorerst im eigenen Rechenzentrum belassen,
• Rehost: die Anwendung unverändert in die Cloud verschieben (Lift and Shift),
• Relocate: ganze Server- oder Virtualisierungsumgebungen auf die Cloud-Version derselben Plattform verlagern,
• Repurchase: die Anwendung durch ein anderes Produkt ersetzen, meist eine SaaS-Lösung,
• Replatform: mit gezielten Anpassungen migrieren, etwa die Datenbank in einen verwalteten Dienst überführen,
• Refactor: die Architektur cloudnativ umbauen, zum Beispiel in Microservices.

„Replace“ im 6-R-Modell entspricht weitgehend „Repurchase“; „Revise“ und „Rebuild“ beschreiben unterschiedlich tiefe Umbauten. Wichtiger als die Bezeichnung ist die Entscheidung pro Anwendung. Für große Migrationen empfiehlt AWS vor allem Rehost, Replatform, Relocate und Retire, weil Refactoring die aufwendigste Strategie ist. Eine Altanwendung, die Sie in absehbarer Zeit ablösen wollen, sollten Sie daher nicht aufwendig umbauen.

3. Schritt: Daten sichern und die Kontinuität der Geschäftsprozesse gewährleisten

Bei der Migration einer Legacy-Anwendung in die Cloud gehen Sie mit höchst sensiblen Informationen um. Daher besteht die oberste Priorität darin, die Daten bei der Migration zu schützen, zum Beispiel durch:

• AES-256-Verschlüsselung
• Schlüsselmanagement durch Hardware-Sicherheitsmodule (HSM)
• Netzwerksegmentierung
• Multi-Faktor-Authentifizierung (MFA)

Solche Maßnahmen sind die Voraussetzung, um Sicherheitsrisiken zu vermeiden und die Auflagen der Datenschutz-Grundverordnung (DSGVO) zu erfüllen. In einem zentral geführten Audit-Protokoll werden alle Ereignisse aufgezeichnet, um Anomalien in Echtzeit zu erkennen.

Auf jeden Fall muss die Kontinuität der Prozesse gewährleistet sein. Pläne zur Aufrechterhaltung der Geschäftskontinuität (Business Continuity Plan, BCP) und zur Notfallwiederherstellung (Disaster Recovery Plan, DRP) legen die maximale Dauer von Ausfallzeiten sowie den maximal vertretbaren Datenverlust fest. Automatische Back-ups, die in mehrere Regionen repliziert werden, sowie Rollback-Skripts gewährleisten die Wiederherstellung des Zustands vor einem Zwischenfall.

Regelmäßige Belastungstests prüfen die Resilienz der Infrastruktur. Dieser integrierte Ansatz sichert kritische Geschäftsprozesse ab und gibt den Stakeholdern Sicherheit. Wir empfehlen zudem, die Installation von System-Patches zu automatisieren sowie eine Zero-Trust-Strategie und ein striktes Container-Management umzusetzen, um potenzielle Angriffsflächen im Tagesgeschäft zu reduzieren.

4. Schritt: Migration sukzessive durchführen

Eine Migration gelingt am besten, wenn sie in Einzelschritte gegliedert und methodisch durchgeführt wird. Sinnvollerweise beginnt man zunächst in einer Testumgebung oder einer Sandbox, die das reale System exakt abbildet. In dieser Sandbox können IaC-Skripts (Infrastructure as Code) validiert, die Kompatibilität überprüft und Auswirkungen auf die Performance gemessen werden.

Anschließend zerlegen Sie die Anwendung in eigenständige Module:

• Benutzeroberfläche,
• Anwendungsschicht (Application Layer)
• Business Rule Engine
• Datenbank

Jedes der Module wird eigenständig verschoben, wobei Module mit schnellem Nutzen Vorrang haben. Dieses schrittweise Vorgehen verhindert lange Projektphasen ohne sichtbare Ergebnisse und sichert den operativen Betrieb ab.

Die Steuerung des gesamten Prozesses setzt allerdings eine straffe Überwachung voraus: aktuelle Jira-Backlogs, Dashboards zur Überwachung, Indikatoren für die Reaktionszeit und Kosten pro Transaktion. Für die ersten Sprints werden Key-User benannt. Ein agiles Veränderungsmanagement verhindert unterschwelligen Widerstand und fördert die Akzeptanz der neuen Benutzeroberflächen. Bevor ein Inkrement in den Live-Betrieb geht, wird es durch automatisierte Tests freigegeben. Mit einem Canary Release (einem schrittweisen Rollout) lässt sich bei Problemen schnell zur alten Version zurückkehren.

6 Fehler, die Sie bei der Migration einer Legacy-Anwendung vermeiden sollten

Bevor wir auf einige klassische Fallstricke eingehen, vorab ein Hinweis: Die Migration in die Cloud ist nicht einfach ein Wechsel von einem Server auf den anderen, sondern zieht die Transformation von Geschäftsprozessen, Systemarchitekturen und der technischen Kultur nach sich. Um Kosten, Sicherheit und Performance im Griff zu behalten, müssen Sie den Migrationsprozess vorausschauend planen, die notwendigen Vorkehrungen treffen und jeden Schritt bewerten.

Migration ohne vorheriges Audit

Ein zu ehrgeiziger Zeitplan kann Unternehmen dazu bewegen, sich blindlings in ein Rehosting (Lift & Shift) zu stürzen. Application Dependency Mapping, aus Lizenzen resultierende Verpflichtungen, technische Schulden und die veraltete Hardware werden außer Acht gelassen. Die Folgen sind eine sinkende Performance und versteckte Kosten, denn hinter der Cloud-Fassade verbirgt sich weiterhin eine Legacy-Anwendung. Nehmen Sie sich ausreichend Zeit für eine gründliche Analyse des Istzustands, damit sich die Investition langfristig rechnet.

Abhängigkeiten oder technische Schulden unterschätzen

Es gibt viele „unsichtbare Faktoren“, die die Migration am Tag X zum Erliegen bringen können:

• ein COBOL-Batchprogramm
• eine veraltete ODBC-Schnittstelle
• ein nicht dokumentiertes Shellskript

Erfassen Sie daher alle Prozesse, Programme und Schnittstellen und erstellen Sie anhand der Anzahl der zu optimierenden Codezeilen ein Budget für die Systemmodernisierung.

Die falsche Strategie wählen

Manchmal werden monolithische, schlecht skalierbare Anwendungen unverändert in die Cloud verschoben. Es sieht so aus, als würde sich das schnell auszahlen, doch in Wirklichkeit schnellen die Kosten für die Cloud in die Höhe und die „tatsächliche“ Modernisierung steht immer noch aus. Umgekehrt kann der Wunsch, alles sofort neu machen zu wollen, die Verfügbarkeit neuer Features hinauszögern. Nutzen Sie das 6-R-Modell, um Businessziele, Budget und technische Reife aufeinander abzustimmen.

Sicherheit und Compliance vernachlässigen

Einen Datenbank-Dump in einen öffentlichen, nicht verschlüsselten Cloud-Bucket zu kopieren, öffnet Angreifern Tür und Tor. Überprüfen Sie die im Rahmen des IAM (Identity and Access Management) vergebenen Rechte, führen Sie regelmäßige Rezertifizierungen durch und verschlüsseln Sie Ihre Daten. Beachten Sie von Anfang an Compliance-Vorgaben wie DSGVO, ISO 27001 oder spezifische Auflagen Ihrer Branche. Korrekturen in letzter Minute sind um ein Vielfaches teurer.

Schulung der Endanwender vernachlässigen

Die Cloud bringt gewohnte Abläufe durcheinander: neue Oberflächen, Single Sign-on (SSO), eigenständige Erstellung von Testumgebungen. Ohne Unterstützung besteht die Gefahr, dass sich schnell Widerstand gegen die Veränderung einschleicht und der Produktivitätsgewinn dahinschmilzt. Rechnen Sie mit diesem Widerstand und wirken Sie ihm durch Schulungsprogramme, interaktive Tutorials und andere Unterstützungsmaßnahmen entgegen.

Keine Indikatoren für die Überwachung nach der Migration vorsehen

Ist die Legacy-Anwendung einmal in die Cloud verlagert, löst sich das Projektteam auf und es ist niemand mehr da, um Faktoren wie Latenz, Kosten pro Anfrage oder die User-Zufriedenheit zu messen. Legen Sie gleich zu Beginn Kennzahlen (KPIs) fest, etwa Bearbeitungszeit, Fehlerquote oder durchschnittlichen Warenkorbwert. Richten Sie Monitoring und Logging ein und automatisieren Sie Warnmeldungen. Über ein Cloud-Dashboard passen Sie die Ressourcenzuteilung an, behalten die Kosten im Griff und belegen gegenüber der Unternehmensleitung den Nutzen der Migration.

Wenn Sie diese Fehler vermeiden, ist die Migration einer Legacy-Anwendung nicht nur eine Verlagerung der Infrastruktur in die Cloud, sondern ein Hebel für die Modernisierung Ihrer Systeme. Die Folge: bessere Performance, geringere Wartungskosten und eine höhere Sicherheit der Legacy-Anwendungen.

Beispiel: So kann eine gelungene Migration aussehen

Nehmen wir als fiktives Beispiel ein mittelständisches Unternehmen mit 250 Beschäftigten, das auf die Regulierung von Kfz-Schadensfällen spezialisiert ist. Es besitzt eine Legacy-Anwendung, die vor 15 Jahren entwickelt wurde und auf einem eigenen Server im Unternehmen läuft, dessen Wartung sehr hohe Kosten verursacht. Nach einem umfassenden Audit entscheidet sich das Unternehmen für eine kombinierte Migration: Rebuild für das Kundenportal, Refactor für den Bereich Entschädigungsberechnung.

Die Migration erfolgt innerhalb von vier Monaten, Modul für Modul, über eine CI/CD-Pipeline in Azure. Das Ergebnis spricht für sich:

• Die Infrastrukturkosten sind um 30 % gesunken.
• Die Bearbeitung kann 50 % schneller erfolgen.
• Die Nutzerzufriedenheit liegt bei 4,6 von 5 möglichen Punkten.

Dazu tragen unter anderem ein responsives Webdesign und ein Self-Service-Dashboard für Echtzeitanalysen bei.

Die Fachabteilungen haben nun datengesteuerte Dashboards zur Verfügung, die Entwickler arbeiten in einer cloudnativen Umgebung und die Unternehmensleitung kann das Dienstleistungsniveau genau ablesen. Das Unternehmen bereitet bereits die Einführung neuer, KI-basierter Dienstleistungen vor und plant die Expansion auf europäischer Ebene.

Fazit: Migration ja, aber richtig

Cloud-Computing kann Innovationen deutlich beschleunigen. Mit dem richtigen strategischen Ansatz modernisieren Sie die Systeme Ihres Unternehmens sukzessive und zuverlässig, sparen dadurch Kosten und gewährleisten die Sicherheit.

Bevor Sie sich an die konkrete Umsetzung machen, bewerten Sie zuerst die Cloud-Readiness und erstellen Sie eine realistische Roadmap. Ihre Legacy-Anwendungen sind es wert, dass Sie ihre Funktionsfähigkeit langfristig sicherstellen.