Warum AI die Legacy-Modernisierung neu definiert

von Michael Heß, Area Manager Software Development

Das klingt banal. Ist es aber nicht. In den meisten Unternehmen steckt das eigentliche Wissen über geschäftskritische Systeme nämlich nicht in der Dokumentation, sondern in den Köpfen von drei Leuten, die seit y2k dabei sind. Und einer davon geht nächstes Jahr in Rente.

Modernisierung war deshalb immer ein organisatorisches Risiko. Nicht primär ein technisches. Wer ein System erneuern will, das er nicht vollständig versteht, trifft Entscheidungen auf unsicherer Basis. Das Ergebnis sind überdimensionierte Projekte, politische Absicherung und Stillstand.

AI verschiebt den Engpass. Der Fokus liegt nicht mehr auf monatelanger manueller Rekonstruktion, sondern auf schnellerer, reproduzierbarer Systemexploration. Die Entscheidungen bleiben zwar politisch und wirtschaftlich, basieren aber seltener auf Bauchgefühl.

Und das verändert alles, was danach kommt.

Als Legacy-Modernisierung wird die systematische Erneuerung bestehender IT-Systeme bezeichnet, um deren Wartbarkeit, Sicherheit und Veränderbarkeit wiederherzustellen. So weit die saubere Definition.

Die Realität sieht jedoch anders aus.

In der Praxis bedeutet Legacy-Modernisierung monatelange Analysephasen, in denen Teams versuchen, die Funktionsweise eines Systems zu rekonstruieren. Die Dokumentation fehlt entweder, ist veraltet oder beides. Eine Preisberechnung mit 14 Sonderfällen, die nur ein einziger Entwickler erklären kann. Abhängigkeiten, die erst im Betrieb sichtbar werden. Und Stakeholder, die sich nicht einig sind, ob man das System überhaupt anfassen sollte.

Das Muster ist fast immer dasselbe: Die technische Komplexität ist beherrschbar. Was Projekte ausbremst, ist fehlende Transparenz – über den tatsächlichen Zustand des Systems, über die realen Abhängigkeiten und über die wirtschaftlichen Auswirkungen einzelner Entscheidungen.

Wer nicht weiß, was er hat, kann nicht sinnvoll entscheiden, was er daraus macht.

Wenn eine Legacy-Modernisierung offensichtlich nötig ist, warum wird sie dann so selten durchgeführt? In fast jedem Projekt tauchen drei Ursachen auf.

Das größte Risiko bei Legacy-Systemen geht nicht von der veralteten Technologie aus. Es ist das verlorene Wissen. Systemlogik, die nie dokumentiert wurde. Geschäftsregeln, die nur im Code existieren und dort auch nur implizit. Oder Schnittstellen, deren Verhalten niemand mehr erklären kann, weil die Person, die sie programmiert hat, seit fünf Jahren im Ruhestand ist.

Und der Code ist selten die ganze Wahrheit. In vielen Legacy-Landschaften steckt entscheidendes Wissen in Datenbank-Schemata, Stored Procedures, Batch-Jobs, Konfigurationen und im Laufzeitverhalten. Wer nur den Quellcode liest, sieht daher bestenfalls die Hälfte.

Legacy ist oft nicht alt. Legacy ist undokumentiert.

Monolithen sehen von außen stabil aus. Innen sind sie wie gewachsene Landschaften: Schicht um Schicht, Workaround auf Workaround, Sonderlogik für einen Kunden, der längst abgewandert ist. Diese Komplexität ist nicht böswillig entstanden. Sie ist das Ergebnis von Jahren pragmatischer Entscheidungen unter Zeitdruck.

Das Problem ist jedoch, dass niemand die tatsächliche Tragweite einer Änderung kennt. Also ändert man lieber nichts.

Fast jede Modernisierung ist ein Großprojekt. Großprojekte erzeugen Governance. Diese erzeugt wiederum Abstimmungsrunden, Lenkungsausschüsse und Risikoanalysen der Risikoanalysen. Am Ende steht ein Projektplan, der so konservativ ist, dass das System de facto konserviert wird.

Wenn ein System „zu kritisch zum Anfassen“ ist, dann wird es mit jedem Monat kritischer. Das ist kein Paradoxon. Das ist der Normalfall.

Die naheliegende Erwartung lautet: AI automatisiert die Modernisierung. Code rein, moderner Code raus. Das klingt gut in Keynotes. In der Praxis ist es jedoch unsinnig.

Der tatsächliche Hebel liegt woanders.

AI verändert nicht in erster Linie, wie modernisiert wird. AI verändert, auf welcher Grundlage Entscheidungen getroffen werden. Das ist ein wesentlicher Unterschied.

