Ein undokumentiertes Legacy-System verstehen: Architektur-Rekonstruktion mit KI-Agenten vor der Modernisierungsentscheidung

Die Ausgangslage ist in vielen Häusern dieselbe. Das Kernsystem ist zwanzig Jahre alt. Zwei Personen kennen es, eine davon geht nächstes Jahr in Rente. Die Dokumentation beschreibt den Stand von vor zehn Jahren. Und jetzt soll entschieden werden, ob das System weiterläuft, modernisiert oder ersetzt wird. Die Checkliste für ein Architektur-Review verlangt eine Systemübersicht mit Schnittstellen und Datenflüssen. Die gibt es nicht.

Bis 2024 hieß die Antwort darauf: Interviews, Code lesen, Datenbankschema durchgehen, Wochen bis Monate. KI-Coding-Agenten verändern diesen Schritt. Sie lesen eine Codebasis in Stunden, folgen Aufrufketten über Projektgrenzen hinweg und formulieren, was ein Modul tut. Sie ersetzen damit das Lesen, nicht das Urteil. Dieser Artikel beschreibt, wie ich diese Werkzeuge vor einer Modernisierungsentscheidung einsetze, was dabei herauskommt und wo die Grenzen liegen.

Was am Ende vorliegen soll

Das Ziel ist eine Beschreibung des Systems, die eine Entscheidung trägt. Dazu gehören sieben Arbeitsergebnisse.

1. Eine Modul- und Abhängigkeitskarte. Welche Projekte, Bibliotheken, Datenbanken, gespeicherten Prozeduren, Batchjobs und Dateischnittstellen gibt es, und wer ruft wen auf?
2. Die Datenflüsse nach außen. Welche Systeme liefern Daten, welche empfangen sie, über welche Formate und Protokolle?
3. Eine Liste der fachlichen Regeln je Modul mit Fundstelle im Code und einer Einschätzung, wie sicher die Deutung ist.
4. Die Änderungs-Hotspots. Welche Teile wurden in den letzten Jahren am häufigsten geändert, und wie komplex sind sie? Das ergibt sich aus der Versionsgeschichte, sofern sie den Umzug zwischen Repositorys überlebt hat.
5. Die Wissensrisiken. Welche Module hat in den letzten Jahren nur eine Person angefasst?
6. Tote Pfade, abgeschaltete Funktionen und Schalter in der Konfiguration, die niemand mehr zuordnen kann.
7. Sicherheitsauffälligkeiten wie fest eingetragene Zugangsdaten, veraltete Bibliotheken oder ungeschützte Schnittstellen.

Die ersten beiden Ergebnisse füllen direkt die Review-Checkliste. Das fünfte und das siebte sind dieselben Befunde, die in einer Technical Due Diligence als rote Findings gelten. Wer diese Liste vor einer Transaktion selbst erstellt, kennt seine Schwachstellen vor dem Käufer.

Das Vorgehen in fünf Schritten

Schritt 1: Zugang und Datenschutz klären

Bevor ein Agent eine Zeile liest, ist geklärt, welcher Code in welches Werkzeug darf. Enterprise-Verträge der großen Anbieter schließen das Training auf Kundendaten aus. Für Einzellizenzen gilt das nicht automatisch. Das gehört schriftlich festgehalten. Zugangsdaten, Zertifikate und Produktionsdaten werden vorher aus dem Arbeitsbereich entfernt. Testdaten mit echten Kundennamen sind in alten Systemen häufig und gehören ebenfalls nicht in die Analyse. Der Agent arbeitet auf einer eigenen Kopie des Repositorys, im Lesemodus des Werkzeugs und ohne Zugangsdaten für Produktionsdatenbanken. Dass er nichts ändert, steht dann nicht nur im Auftrag. In regulierten Häusern ist der Anbieter des Werkzeugs ein IKT-Dienstleister im Sinne der DORA-Verordnung und gehört in das Informationsregister. Was eine EU-Region beim Datenschutz leistet und welche Modelle dort verfügbar sind, steht im Artikel zu Azure AI Foundry.

Schritt 2: Inventar automatisiert erstellen

Der erste Durchlauf ist mechanisch. Der Agent liest Projektdateien, Paketreferenzen, Konfigurationen, Datenbankskripte und Deployment-Beschreibungen und erzeugt daraus die Abhängigkeitskarte. Für ein .NET-System heißt das: Lösungsdateien, Projektreferenzen, Verbindungszeichenfolgen, registrierte Dienste, geplante Aufgaben. Diese Karte ist die Modulliste für Schritt 3 und bei großen Codebasen später die Orientierung für den Agenten.

Schritt 3: Fachliche Regeln je Modul erklären lassen

Jetzt arbeitet der Agent Modul für Modul. Die Aufgabe lautet jedes Mal gleich: Erkläre, was dieses Modul fachlich tut, liste jede Regel mit Fundstelle, markiere, wo Du unsicher bist, und ändere nichts. Eine Regel ohne Datei und Zeile lässt sich nicht prüfen und ist für die Entscheidung wertlos.

Ein Beispiel für eine solche Anweisung:

