Auf ein Gespräch mit dem Altsystem: KI-gestützte Codeanalyse für Migrationsprojekte

Executive Summary: Der Aufwand einer Migration wird üblicherweise geschätzt, bevor im Detail bekannt ist, wie ein Altsystem tatsächlich funktioniert. KI schafft hier Abhilfe: Als Knowledge Graph aufbereitet ist auch eine über Jahrzehnte gewachsene Codebasis für ein Sprachmodell befragbar. Annahmen über Logiken und Sonderfälle werden damit systematisch prüfbar, und Schätzungen werden robuster. Gleichzeitig werden aufwändige und teure Korrekturen in späteren Projektphasen vermieden.

Niemand kennt das ganze System

Irgendwann kommt der Moment, in dem ein Altsystem abgelöst werden muss. Die Gründe sind altbekannt: regulatorischer Druck, steigende Wartungskosten, ein Nachfolgesystem, das schon wartet. Die Entscheidung für ein Migrationsprojekt ist gefallen, und genau zu diesem Zeitpunkt stellt sich häufig die Frage: Was tut dieses System eigentlich genau?

Jeder im Haus kennt einen Teil der Antwort. Aber das Wissen darüber, wie das System als Ganzes tatsächlich funktioniert, das existiert meist nicht vollständig oder ist nur umständlich zusammenzusetzen. Zu viel ist über die Jahre an Anpassungen hinzugekommen.

Hier beginnt das eigentliche Risiko einer Migration: Der Aufwand wird geschätzt, bevor vollständig bekannt ist, was migriert werden muss. Jede Schätzung enthält damit Annahmen über Logiken und Sonderfälle im Altsystem, die bislang nicht systematisch überprüft werden konnten.

Die Grenze des Lesbaren hat sich verschoben: Sprachmodelle erschließen Code

Diese systematische Prüfung ist möglich, war bisher aber schlicht in der Zeit, die für ein Migrationsprojekt zur Verfügung steht, nicht machbar. Ein Bestandssystem, welches über Jahrzehnte gewachsen ist, umfasst häufig mehrere Millionen Zeilen Code. Wer sie durcharbeitet, hat am Ende Notizen, aber keine Struktur, die das Wissen einfach zugänglich macht.

Die Grenze dessen, was innerhalb der Projektlaufzeit lesbar ist, hat sich in den letzten Jahren verschoben. Sprachmodelle erschließen Code in einer Größenordnung, die früher nicht praktikabel war, vorausgesetzt, man übergibt ihn nicht als Text, sondern in einer Form, die sowohl seine Struktur abbildet, als auch anschließend eine token-schonende Verarbeitung ermöglicht.

Ob eine Sonderbehandlung im Code eine bewusste Produktentscheidung war oder ein Workaround aus einem alten Release, den längst niemand mehr braucht, steht dort nicht. Der Code zeigt jedes Verhalten, aber nicht, welches davon so gewollt war. Diese Unterscheidung ist der Grund, warum am Ende der Analyse weiterhin eine Einordnung von Fachexperten steht. KI hilft dabei Themen aufzubereiten und macht Dinge sichtbar. Die letztendliche Entscheidung bleibt beim Menschen.

Vom Quellcode zum abfragbaren Graphen

Der Ausgangspunkt ist der Quellcode, so wie er vorliegt. Es gibt keine Vorstufe, in der aufgeräumt oder umstrukturiert wird, sonst würde das Verfahren nur unter Bedingungen funktionieren, die in Migrationsprojekten selten vorliegen.

Wir verarbeiten den Code und bauen aus den Syntaxbäumen einen Graphen, in dem Module, Funktionen und ihre Abhängigkeiten als Knoten und Kanten liegen. Was vorher als Text über Tausende Dateien verteilt war, ist damit abfragbar: ein Knowledge Graph über die Codebasis.

Auf diesem Graphen laufen die Abfragen. Ein Sprachmodell kann ihn durchsuchen und damit den Einstieg finden, für den es vorher lange Systemkenntnis brauchte: wo eine Regel definiert ist und welche Module sie einbinden. Was danach vom Menschen noch zu lesen ist, sind nur noch einzelne Stellen und nicht mehr die gesamte Codebasis. Produktdaten und Konfiguration liegen in eigenen Dateien neben dem Graphen und werden in der KI-Analyse zusätzlich berücksichtigt. Die darin enthaltenen Informationen gehen so in die Antwort ein.

Der Graph allein löst aber noch kein Problem. Er macht den Code und seine Zusammenhänge anders zugänglich. Der Mehrwert entsteht erst im Dialog mit dem Altsystem: indem wir über den Graphen gezielt die richtigen Fragen stellen.

Das Altsystem selbst ist für uns neu, die typischen Problemstellen sind es nicht. Aus jahrzehntelanger Migrationserfahrung wissen wir, wo Sonderfälle zu erwarten sind und welche Fragen für eine belastbare Aufwandsschätzung beantwortet werden müssen.