Bisher stand am Anfang jeder Modernisierung eine Phase der Unsicherheit: Was tut das System genau? Welche Abhängigkeiten existieren? Was passiert, wenn wir hier eingreifen? Die Antworten kamen, wenn überhaupt, aus Workshops, Interviews und manueller Code-Analyse. Oft war das Ergebnis eine teure Annäherung an die Wahrheit.

AI dreht diese Gleichung um. Nicht, weil sie allwissend ist. Sondern weil sie – bei zugänglicher Codebasis und vorhandenen Artefakten – in Tagen das leisten kann, wofür Teams bisher Monate gebraucht haben: Sie kann Systeme lesen, Zusammenhänge extrahieren und Muster erkennen.

Das reduziert nicht nur den Aufwand. Es verändert auch die Entscheidungsqualität. Wer ein System versteht, bevor er es anfasst, plant anders. Budgetiert anders. Priorisiert anders. Und genau das ist der Unterschied zwischen einem Modernisierungsprojekt, das im Lenkungsausschuss versandet, und einem, das seine Ziele erreicht.

Eine Strategie ist wichtig. Aber irgendwann muss es konkret werden. Was genau kann AI bei der Legacy-Modernisierung leisten, wodurch unterscheidet sie sich von bestehenden Werkzeugen und wo liegen ihre Grenzen?

Static-Analysis-Tools und Architektur-Scanner sind bereits seit Jahren auf dem Markt erhältlich. Sie liefern Abhängigkeitsgraphen und Metriken. Was sie jedoch nicht leisten können, ist die semantische Rekonstruktion von Fachlogik. Sie können also nicht die Frage beantworten, was ein System tut und warum, sondern nur, wie es zusammenhängt.

AI kann hingegen Quellcode lesen, analysieren und in verständliche Zusammenhänge übersetzen. Das bedeutet konkret, dass Geschäftslogik extrahiert werden kann, die seit Jahren nur im Code existiert. Sie können Schnittstellen-Verhalten beschreiben, das kein Diagramm mehr abbildet. Sie können Dokumentation generieren, wo keine existiert. Testszenarien vorschlagen, die auf tatsächlichem Systemverhalten basieren und nicht auf Annahmen.

Neu ist nicht der Graph an sich. Neu ist, dass Teams ihn schneller erzeugen, erklären und mit Fachkontext anreichern können – inklusive Quellenhinweisen und benannten Unsicherheiten.

Das ersetzt keine Entwickler:innen. Aber es erspart Wochen manueller Analyse, die bisher am Anfang jedes Projekts standen und deren Ergebnisse trotzdem lückenhaft waren.

Eine der hartnäckigsten Herausforderungen bei Legacy-Systemen ist: Niemand kann beziffern, wie komplex ein Eingriff tatsächlich ist. Entscheidungen werden auf Basis von Erfahrung und Bauchgefühl getroffen. Manchmal richtig. Oft genug aber auch nicht.

AI ermöglicht etwas, das vorher schlicht zu aufwändig war: systematische Impact-Analysen über die gesamte Codebasis. Es erstellt Abhängigkeitsgraphen, die nicht manuell gepflegt werden müssen. Risiko-Scoring auf Modulebene. Und es ermöglicht die Erstellung früher Hypothesen zu Änderungsauswirkungen, die durch Tests und Telemetrie validiert werden, bevor auch nur eine Zeile Produktivcode angefasst wird.

Messbarkeit statt Intuition. Das klingt nüchtern. Für Projektverantwortliche ist es jedoch eine Befreiung.

Eine inkrementelle Modernisierung war auch vor AI möglich – und oft die bessere Idee. Das Problem war jedoch, dass jeder einzelne Schritt eine erneute Analyse, erneutes Kontextwissen und erneute Absicherung erforderte. Die Transaktionskosten pro Inkrement waren so hoch, dass sich kleine Schritte selten lohnte. Also wurde entweder alles auf einmal gemacht – oder gar nichts.

AI verändert diese Rechnung. Wenn das Systemverständnis einmal aufgebaut ist, bleibt es verfügbar: Es ist reproduzierbar, aktualisierbar und teilbar. Testszenarien lassen sich für jedes Modul gezielt generieren und nicht pauschal. Die Auswirkungen einer Änderung lassen sich vorab abschätzen, statt sie erst im Betrieb zu entdecken.

Das bedeutet, dass die Kosten pro Modernisierungsschritt sinken. Damit wird der eigentlich immer richtige Weg gangbar: schrittweise, validiert, ohne Alles-oder-nichts.

