Die meisten Unternehmen erkennen nicht, dass sie ein Legacy-Problem haben, bis etwas auf eine Weise ausfällt, die teuer zu erklären ist. Ein Compliance-Audit beanstandet eine nicht unterstützte Plattform. Die Integration mit einem neuen Tool scheitert, weil das alte System keine nutzbare API hat. Ein Sicherheitsteam eskaliert eine Schwachstelle in Code, der seit vier Jahren kein Patch erhalten hat. Und plötzlich muss ein Gespräch, das vor zwei Jahren hätte stattfinden sollen, sofort geführt werden – unter Druck und mit einem Budget, das dafür nie eingeplant war.
Die Modernisierung von Legacy-Anwendungen ist die Antwort auf dieses Gespräch – aber nicht so, wie die meisten Menschen denken. Es ist keine einmalige Cloud-Migration. Es ist kein Rewrite-Projekt mit einer Ziellinie. Es ist ein kontinuierliches, risikogesteuertes Programm, das veraltete Systeme systematisch an aktuelle Geschäfts-, Sicherheits- und Leistungsanforderungen anpasst. Teams, die es als einzelnes Projekt behandeln, schließen das Projekt meist ab und häufen dann stillschweigend die nächste Welle technischer Schulden in den Systemen an, die sie nicht angefasst haben.
Das ist die zentrale These, die dieser Artikel vertritt: Die Modernisierung von Legacy-Anwendungen ist ein strukturiertes, iteratives Programm – kein Ereignis, das Sie abschließen.
Der Teil, den die meisten Teams erst nach der ersten gescheiterten Migration lernen
- Modernisierung ist nicht gleich Cloud-Migration – Rehosting ohne Architekturänderung bewahrt oft genau die technischen Schulden, denen Sie entkommen wollten.
- Die Strategie-Frameworks 6R und 7R geben Teams echte Optionen; nicht jedes System muss neu geschrieben oder ersetzt werden.
- Das Überspringen einer gründlichen Bewertungsphase ist die Hauptursache für Budgetüberschreitungen und festgefahrene Projekte.
- Wer Modernisierung als einmaliges Projekt behandelt, sorgt dafür, dass das Unternehmen sie zweimal durchführen muss.
- Die Sicherheits- und Compliance-Probleme, die eine Modernisierung erzwingen, treten in der Regel auf, bevor das Budget zu ihrer Behebung genehmigt wurde.
Was die Modernisierung von Legacy-Anwendungen tatsächlich bedeutet
Legacy-Modernisierung ist der Prozess, bestehende Softwareanwendungen zu aktualisieren, zu ersetzen oder umzustrukturieren, damit sie aktuellen technischen Standards, Geschäftsanforderungen und Sicherheitserwartungen entsprechen. Der Begriff ist bewusst weit gefasst – denn die richtige Maßnahme unterscheidet sich erheblich je nach System.
IBM definiert Anwendungsmodernisierung als die Aktualisierung älterer Software für neuere Computing-Ansätze, einschließlich neuerer Sprachen, Frameworks und Infrastrukturplattformen. Microsoft Azure beschreibt es ähnlich: Anwendungen, die für eine frühere Infrastruktur-Generation entwickelt wurden, weiterzuentwickeln – nicht nur hinsichtlich ihres Ausführungsorts, sondern auch hinsichtlich ihrer Architektur.
Der entscheidende Unterschied besteht darin, dass modernisieren nicht einfach bedeutet, etwas „an einen neuen Ort zu verschieben“. Ein System, das ohne Architekturänderung in die Cloud gehoben wird, bleibt ein Legacy-System – es läuft nur auf neuerer Hardware. Echte Anwendungsmodernisierung adressiert die zugrunde liegende Struktur: wie die Anwendung aufgebaut ist, wie sie mit anderen Systemen kommuniziert, wie sie Daten verarbeitet und ob ihre Architektur Geschäftsanforderungen unterstützen kann, die bei ihrer ursprünglichen Entwicklung noch nicht existierten.
Legacy-Systeme sind nicht immer gemessen am Kalenderdatum alt. Sie sind gemessen an ihrer Relevanz alt: aufgebaut auf einer monolithischen Architektur, die Veränderungen widersteht, abhängig von Plattformen, die Anbieter nicht mehr unterstützen, oder vom Rest des Unternehmens isoliert, weil sie nie mit Blick auf Integration konzipiert wurden. Modernisierung führt sie aus diesem Zustand in einen Zustand, der wartbar, erweiterbar und sicher ist.
Diese Unterscheidung zwischen „an einem neuen Ort ausgeführt“ und „tatsächlich modernisiert“ ist der Punkt, an dem die meisten Probleme beim Projektumfang beginnen.
Was überhaupt als Legacy-System gilt
Vor jedem Modernisierungsgespräch muss jemand entscheiden, welche Systeme dafür infrage kommen. Das klingt nach einem offensichtlichen Schritt. Selten wird er konsequent durchgeführt.
Eine Legacy-Anwendung wird nicht allein durch ihr Alter definiert. Entscheidend sind ihre operativen Merkmale: Läuft sie auf einer Plattform, für die der Anbieter keine Patches mehr bereitstellt? Kommuniziert sie über proprietäre Protokolle, die die Integration mit modernen Tools verhindern? Erfordert eine Änderung an einem Teil den Eingriff in fünf nicht zusammenhängende Komponenten, weil die Architektur nie modular konzipiert wurde? Setzt die Sicherheitslage das Unternehmen Schwachstellen aus, für die kein Fix verfügbar ist?
Veraltete Legacy-Systeme weisen meist einige wiederkehrende Fehlermuster auf – nicht unterstützte Laufzeitumgebungen, undokumentierte Abhängigkeiten, fest im Code verankerte Konfigurationen und Datenbanken, die so eng mit der Anwendungslogik gekoppelt sind, dass beide nicht unabhängig voneinander geändert werden können. Jedes dieser Probleme erzeugt Wartungsaufwand. Alle vier zusammen schaffen ein System, dessen Betrieb mehr Teamkapazität verbraucht, als es geschäftlichen Nutzen liefert.
Regulierte Branchen spüren dies besonders deutlich. Das Gesundheitswesen ist das klarste Beispiel: Laut Branchenberichten zur IT-Infrastruktur im Gesundheitswesen betreiben mehr als 60 % der US-Krankenhäuser weiterhin kritische Anwendungen auf Legacy-Software. In einem Umfeld, in dem Ausfallzeiten Auswirkungen auf die Patientensicherheit haben und Compliance-Anforderungen sich ständig weiterentwickeln, ist das nicht nur ein technisches Problem – sondern ein operatives Risiko, das sich jährlich verstärkt.
Wenn Ihr Team mehr Zeit damit verbringt, ein System am Leben zu halten, als es zu verbessern, ist das das diagnostische Signal.
📊 Die Zahlen:
Die Modernisierung von Legacy-Software in regulierten Branchen ist nicht nur eine technische Entscheidung – sie ist eine Frage des Risikomanagements. Wenn mehr als 60 % der US-Krankenhäuser kritische Workflows weiterhin auf nicht unterstützten Plattformen ausführen, lautet die Frage nicht, ob modernisiert werden soll, sondern was passiert, wenn ein Sicherheits- oder Compliance-Ereignis den Zeitplan erzwingt.
Warum Unternehmen Legacy-Anwendungen tatsächlich modernisieren
Die ehrliche Antwort lautet: Die meisten Unternehmen entscheiden sich nicht proaktiv für die Modernisierung von Legacy-Anwendungen. Sie werden dazu gedrängt. Ein Sicherheitsvorfall, ein fehlgeschlagenes Compliance-Audit, ein neues Geschäftssystem, das sich nicht mit dem alten integrieren lässt, oder ein wichtiger Anbieter, der das End-of-Life einer Plattform ankündigt, von der das Unternehmen abhängt. Die Entscheidung zur Modernisierung entsteht oft als Reaktion, nicht als Strategie.
Die geschäftlichen Treiber sind jedoch gut bekannt. Die Aktualisierung von Legacy-Anwendungen sowie die langfristige Wartung und Unterstützung von Legacy-Systemen verursachen sich verstärkende Kosten: Lizenzgebühren für alternde Plattformen, spezialisierte Fähigkeiten für die Pflege von Code in Sprachen, die niemand Neues mehr lernt, Infrastruktur ohne automatische Skalierung und ein Entwicklungstempo, das so langsam ist, dass Produktteams das Systemteam nicht mehr fragen, was möglich ist. Die Analyse der ProVato Group zeigt, dass die Kosten über den gesamten Lebenszyklus – laufende Wartung, Support und Infrastruktur – Legacy-Anwendungen über Zeit oft deutlich teurer machen als modernisierte Alternativen. Diese Rechnung landet irgendwann auf dem Schreibtisch eines CIO.
Die Forschungsperspektive von Konveyor/Red Hat weist auf einen Wandel hin, der inzwischen in Budgetzuweisungen sichtbar wird: Unternehmen verlagern Modernisierungsausgaben auf die Aktualisierung bestehender Legacy-Systeme, statt neue Systeme vollständig von Grund auf zu entwickeln. Der Impuls, um ein Legacy-System herumzubauen, hat ein Ablaufdatum. Irgendwann kostet die Erweiterung einer Behelfslösung mehr als die Behebung des zugrunde liegenden Problems.
Skalierungsgrenzen sind oft der operative Auslöser. Ein System, das das Geschäft mit 10.000 Transaktionen täglich bewältigt hat, gerät bei 500.000 an seine Grenzen und fällt bei einer Million aus – nicht weil die Logik falsch ist, sondern weil die Architektur nie für diese Last ausgelegt war. Integrationsblockaden sind der strategische Auslöser: Wenn ein neues CRM, eine Analyseplattform oder eine Partner-API nicht mit dem bestehenden System kommunizieren kann, wird die Legacy-Anwendung zur Obergrenze dessen, was das Unternehmen tun kann.
Die Bedeutung der Modernisierung von Legacy-Anwendungen für Sicherheit und Compliance
Sicherheits- und Compliance-Ausfälle sind der Punkt, an dem die Modernisierung von Legacy-Systemen nicht mehr optional ist. Auch im Support sehe ich dieses Muster immer wieder: Teams starten eine Modernisierungsinitiative erst, nachdem eine Schwachstelle ausgenutzt wurde oder ein Audit kritische Feststellungen liefert. Die Modernisierungsziele, die das Projekt von Anfang an hätten bestimmen sollen, werden zu Notfallkriterien, die den Umfang festlegen.
Regulierte Branchen – Gesundheitswesen, Finanzwesen und Behörden – tragen hier das höchste Risikoprofil. Nicht unterstützte Plattformen erhalten keine Patches. Ungepatchte Systeme sammeln bekannte Exploits an. Der Bericht der ACT-IAC-Arbeitsgruppe zur Modernisierung von Legacy-IT in Bundesbehörden formuliert dies ausdrücklich: Legacy-Code in zivilen Bundesbehörden schafft Sicherheitslücken, Integrationsschwierigkeiten und Compliance-Risiken, die sich direkt auf die Erfüllung ihres Auftrags auswirken.
Modernisierungsinitiativen, die zuerst die Sicherheitslage priorisieren, schaffen meist die richtige Grundlage für alles Weitere. Architekturentscheidungen, die eine Compliance-Lücke schließen, verbessern oft auch die Fähigkeit des Systems zur Integration, Skalierung und Wartung durch ein breiteres Team.
Vorteile der Legacy-Modernisierung für Skalierbarkeit und Kosteneffizienz
Bei den operativen Vorteilen konzentriert sich das Argument für Legacy-Modernisierung meist auf dieselben Ergebnisse: die Fähigkeit, auf Cloud-nativer Infrastruktur zu laufen, die Möglichkeit zur Einführung von DevOps- und CI/CD-Praktiken, die die Bereitstellung beschleunigen, sowie die Verringerung der Wartungslast für Engineering-Teams, die derzeit große Teile ihrer Zeit damit verbringen, alte Systeme am Leben zu halten, statt neue Funktionen zu entwickeln.
IT-Betriebsteams, die Modernisierung vorantreiben – insbesondere mit Blick auf eine Cloud-Service-Strategie –, rechtfertigen die Investition häufig mit Kosten- und Skalierungsargumenten. Weniger Abhängigkeiten von spezialisierten Fähigkeiten, Infrastruktur, die bei Bedarf skaliert statt überdimensionierter physischer Hardware, und die Möglichkeit, einen Monolithen in Services zu zerlegen, die unabhängig aktualisiert werden können, ohne das gesamte System anzufassen. Legacy-Modernisierung liefert keines dieser Ergebnisse automatisch, schafft jedoch die Voraussetzungen, um sie zu erreichen.
Legacy-Modernisierungsstrategien: Die Modelle 6R und 7R erklärt
Das Multi-R-Framework ist das Standard-Entscheidungsmodell für Strategien zur Anwendungsmodernisierung. Verschiedene Varianten erscheinen bei Argano, K2view, Konveyor und in der gesamten Branche – die Anzahl der Rs unterscheidet sich zwischen den Quellen leicht, die Kernoptionen sind jedoch konsistent. Der richtige Modernisierungsansatz für ein bestimmtes System hängt von seiner Kritikalität, Architektur, Integrationsabhängigkeiten und der Umsetzungskapazität des Teams ab.
So lassen sich die Strategien tatsächlich realen Situationen zuordnen:
| Strategie | Was sie tatsächlich bewirkt | Passendstes Einsatzszenario | Aufwand | Wann Sie sie vermeiden sollten |
|---|---|---|---|---|
| Rehost (Lift and Shift) | Verschiebt die Anwendung ohne Codeänderungen auf neue Infrastruktur | Enger Zeitplan, Compliance-Druck, Senkung der Infrastrukturkosten | Niedrig | Wenn die Architektur das eigentliche Problem ist – dann stehen Sie in zwei Jahren wieder hier |
| Replatform | Migriert auf eine neue Laufzeitumgebung oder einen Managed Service mit kleineren Optimierungen | Kernlogik ist solide, aber die Plattform hat ihr End-of-Life erreicht oder ist zu teuer | Mittel | Wenn zugleich tiefgreifende Codeänderungen nötig sind – ein teilweises Replatforming erzeugt oft hybride technische Schulden |
| Refactor | Strukturiert bestehenden Code um, um die Qualität ohne Änderung des externen Verhaltens zu verbessern | Codebasis ist wartbar, aber ineffizient; das Team kennt den Code | Mittel bis hoch | Wenn der bestehende Code so eng gekoppelt ist, dass Refactoring zu einem getarnten Rewrite wird |
| Re-architect | Gestaltet die Struktur der Anwendung neu, etwa vom Monolithen zu Microservices | Skalierbarkeit ist das Kernproblem, Entkopplung von Integrationen ist erforderlich | Hoch | Wenn dem Team die Fähigkeiten fehlen, die neue Architektur langfristig zu warten |
| Rebuild | Schreibt die Anwendung mit moderner Technologie komplett neu | Funktionalität wird benötigt, aber der bestehende Code ist zu fragil oder undokumentiert, um darauf aufzubauen | Sehr hoch | Wenn das bestehende System ausreichend gut funktioniert – eine Anwendung von Grund auf neu zu schreiben liefert selten das, was die Schätzung verspricht |
| Replace | Nimmt die individuelle Anwendung außer Betrieb und führt eine kommerzielle oder SaaS-Alternative ein | Standardfunktionalität ohne Wettbewerbsvorteil durch die individuelle Entwicklung | Mittel | Wenn das bestehende Datenmodell komplex ist und die Migration die eigentliche Herausforderung darstellt |
| Retire | Nimmt Legacy-Anwendungen außer Betrieb, die keinen Zweck mehr erfüllen | Geringe Nutzung, redundante Funktionalität wird bereits anderswo abgedeckt | Niedrig | Wenn „geringe Nutzung“ in Wirklichkeit eine unbekannte Abhängigkeit bedeutet – prüfen Sie dies, bevor Sie das System abschalten |
| Retain | Behält das System bewusst unverändert bei | Stabil, sicher, risikoarm, die Unterbrechungskosten lohnen sich nicht | Kein Aufwand | Wenn keine Sicherheitspatches mehr verfügbar sind – Retain ist nicht dasselbe wie akzeptiertes Risiko |
Der für jedes System gewählte Modernisierungsgrad sollte durch Analyse und nicht durch Präferenz bestimmt werden. Das Rehosting einer Anwendung bringt Projekte schnell in Gang und erfüllt kurzfristigen Druck. Es reduziert keine technischen Schulden. Das Ersetzen von Legacy-Systemen durch kommerzielle Alternativen tauscht Entwicklungskomplexität gegen Anbieterabhängigkeit und Datenmigrationsaufwand. Beides ist nicht falsch – der Fehler besteht darin, eine Strategie zu wählen, ohne zu verstehen, welches Problem sie tatsächlich löst.
Der Bedarf an Modernisierung von Legacy-Anwendungen: Wenn das System mehr kostet, als es liefert
Dies sind die Signale, die in Support-Warteschlangen, Eskalationsthreads und Architektur-Reviews auftauchen, bevor ein Modernisierungsprogramm endlich genehmigt wird. Jedes benennt ein Muster, den dadurch erzeugten Fehlermodus und das daraus folgende Geschäftsrisiko.
- Sicherheitspatches, die nicht angewendet werden können
Der Plattformanbieter veröffentlicht keine Updates mehr, oder die Architektur der Anwendung macht Patches zerstörerisch. Das Ergebnis ist eine bekannte Schwachstelle ohne Behebungsweg im Produktivbetrieb. In regulierten Umgebungen ist dies kein Risikomanagementproblem – sondern ein Compliance-Verstoß, der nur darauf wartet, entdeckt zu werden.
- Integrationsanfragen, die immer abgelehnt werden
Jedes neue SaaS-Tool, jede Partner-API oder jedes interne System, das versucht, sich mit der Legacy-Anwendung zu verbinden, erhält dieselbe Antwort: „Das kann dieses System nicht unterstützen.“ Die Architektur verfügt über keine erweiterbare API, nutzt proprietäre Datenformate oder erfordert für jede Verbindung individuelle Middleware. Das Unternehmen fragt nicht mehr, was möglich ist, weil die Antwort vorhersehbar ist.
- Steigende Wartungskosten ohne klare Obergrenze
Die Wartung und Unterstützung von Legacy-Systemen, die in veralteten Frameworks oder abgekündigten Sprachen entwickelt wurden, erfordert zunehmend spezialisierte Fähigkeiten. Je kleiner der Kreis der Personen wird, die diese Technologie beherrschen, desto höher werden die Betriebskosten. Diese Rechnung verstärkt sich über Zeit und wird selten auf einer einzelnen Budgetzeile sichtbar, bis jemand die vollständigen Lebenszykluskosten berechnet.
- Leistungsabfall unter Last, der sich architektonisch nicht beheben lässt
Legacy-Anwendungen skalieren vertikal – indem mehr Hardware auf das Problem geworfen wird –, bis das nicht mehr funktioniert. Monolithische Legacy-Anwendungen, die nicht für horizontale Skalierung vorgesehen waren, erreichen eine Grenze, die sich ohne Umstrukturierung der Anwendung selbst nicht umgehen lässt. Erweitern Sie Legacy-Systeme lange genug, verwalten Sie Symptome statt der Ursache.
- Unfähigkeit zur Einführung von CI/CD oder modernen Bereitstellungspraktiken
Wenn das Bereitstellungsmodell Ausfallzeiten, vollständige System-Regressionstests für jede Änderung oder Release-Zyklen erfordert, die in Monaten gemessen werden, verschlechtert sich die Fähigkeit des Unternehmens, auf Marktveränderungen zu reagieren. Die Geschwindigkeit der Bereitstellung wird zum Wettbewerbsengpass, nicht die technische Fähigkeit.
- Daten, die in unbeweglichen Formaten oder Strukturen eingeschlossen sind
Legacy-Systeme mit eng gekoppelten Datenbanken und proprietären Datenschemata machen jede Analytics-, Reporting- oder KI-Initiative schwieriger, als sie sein müsste. Die Daten existieren. Sie dorthin zu bringen, wo Entscheidungen getroffen werden, ist der kostspielige Teil.
- Das Bus-Factor-Problem
Es gibt ein oder zwei Personen, die verstehen, wie das System tatsächlich funktioniert. Sie sind nicht die Personen, die es entwickelt haben – diese haben das Unternehmen vor Jahren verlassen. Das aktuelle Team hat das System übernommen und durch Archäologie kennengelernt. Modernisieren Sie eine Legacy-Anwendung jetzt, solange diese Personen noch im Unternehmen sind, oder später unter schlechteren Bedingungen.
Das letzte Signal schafft es üblicherweise nicht in Management-Präsentationen. Es sollte es aber.
Wie die Modernisierung von Legacy-Anwendungen tatsächlich abläuft
Der Modernisierungsprozess ist kein Projekt mit Anfang, Mitte und Abschluss. Teams, die ihn so behandeln, schließen die Erstmigration ab, erklären sie zum Erfolg und beobachten dann, wie sich technische Schulden in den Systemen ansammeln, die sie nicht adressiert haben. Zwei Jahre später führen sie dasselbe Gespräch erneut – mit leicht verändertem Vokabular.
Die praktische Realität lautet: Ein Programm zur Modernisierung von Legacy-Anwendungen hat Phasen, aber keinen Endzustand. Systeme verändern sich. Geschäftsanforderungen verändern sich. Sicherheitslandschaften verändern sich. Das Ziel ist nicht, die Modernisierung abzuschließen – sondern ein Unternehmen aufzubauen, das sie als normale Funktion seines Technologiemanagements fortführen kann.
Das Programm hat dennoch eine logische Struktur: Bewertung, Strategieauswahl, Umsetzung und Validierung, die im Laufe der Zeit den gesamten Anwendungsbestand durchläuft.
Eine Kurzübersicht darüber, was jede Phase liefern sollte:
| Phase | Zentrales Ergebnis | Häufiger Fehlermodus |
|---|---|---|
| Bewertung | Architekturkarte, Abhängigkeitsinventar, Risikoregister | Übersprungen oder überhastet – der teuerste ausgelassene Schritt im Programm |
| Strategieauswahl | Entscheidung pro Anwendung anhand des 6R-/7R-Frameworks | Einheitliche Strategie wird unabhängig von der Eignung auf alle Systeme angewendet |
| Umsetzung | Phasenweise Migration oder Refactoring mit Validierungspunkten | Big-Bang-Ansatz; das neue System geht live, bevor es validiert wurde |
| Validierung | Tests auf funktionale Gleichwertigkeit, Performance-Benchmarking, Sicherheitsprüfung | Wird als abgeschlossen betrachtet, sobald die Migration fehlerfrei kompiliert |
Warum die Bewertungsphase der Punkt ist, an dem die meisten Legacy-Modernisierungsprojekte scheitern
In diese Phase investieren Teams am häufigsten zu wenig, und die Folgen ihrer Fehler sind am teuersten zu beheben. Das Muster ist konsistent: Ein Modernisierungsprojekt wird mit einem Umfang genehmigt, der darauf basiert, was Personen glauben, dass das System tut, statt darauf, was es tatsächlich tut. Das Projekt beginnt. Die Analyse startet. Und nach drei Monaten findet das Team Abhängigkeiten, Datenbankkopplungen und Integrationspunkte, die niemand dokumentiert hat, weil niemand wusste, wonach gesucht werden musste.
Die Forschung von Zend und CGI zu Fehlern bei der Legacy-Modernisierung nennt oberflächliche Bewertungen vor der Modernisierung als einen wesentlichen Treiber für Budgetüberschreitungen und gescheiterte Projekte. Die konkrete Lücke ist meist dieselbe: Architekturannahmen ohne Abhängigkeitsmapping, Datenbankkopplungen, die auf Tabellenebene statt auf Abfrageebene untersucht werden, sowie Sicherheitsprüfungen anhand bekannter Schwachstellen statt anhand der tatsächlichen Angriffsfläche.
Eine gründliche Bewertung für eine Initiative zur Legacy-Modernisierung sollte mindestens Folgendes liefern: ein vollständiges Inventar der Anwendungskomponenten, eine Abhängigkeitskarte einschließlich externer Integrationen und interner Datenflüsse, eine Analyse der Datenbankkopplung, die identifiziert, welche Geschäftslogik in Stored Procedures und welche im Anwendungscode liegt, sowie eine Sicherheitsprüfung, die über CVE-Abgleiche hinausgeht.
Die Bewertung dauert länger, als die meisten Stakeholder warten möchten. Sie kostet einen Anteil des gesamten Modernisierungsbudgets, der erheblich wirkt. Trotzdem ist sie die wichtigste Investition im Programm.
Die Migration von Legacy-Systemen ohne dieses Fundament führt dazu, dass Teams eine Ebene eines Problems modernisieren, während die tiefere Ebene bestehen bleibt.
Best Practices für die Umsetzung und kontinuierliche Iteration der Legacy-Modernisierung
Das ist der Irrtum, den ich im Kontext eines Modernisierungsprojekts am häufigsten sehe: Jemand schließt eine Migrationswelle ab, das neue System läuft, und das Projekt wird für beendet erklärt. Die Retrospektive findet statt. Das Team widmet sich anderen Aufgaben. Und die zwölf Systeme, die nicht zum Umfang der ersten Welle gehörten, sammeln still weiter technische Schulden an.
Erfolgreiche Legacy-Modernisierung behandelt die Umsetzung als erste Iteration eines fortlaufenden Programms, nicht als Abschluss eines einmaligen Projekts. Praktisch bedeutet das:
- Phasenweise Einführung mit Validierungsschleusen vor jeder Welle. Lassen Sie die neue Komponente parallel zum Legacy-System laufen, vergleichen Sie die Ergebnisse und stellen Sie erst um, wenn funktionale Gleichwertigkeit bestätigt ist. - CI/CD-Integration von Anfang an, nicht nachträglich am Ende. Eine Anwendung auf Infrastruktur zu modernisieren, die weiterhin manuelle Bereitstellungsprozesse erfordert, verlagert nur den Engpass. - Klar definierte Verantwortung für jedes System im Portfolio. Eine erfolgreiche Modernisierungsstrategie setzt voraus, dass bekannt ist, wer für die laufende Wartung jeder Anwendung verantwortlich ist, nicht nur, wer die Migration durchgeführt hat. - Den Modernisierungs-Backlog als lebendiges Artefakt behandeln. Neue Systeme werden hinzugefügt, wenn das Unternehmen sie übernimmt. Alte Systeme werden neu bewertet, wenn sich ihre Risikoprofile verändern. Die Modernisierung einer Anwendung ist ein Ereignis. Die Verwaltung des Portfolios ist eine Disziplin.
Der Aufwand, der erforderlich ist, um eine Initiative zur Legacy-Modernisierung wirklich erfolgreich zu machen, dreht sich vor allem um Prozesskontinuität, nicht um technische Umsetzung. Die technischen Teile sind schwierig. Die organisatorische Disziplin, sie als dauerhaft zu behandeln, ist schwieriger.
🤔 Moment.
Die meisten Unternehmen erklären die Modernisierung nach der ersten Migrationswelle für abgeschlossen – und sammeln dann weiterhin technische Schulden in jedem System an, das nicht zum Umfang gehörte. Legacy-Code hört nicht auf zu altern, nur weil ein benachbartes System modernisiert wurde. Das Programm hat keine Ziellinie; das Portfolio schon.
KI und Automatisierung im modernen Workflow zur Legacy-Modernisierung
Die Rolle von KI bei der Modernisierung von Legacy-Anwendungen hat die theoretische Phase hinter sich gelassen. Die Analyse von Deloitte aus dem Jahr 2025 identifiziert drei aufkommende KI-gestützte Ansätze: technische Prozesse neu denken, um technische Schulden abzubauen, den digitalen Kern mit intelligenten Technologien neu gestalten und Geschäftsfähigkeiten mit agentischer KI neu definieren. Das Muster ist bei allen drei Ansätzen gleich: KI als Beschleuniger für Arbeit, die weiterhin von Menschen gesteuert werden muss.
Die konkretesten Belege für den praktischen Nutzen von KI in diesem Bereich stammen aus einer arXiv-Studie zur KI-gestützten COBOL-zu-Java-Modernisierung, die einen KI-unterstützten Ansatz anhand eines Bestands von 50.000 COBOL-Dateien bewertete. Das System erreichte eine Übersetzungsgenauigkeit von 93 % und reduzierte zugleich die Codekomplexität um 35 % sowie die Kopplung um 33 % im Vergleich zu Legacy-Basiscode. Das sind keine trivialen Zahlen für alle, die jemals COBOL manuell lesen mussten, das seit der Clinton-Ära nicht mehr angefasst wurde.
Wo KI in der Anwendungsentwicklung und Modernisierung wirklich hilft:
- Codeanalyse im großen Maßstab. Ein menschliches Team benötigt Wochen, um eine Legacy-Codebasis mit 500.000 Zeilen auf Modernisierungskandidaten zu prüfen. KI-Modelle können Komplexitätsschwerpunkte, Abhängigkeitscluster und risikogekennzeichnete Module innerhalb von Stunden sichtbar machen. Das Ergebnis erfordert weiterhin menschliches Urteilsvermögen, aber der Umfang wird beherrschbar. - Dokumentationserstellung. Legacy-Systeme sind oft im institutionellen Gedächtnis dokumentiert, nicht in Dateien. KI kann Code, Commit-Historien und Fehlerprotokolle analysieren, um nutzbare Dokumentation für Systeme zu generieren, für die keine Dokumentation existiert. - Automatisierte Refactoring-Vorschläge. Nicht autonomes Refactoring – Vorschläge. Dieser Unterschied ist wichtig. KI-gestützte Tools schlagen Änderungen vor; Engineers validieren und genehmigen sie. Die Genauigkeit von 93 % aus der COBOL-Studie ist für ein klar begrenztes Übersetzungsproblem beeindruckend; sie bedeutet nicht, dass KI bei Modernisierungsaufgaben in der Produktion unbeaufsichtigt arbeiten kann.
Wo menschliches Urteilsvermögen unverzichtbar bleibt: Architekturentscheidungen, die Analyse von Kompromissen zwischen Modernisierungsstrategien und jeder Migrationsschritt, der produktive Live-Daten berührt.
Hier werden Automatisierungsplattformen wie Latenode während eines Modernisierungsprogramms praktisch nützlich – nicht als KI-Ersatz für Engineering, sondern als Orchestrierungsinfrastruktur für den Migrationsprozess selbst. In einem Muster, das ich gut funktionieren gesehen habe, verbinden Teams ihr Legacy-System, ihre Staging-Umgebung und ihre Monitoring-Tools über einen einzigen Workflow, der automatisch Beispieltransaktionen abruft, sie durch die Pfade des alten und des neuen Systems leitet und Vergleichszusammenfassungen in einem Team-Channel veröffentlicht. Die Engineers prüfen die Vergleiche. Die Automatisierung übernimmt Abruf und Formatierung. Andernfalls erfordert diese Arbeit 45 Minuten manuelle Einrichtung pro Testlauf – und sie findet tendenziell deutlich seltener statt, wenn dieser Aufwand notwendig ist.
Herausforderungen der Legacy-Modernisierung, die Projekte während der Umsetzung zum Stillstand bringen
Die Herausforderungen der Legacy-Modernisierung erscheinen selten im ursprünglichen Projektplan. Sie treten im vierten Monat auf, wenn das Team mitten in der Migration steckt und der geschätzte Umfang sich als Bruchteil dessen erweist, was tatsächlich vorhanden ist. Ich habe genug Eskalationen von Teams in dieser Situation begleitet, um das Muster zu erkennen.
- Versteckte Abhängigkeiten werden erst nach Beginn der Migration sichtbar
Legacy-Systeme weisen Kopplungen auf, die in Architekturdiagrammen nicht erscheinen, weil niemand Architekturdiagramme erstellt hat. Zwei Legacy-Anwendungen teilen sich plötzlich eine Datenbanktabelle. Ein Batch-Job, der um 2 Uhr nachts läuft, erweist sich als Auslöser für einen kritischen nachgelagerten Prozess. Insbesondere Modernisierungsinitiativen für IBM i sind dafür bekannt: Geschäftslogik, verteilt über RPG-Programme, Stored Procedures und Job-Scheduler, für die niemand eine vollständige Übersicht besitzt.
- Die Komplexität der Datenmigration wird systematisch unterschätzt
Ein bestehendes System auf neue Infrastruktur zu verschieben, ist ein Problem. Die Daten mit umzuziehen – sie zu bereinigen, an das neue Schema anzupassen und nach dem Umzug auf Vollständigkeit zu validieren – ist ein anderes Problem mit einer völlig anderen Kostenstruktur. Die Schätzung für Anwendungsmodernisierungsservices deckt den Code ab. Die Datenarbeit deckt sie selten angemessen ab.
- Kompetenzlücken blockieren die Umsetzung in kritischen Phasen
Eine Re-Architecture-Entscheidung, die in der Planung richtig klingt, erfordert Engineers, die Microservices entwickeln und betreiben, CI/CD-Pipelines implementieren und containerisierte Deployments verwalten können. Diese Fähigkeiten sind nicht gleichmäßig über Teams verteilt. Die Lücke zwischen dem modernisierten System, das der Plan beschreibt, und der Fähigkeit des Teams, es zu entwickeln, tritt meist zum ungünstigsten Zeitpunkt zutage.
- Organisatorischer Widerstand gegen die Umstellung
Geschäftsbereiche, die Workflows rund um die spezifischen Verhaltensweisen der Legacy-Anwendung aufgebaut haben – einschließlich ihrer Eigenheiten und Einschränkungen –, widersetzen sich der Migration auf ein modernisiertes System, das anders funktioniert. Selbst wenn das neue System objektiv besser ist, trägt der geschäftliche Nutzer die Umstellungskosten, nicht das Technologieteam. Diese Asymmetrie erzeugt Reibung, die durch technische Umsetzung allein nicht gelöst werden kann.
- Unterschätzung des Umfangs durch oberflächliche Bewertung
Das ist die grundlegende Ursache, aus der sich die anderen Fehler meist ableiten. Wenn die Bewertung vor der Modernisierung oberflächlich war, basiert der Umfang des Anwendungsmodernisierungsprojekts auf Annahmen statt auf Erkenntnissen. Jede Annahme, die sich als falsch erweist, wird zu einem Änderungsauftrag, einer Verzögerung oder einer aus dem Umfang entfernten Funktion. Jede mittelkomplexe Softwareanwendung wird in der ursprünglichen Schätzung mindestens einige falsche Annahmen enthalten. Die Frage ist, wie viele.
Modernisierungslösungen, die diese Risiken von Anfang an adressieren – indem sie Abhängigkeitsmapping und Datenmigrationsanalyse in das Bewertungsbudget aufnehmen, Teamfähigkeiten vor der Festlegung auf die gewählte Strategie validieren und den Umstellungsprozess unter Einbeziehung der Geschäftsbereiche gestalten –, liefern in der Regel Ergebnisse. Diejenigen, die diese Schritte überspringen, erzeugen meist um den vierten Monat herum Support-Tickets mit der Frage, wie sich ein Umfang wiederherstellen lässt, der von Anfang an nie richtig abgegrenzt wurde.
Dort beginnt das Ticket in der Regel.