Ein Blick in die Werkstatt

Wie sieht der Einsatz eines solchen Graphen in der Praxis aus? In einem laufenden Projekt hätte eine Migrationsregel einen Teil des Bestands falsch eingeordnet. Der Grund: Ein Feld, das den Umgang mit Auszahlungen steuert, trägt in der Konfiguration Klartextwerte, die sich wie eine Tarifart lesen. Wer die Regel daraus ableitet, migriert nach einem Kriterium, das es fachlich nicht gibt. Der Quellcode zeigt, was das Feld tatsächlich steuert, und die Regel wurde korrigiert, bevor sie im Zielsystem stand.

Gefunden wurde die Abweichung, weil beide Quellen in derselben Analyse nebeneinander lagen und jemand nach Widersprüchen gefragt hat. Beim menschlichen Lesen fällt so etwas nicht auf, dafür ist die Codebasis zu groß. Was im Altsystem tatsächlich gilt, liefert die Analyse inklusive Fundstellen im Code. Offen bleibt die fachliche Entscheidung, welches Kriterium im Zielsystem greifen soll. Diese Entscheidung kann der Fachbereich nun frühzeitig auf Basis eines geprüften Befundes treffen, und vermeidet so aufwändige Korrekturen in einer späten Projektphase.

Das System, um das es in diesem Projekt geht:

• Codebasis: rund 32.500 Dateien, über zwölf Millionen Zeilen Code, gewachsen über Jahrzehnte
• Größte einzelne Datei: knapp 378.000 Zeilen Code
• Dauer bis zum abfragbaren Stand: gut drei Stunden, einmalig, auf einer virtuellen Maschine mit zwei Prozessorkernen

Human-in-the-Loop: Kontrolle und Abnahme

Die menschliche Kontrolle darf jedoch nicht eingespart werden. In einem Fall lieferte die Analyse z. B. die richtige Antwort aus dem falschen Grund: Das Werkzeug erkennt zuverlässig, wo etwas definiert ist und welche Bausteine zusammen benutzt werden, aber nicht in jedem Fall, wer wen aufruft. Diese Nähe im Graphen wurde als Abhängigkeit gelesen. Genau solche Fehler sind gefährlich. Sie fallen nicht durch offensichtlich falsche Antworten auf, sondern verstecken sich hinter plausiblen Ergebnissen. Die Lösung hierfür liegt im Dialog über den Graphen, die Antworten liefern die Vorlage zur Abnahme durch den Kunden.

Der Werkstattblick zeigt: Die Nutzung dieser neuen Technologie ist work in progress. Nicht alles ist erschlossen, aber die Lernkurve ist steil. Kundenspezifische Anpassungen sind z. B. bisher nicht einbezogen, und die bisherigen befragbaren Graphen basieren auf C++- und Java-Codebasen. Für alte Programmiersprachen wie etwa COBOL steht allerdings bereits ein technischer Durchstich zur Verfügung, die Methodik verspricht also auch dort zu tragen.

Erfahrung bleibt der Schlüssel

Werkzeuge zur Codeanalyse gibt es inzwischen einige. Sie können Strukturen, Abhängigkeiten und Auffälligkeiten sichtbar machen. Ob daraus etwas Brauchbares entsteht, hängt aber davon ab, welche Fragen man an das System stellt. Der am stärksten vernetzte Knoten in unserem Graphen ist eine Funktion zur Speicherverwaltung. Nach der Zahl ihrer Verbindungen steht sie vor jedem fachlichen Modul. Für die Migration ist sie trotzdem bedeutungslos.

Das Wissen bezüglich Qualität, Zuverlässigkeit und Effizienz der eingesetzten KI-Verfahren allein reicht nicht aus, um KI-basierte Migrationsverfahren erfolgreich umzusetzen. Genauso bedeutend ist das Wissen, wo sich in einem Lebensversicherungsbestand die teuren Stellen verbergen. Dieses Wissen haben wir durch mehr als 25 Jahre Migrationserfahrung bei uns im Haus. Beides in einem Team macht den Unterschied zwischen einer reinen Codeanalyse und einer belastbaren Migrationsvorstudie. Eine Aufwandsschätzung wird nicht dadurch belastbar, dass mehr bekannt ist, sondern dadurch, dass solche Fragen gestellt werden, bevor jemand eine Zahl nennt.

Die Frage nach Widersprüchen zwischen Konfiguration und Quellcode stellt niemand, der Code liest. Sie stellt jemand, der weiß, wie teuer eine falsch eingeordnete Bestandsgruppe wird, wenn sie erst im Zielsystem auffällt. Beantwortet hat diese Frage das Sprachmodell. Gestellt hat sie ein Mensch.