Die vorherigen Schritte – Systemwissen rekonstruieren, Komplexität messen und Modernisierung wirtschaftlich skalierbar machen – münden in ein strukturiertes Assessment. Es entsteht kein Foliensatz mit Empfehlungen, sondern vier handlungsfähige Artefakte.

Wissenskarte: Ein dokumentierter Überblick über Geschäftslogik, Fachregeln und Systemverhalten, extrahiert aus Code, Konfiguration und Datenflüssen. Das implizite Wissen, das vorher nur in einzelnen Köpfen existierte, wird explizit und teilbar.

Maintainability Map: Eine strukturierte Bewertung der Wartbarkeit: Wie verständlich ist der Code? Wie gut ist er dokumentiert? Wie hoch ist die Kopplung? Wo entstehen die meisten Aufwände bei Änderungen? Das macht Wartbarkeit von einem vagen Gefühl zu einer steuerbaren Größe.

Risiko-Register: Eine systematische Erfassung der Risiken über alle Ebenen hinweg ist entscheidend: von Sicherheitslücken und Code-Qualität über Abhängigkeiten von Einzelpersonen bis hin zu Makro-Risiken wie der Verfügbarkeit von Fachkräften für den jeweiligen Technologie-Stack.

Strategic Evolution Roadmap: Eine gewichtete Roadmap macht transparent, welche Modernisierungspfade möglich sind und welchen Hebel sie haben. Es geht nicht um Einzelempfehlungen, sondern um eine Entscheidungsgrundlage mit Optionen und der Möglichkeit, in Szenarien zu denken.

Lange Zeit wurde die Legacy-Modernisierung als notwendiges Übel betrachtet. Sie war aufwändig, riskant und schwer zu vermitteln. Das lag jedoch nicht an fehlender Technik, sondern an fehlender Transparenz.

AI ändert das. Nicht durch Automatisierung auf Knopfdruck. Sondern indem sie das sichtbar macht, was bisher im Verborgenen lag: Systemwissen, Abhängigkeiten, Risiken und Hebel. Was vorher Monate manueller Analyse kostete, liegt nun innerhalb weniger Tage vor. Was vorher Bauchgefühl war, wird zur belastbaren Entscheidungsgrundlage.

Das macht die Legacy-Modernisierung nicht einfacher. Aber sie wird steuerbar. Damit wird sie von einem Projekt, das man vor sich herschiebt, zu einer strategischen Option, die man bewusst nutzt.

Wer seine Systeme versteht, kann sie verändern. Wer sie verändern kann, kann innovieren. Wer sich heute um seine technischen Schulden kümmert, programmiert nicht nur bessere Software, sondern legt auch den Grundstein für alles, was als Nächstes kommt.

Transparenz ist die Voraussetzung für jede gute Entscheidung. AI liefert sie. Was daraus wird, entscheiden Menschen.

Ist der Einsatz von AI bei Legacy-Modernisierung sicher?

Ja – wenn er kontrolliert erfolgt. AI liefert Analysen, Vorschläge und Entwürfe. Sie trifft keine autonomen Entscheidungen und deployt keinen Code. Jede Empfehlung durchläuft menschliche Prüfung und bestehende Governance-Prozesse. Das Risiko liegt nicht in der AI. Es liegt darin, sie ohne klare Leitplanken einzusetzen.

Ersetzt AI Entwickler?

Nein. AI verstärkt Entwickler. Sie übernimmt die zeitintensiven, repetitiven Analyseschritte, die bisher den Großteil der frühen Projektphasen verschlungen haben. Die Verantwortung für Architekturentscheidungen, fachliche Bewertung und Umsetzung bleibt beim Menschen. Produktivität steigt. Urteilsvermögen bleibt unersetzbar.

Funktioniert das auch bei COBOL, RPG oder sehr alten Technologie-Stacks?

Ja, sofern der Quellcode strukturiert vorliegt und zugänglich ist. Die Herausforderung liegt weniger im Alter der Technologie als in der Qualität der verfügbaren Daten. Ein sauber organisiertes COBOL-System ist für AI-Analyse besser geeignet als ein chaotisches Java-Projekt aus 2015.

Wie aufwändig ist der Einstieg?

Geringer als erwartet. Ein erstes Assessment in Form einer Codebase-Analyse, eines Abhängigkeitsmappings und einer Risikobewertung liefert innerhalb weniger Tage belastbare Ergebnisse. Es ist kein Großprojekt und es ist keine monatelange Vorstudie nötig. Wer wissen will, wo er steht, kann das schnell herausfinden. Shameless Plug: 7P bietet ein solches Assessment an. Es ist der ideale Einstieg in die Überlegungen zur Modernisierung.