Analysiere das Projekt Billing. Beschreibe in Alltagssprache, welche fachlichen Regeln hier umgesetzt sind.
Für jede Regel: Datei und Zeile, beteiligte Datenbanktabellen, Herkunft der Eingaben.
Markiere Regeln, deren Zweck Du aus dem Code nicht sicher ableiten kannst.
Nimm keine Änderungen am Code vor.

Die Ergebnisse sind Kandidaten. Ein Agent erkennt in der Regel, dass ein Rabatt ab einer bestimmten Vertragssumme gewährt wird. Warum die Grenze bei genau diesem Betrag liegt und ob sie noch gilt, weiß nur der Fachbereich.

Schritt 4: Mit Fachbereich und Entwicklern validieren

Die Regelliste geht in einen Workshop mit dem Fachbereich und den verbliebenen Kennern des Systems. Jede Regel bekommt eine von drei Markierungen: bestätigt, falsch oder unbekannt. Die unbekannten sind die wertvollsten Funde. Sie zeigen, wo das System Entscheidungen trifft, die niemand mehr verantwortet. Diese Stellen sind in einer Modernisierung am teuersten, weil sie eine fachliche Entscheidung brauchen, bevor Code entsteht.

Schritt 5: In die Entscheidung überführen

Aus den validierten Ergebnissen entstehen die Unterlagen für die Entscheidung. Dazu gehören die gefüllte Review-Checkliste, eine Risikobewertung je Modul, die Liste der Schnittstellen mit Partnern und Kandidaten für einen abgegrenzten Pilot. Dazu kommen die Zahlen, die der Business Case braucht, etwa die Zahl der Schnittstellen und der Umfang ungetesteter Logik.

Wo die Grenzen liegen

Fünf Grenzen habe ich in Projekten regelmäßig erlebt.

1. Plausible Fehldeutungen. Ein Agent beschreibt eine Regel überzeugend und falsch, weil der Code zwei Sonderfälle weiter oben überschreibt. Ohne Fundstelle und Prüfung im Code bleibt das unentdeckt.
2. Logik in der Datenbank. Gespeicherte Prozeduren, Trigger und Sichten enthalten in alten Systemen oft die Hälfte der Fachlogik. Der Agent braucht die Datenbankskripte oder Lesezugriff auf das Schema, sonst fehlt diese Hälfte.
3. Verhalten zur Laufzeit. Konfigurationsschalter, mandantenabhängige Pfade und datengetriebene Verzweigungen sieht man erst im Betrieb. Protokolle aus der Produktion ergänzen die Code-Analyse.
4. Wissen außerhalb des Codes. Die Excel-Tabelle neben dem System, der manuelle Monatsabschluss und die Absprache mit dem Partner stehen in keinem Repository. Dafür bleiben Interviews.
5. Umfang. Sehr große Codebasen übersteigen das Kontextfenster eines Agenten. Dann arbeitet man je Modul und gibt dem Agenten die Abhängigkeitskarte aus Schritt 2 als Orientierung mit.

Die Werkzeugkosten sind dabei der kleinste Posten. Teuer ist die Zeit des Fachbereichs in der Validierung. Sie bleibt gleich, wird aber auf die Stellen gelenkt, an denen Unsicherheit besteht.

Was das für die Entscheidung bringt

Der Unterschied zur klassischen Analyse liegt in Tempo und Vollständigkeit. Eine Bestandsaufnahme eines undokumentierten Kernsystems, die früher Wochen bis Monate dauerte, dauert mit Agenten in meinen Projekten zwei bis vier Wochen. Darin enthalten ist der Workshop mit dem Fachbereich, der den Termin meist bestimmt. Vor allem aber lässt sie sich vollständig machen. Die Modulliste aus Schritt 2 wird abgearbeitet, und jedes Modul bekommt denselben Auftrag. Ein Mensch lässt das langweilige Modul gern aus, der Agent bekommt es als nächsten Auftrag. Was außerhalb des Repositorys läuft, etwa ein Job in der Aufgabenplanung des Servers, sieht er nicht. Dafür gibt es die Betriebsdaten aus der dritten Grenze.

Für die Entscheidung heißt das: Die Spannen im Business Case beruhen auf gezählten Schnittstellen und einer gemessenen Testlücke. Der Pilot wird dort gewählt, wo die Karte wenige Abhängigkeiten zeigt. Und die Wissensrisiken sind benannt, bevor die betroffene Person das Haus verlässt.

Wie es nach der Analyse weitergeht, zeigt der Praxisbericht zur WebForms-Modernisierung mit Claude Code. Dort beginnt jedes Modul mit derselben Analyse, bevor Code entsteht. Wie ein Team solche Werkzeuge über den Einzelfall hinaus einführt, beschreibt der Artikel zum KI-Enablement im Engineering-Team.

Nächster Schritt

Ein Architektur-Review nutzt dieses Vorgehen im Schritt „System und Betrieb verstehen" und liefert Karte, Risikobewertung und Handlungsoptionen als Ergebnisbericht. Wenn das System Teil einer Beteiligung oder Übernahme ist und der Verkäufer Zugriff auf den Code gewährt, läuft dieselbe Analyse in der Technical Due Diligence. Die Review-Checkliste hilft Ihnen, vorab zu sammeln, was bereits vorhanden ist.