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) gebremst. Die Folgen sind höhere Betriebskosten und – was fast noch schlimmer ist – beunruhigende Sicherheitsrisiken. Im Gegensatz dazu ist Cloud-Computing ein Garant für Skalierbarkeit, Resilienz und Innovation. Daher ist es nicht erstaunlich, dass laut IDC bis 2026 80 % der Modernisierungsprojekte von Unternehmen eine teilweise oder vollständige Migration in die Cloud vorsehen. Unternehmen, die heute eine solche Transition noch aufschieben, riskieren strategische Nachteile, durch die möglicherweise ihre Wettbewerbsfähigkeit sinkt.
Welche Legacy-Anwendungen kann man in die Cloud verlagern?
Bei einer Legacy Application 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 dokumentiertem 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 lancieren, 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 Dienstleistungen vorbereitet werden.
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.
Aufgrund dieser analytischen 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 ist das berühmte 6-R-Modell ein verlässlicher Kompass: 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.
| Strategie | Prinzip | Aufwand | Wichtigster Nutzen | Größtes Risiko |
| Rehost (Lift & Shift) | Eine Software ohne Architekturänderung in der Cloud bereitstellen | Gering | Schnelle Migration | Technische Schulden werden übernommen |
| Refactor | Den Code einer Anwendung optimieren, ohne die Features zu verändern | Mittel | Bessere Skalierbarkeit | Komplexe Tests |
| Revise | Die Softwarearchitektur und einige Schlüsselmodule anpassen | Mittel bis hoch | Verbesserung der Performance | Tunneleffekt |
| Rebuild | Die Anwendung auf einem modernen Cloud-Stack neu aufsetzen | Hoch | Cloud-native Ausrichtung | Benötigt viel Zeit |
| Replace | Die Anwendung durch ein SaaS-System (Software as a Service) oder ein COTS-Produkt (Commercial off-the-shelf, kommerzielles Produkt von der Stange) ersetzen | Unterschiedlich | Innovative Features | Veränderte User-Experience |
| Retire | Ein veraltetes System komplett abschaffen | Gering | Kosteneinsparung | Verlust der nicht-migrierten Daten |
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 offengelegt 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 dagegen eine neue, verpackte Software in einer DevOps-Umgebung 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.
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 auf mehrere Bereiche 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 verschafft den Stakeholdern ein beruhigendes Gefühl. Wir empfehlen zudem, die Installation von System-Patches zu automatisieren sowie eine Zero-Trust-Politik und ein striktes Container-Management zu verfolgen, um potenzielle Angriffsflächen im Tagesgeschäft zu reduzieren.
4. Schritt: Migration sukzessive durchführen
Eine Transition 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.
In der Folge fragmentieren Sie die Anwendung in kohärente Module:
- Benutzeroberfläche,
- Anwendungsschicht (Application Layer),
- Business Rule Engine
- Datenbank
Jedes der Module wird eigenständig verschoben, wobei diejenigen prioritär sind, die eine schnelle Rendite versprechen. Dieses inkrementelle Vorgehen limitiert die Auswirkungen des Tunneleffekts 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. Es werden sogenannte Key-User für die ersten Sprints definiert. 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 einer Canary-Release-Strategie (einem progressiven Rollout) kann man in kürzester Zeit wieder zur alten Version zurückkehren, sollte ein Problem auftreten.
6 Fehler, die Sie bei der Migration einer Legacy-Anwendung vermeiden sollten
Bevor wir auf einige klassische Fallstricke eingehen, zunächst eine Erinnerung: 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 der Migrationsprozess antizipiert, die notwendigen Vorkehrungen getroffen und jeder Schritt bewertet werden.
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 unter dem Deckmantel der Cloud verbringt sich immer noch eine Legacy Application. Wenden Sie mindestens zwei Wochen für eine peinlich genaue Diagnose des Istzustandes auf, damit sich die Investitionen langfristig rentabel gestalten.
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 altertümliche OBDC-Schnittstelle
- ein nicht dokumentiertes Shellskript
Erfassen Sie daher alle Prozesse, Codes und Schnittstellen und erstellen Sie anhand der Anzahl der zu optimierenden Codezeilen ein Budget für die Systemmodernisierung.
Die falsche Strategie
Manchmal werden monolithische, schlecht skalierbare Anwendungen „nur“ optimiert. 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 Angriffen auf die Sicherheit Tür und Tor. Überprüfen Sie die im Rahmen des IAM (Identity and Access Management) vergebenen Rechte, führen Sie regelmäßige Rezertifizierungsaudits durch und nutzen Sie die Verschlüsselung. 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. Antizipieren Sie diesen 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 Key-Performance-Indikatoren (KPI) (Bearbeitungszeit, Fehlerquote, durchschnittlicher Warenkorb usw.) fest. Protokollieren Sie Monitoring und Logging, automatisieren Sie Warnmeldungen. Mit dem Cloud-Cockpit können Sie die Zuteilung der Ressourcen anpassen, behalten die Kosten im Griff und stellen gegenüber der Unternehmensleitung den Wert unter Beweis.
Wenn Sie diese Fehler vermeiden, ist die Migration einer Legacy Application nicht nur eine Verlagerung der Infrastruktur in die Cloud, sondern ein Hebel für eine System-Modernisierung. Die Folge: bessere Performance, geringere Wartungskosten und eine höhere Sicherheit der Legacy-Anwendungen.
Szenario einer gelungenen Migration
Nehmen wir ein mittelständisches Unternehmen mit 250 Mitarbeitern, das auf die Regulierung von Kfz-Schadensfällen spezialisiert ist. Es besitzt eine Legacy-Anwendung, die vor 15 Jahren entwickelt wurde und auf einem Server vor Ort gehostet ist, 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, mittels einer mit Azure entwickelten CI/CD-Pipeline. 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.
Grundlage für diese positiven Ergebnisse sind ein Responsive Webdesign und ein Self-Service-Dashboard für Echtzeit-Analysen.
Die Fachabteilungen haben nun datengesteuerte Dashboards zur Verfügung, die Entwickler arbeiten in einer Cloud-nativen 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.
Schlussfolgerung: Migration ja, aber richtig
Cloud-Computing ist ein hervorragender Katalysator für Innovation. 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.
