Legacy-Systeme mit KI-Agenten modernisieren // nh labs

Das System, das niemand anfassen will

In fast jedem Unternehmen, das älter als zehn Jahre ist, gibt es ein System, über das man nur mit gesenkter Stimme spricht. Es läuft. Es verbucht Zahlungen, berechnet Prämien, verwaltet Bestände – seit fünfzehn, zwanzig, manchmal dreißig Jahren. Und niemand versteht es mehr vollständig. Die Autoren sind längst in Rente oder bei anderen Firmen. Die Dokumentation wurde entweder nie geschrieben oder beschreibt eine Version, die es seit 2011 nicht mehr gibt. Tests? Ein paar, an den Rändern, für die harmlosen Teile. Der Kern – die Millionen Zeilen COBOL, das aufgeblähte Java aus der Frühzeit von J2EE, der PHP-Monolith, der mit dem Geschäft gewachsen ist wie ein Korallenriff – ist eine Blackbox, die tut, was sie soll, solange man sie in Ruhe lässt.

Jeder weiß, dass dieses System ein Risiko ist. Es blockiert neue Features, es kettet das Unternehmen an eine sterbende Technologie, es braucht Spezialisten, die man kaum noch findet. Trotzdem wird es Jahr für Jahr nicht modernisiert. Nicht aus Trägheit, sondern aus einer völlig rationalen Rechnung: Die Modernisierung war immer teurer als der Schmerz, mit dem Alten weiterzuleben.

Und diese Rechnung stimmte. Wer ein Legacy-System ablösen will, muss zuerst verstehen, was es tut – nicht ungefähr, sondern exakt, bis in jeden Sonderfall, den irgendein Sachbearbeiter vor zwölf Jahren telefonisch angefordert hat und der seither still im Code lebt. Dieses Verständnis zu rekonstruieren, ohne Tests, ohne Doku, ohne die Originalautoren, war eine archäologische Grabung, die Monate dauerte und trotzdem lückenhaft blieb. Jede Migration war deshalb eine Wette: Man schreibt neu, was man nur halb versteht, und hofft, dass die andere Hälfte nicht die war, an der das halbe Geschäft hing.

Was sich an der Rechnung geändert hat

Genau an dieser Stelle setzen KI-Agenten an – und zwar nicht dort, wo die Werbung sie hinstellt. Der Wert liegt nicht darin, dass ein Modell schnell neuen Code schreibt. Der Wert liegt darin, dass es alten Code im großen Maßstab lesen und erklären kann.

Das ist die Fähigkeit, an der die klassische Modernisierung immer scheiterte. Ein Agent kann sich durch 400.000 Zeilen einer fremden Sprache arbeiten und in Stunden herausschreiben, was ein Team von Menschen in Wochen mühsam zusammengetragen hätte: Welche Module rufen einander auf? Wo wird diese eine Prämienformel berechnet, und an welchen sieben Stellen wird sie aufgerufen? Welche Datenbanktabelle ist toter Ballast und welche das Herzstück? Was tut dieser 900-Zeilen-Batchjob eigentlich, den seit 2014 niemand mehr geöffnet hat?

Konkret verschiebt KI vier Kostenblöcke, die Migration bisher unwirtschaftlich machten:

Verständnis großer Codebasen. Ein Agent liest und fasst zusammen, kartiert Abhängigkeiten, zeichnet den Datenfluss nach. Aus der monatelangen Archäologie werden Tage – und das Ergebnis ist vollständiger, weil kein Mensch die Geduld hätte, jeden toten Pfad zu verfolgen.
Die fehlenden Tests. Und das ist der eigentliche Hebel: Ein Agent kann rund um ungetesteten Code einen Test-Harness generieren, der das aktuelle Verhalten festschreibt – noch bevor eine einzige Zeile migriert wird. Genau das Sicherheitsnetz, das vorher fehlte.
Idiome übersetzen. COBOL-Konstrukte auf Java-Muster abbilden, eine prozedurale PHP-Struktur in etwas Testbares überführen – die stupide, fehleranfällige Fleißarbeit, an der Menschen ermüden und Flüchtigkeitsfehler machen.
Abhängigkeiten kartieren. Was hängt an was? Ein Agent findet die impliziten Kopplungen, die kein Diagramm je verzeichnet hat.

Die Ökonomie hat sich also tatsächlich verändert. Migrationen, die vor drei Jahren an einem Kosten-Nutzen-Vergleich gescheitert wären, sind heute rechenbar. Das ist keine kleine Sache – es ist die Verschiebung, die eine ganze Klasse eingefrorener Projekte auftaut.

Die richtige Reihenfolge

Nur: „Machbar" ist nicht „automatisch". Der teuerste Fehler, den man jetzt machen kann, ist, aus der neuen Ökonomie den falschen Schluss zu ziehen – nämlich den Agenten anzuweisen, das Ganze einfach neu zu schreiben. Wer so vorgeht, hat die Lektion aus dreißig Jahren gescheiterter Rewrites nicht verstanden, sondern nur beschleunigt.

Die Reihenfolge, die funktioniert, ist dieselbe, die Michael Feathers vor zwanzig Jahren in Working Effectively with Legacy Code beschrieben hat – KI ändert nicht die Methode, sie senkt nur die Kosten jedes Schritts:

Charakterisieren. Zuerst schnürt man ein Sicherheitsnetz. Man schreibt keine Tests, die belegen, dass der Code richtig ist – man schreibt Charakterisierungstests, die festhalten, was er tatsächlich tut, Macken inklusive. Der Bug, der seit 2015 im System sitzt und auf den sich drei nachgelagerte Prozesse verlassen, ist kein Bug mehr; er ist Verhalten, das man erhalten muss. Genau hier ist KI unbezahlbar: Sie generiert diesen Harness rund um ungetesteten Code in einem Tempo, das die Übung überhaupt erst praktikabel macht.
Verstehen. Mit dem Agenten erarbeitet man, was das System tut und warum. Nicht, um es zu bewundern, sondern um die Absicht hinter dem Code zu rekonstruieren, die nirgends aufgeschrieben steht.
Inkrementell migrieren. Man tauscht ein Stück aus – ein Modul, einen Endpunkt, einen Batchjob – gegen die neue Implementierung. Klein genug, dass ein Mensch die Änderung vollständig prüfen kann.
Verifizieren. Das Sicherheitsnetz aus Schritt 1 sagt sofort, ob das neue Stück sich genauso verhält wie das alte. Weicht es ab, war die Abweichung entweder beabsichtigt – oder man hat gerade einen Fehler gefunden, bevor er in Produktion ging.

Der springende Punkt: Die Tests kommen zuerst, nicht der neue Code. Ohne das Netz ist jede Migration wieder die alte Wette, nur mit einem Modell am Steuer, das seine Fehler genauso selbstbewusst produziert wie seine Treffer. Mit dem Netz wird aus der Wette ein kontrollierter, umkehrbarer Prozess.

Strangler Fig, jetzt mit Agenten

Es gibt ein Muster, das für genau diese Art von Umbau erfunden wurde, lange vor KI: die Strangler Fig, benannt nach der Würgefeige, die einen Baum langsam umwächst, bis sie sein Gerüst vollständig ersetzt hat, während er die ganze Zeit steht. Man baut das Neue um das Alte herum, leitet den Verkehr Stück für Stück um, und schaltet das Alte erst ab, wenn kein Pfad mehr durch es hindurchführt. Kein Stichtag, an dem alles auf einmal umschlägt. Kein Wochenende, an dem das halbe Team betet.

Agenten machen dieses Muster erst richtig praktikabel. Die klassische Schwäche der Strangler Fig war die Fassade – die Verständnisarbeit an der Grenze zwischen Alt und Neu, das Kartieren jedes Aufrufs, der abgefangen und umgeleitet werden muss. Genau diese Arbeit ist es, die ein Agent beschleunigt: Er findet die Nahtstellen, erklärt, was auf beiden Seiten passiert, generiert die Charakterisierungstests für das nächste Stück, das man herauslöst. Die Feige wächst schneller. Aber sie wächst – Zweig für Zweig, jeder von einem Menschen abgenommen –, sie fällt nicht als fertiger Baum vom Himmel.

Die neue Legacy, die niemand gelesen hat

Und hier lauert die Falle, die die ganze Übung ins Gegenteil verkehren kann. Sie ist verführerisch, weil sie sich nach Fortschritt anfühlt.

Ein Agent kann einen COBOL-Monolithen nach Java übersetzen und dabei Code produzieren, der kompiliert, durchläuft und plausibel aussieht. Zehntausende Zeilen, sauber formatiert, konventionell benannt. Es ist verlockend, das als erledigt zu verbuchen. Aber wenn kein Mensch diesen Code je gelesen und verstanden hat, hat man das ursprüngliche Problem nicht gelöst – man hat es reproduziert. Man ist von einer Blackbox, die niemand versteht, zu einer neuen Blackbox gewechselt, die niemand versteht. Nur ist die alte dreißig Jahre im Feld erprobt, und die neue nicht. Man hat das Alter der Legacy auf null zurückgesetzt und dafür die einzige Eigenschaft geopfert, die sie wertvoll machte: dass sie nachweislich funktioniert.

Das ist die teuerste Art technischer Schulden – nicht Code, der schlecht aussieht, sondern Code, den nie jemand im Kopf hatte. Ein maschinell übersetzter Monolith, den das Team nur vom Vorbeiscrollen kennt, ist schlimmer als das Original, denn er hat dessen Vertrauenswürdigkeit verloren und dessen Undurchdringlichkeit behalten. Die Übersetzung ist nicht das Ziel. Das menschliche Verständnis auf der anderen Seite ist das Ziel – die Übersetzung ist nur das Werkzeug, um dorthin zu gelangen.

Wann man die Finger davon lässt

Jetzt die ehrliche Gegenseite, denn hier verführt die neue Ökonomie zu zwei Trugschlüssen.

Der erste: dass KI den Big-Bang-Rewrite endlich sicher macht. Tut sie nicht. Die Versuchung, das Modell einfach alles neu schreiben zu lassen und den ganzen mühsamen inkrementellen Tanz zu überspringen, ist genau das klassische Rewrite-Desaster – nur schneller herbeigeführt. Der Grund, warum Big-Bang-Rewrites reihenweise scheitern, war nie die Tippgeschwindigkeit. Es war, dass man das alte Verhalten nie vollständig erfasst, das neue nie vollständig gegen die Realität testet und am Stichtag eine Wahrheit entdeckt, die man Monate zu spät hätte kennen müssen. Ein Agent, der in einer Woche 200.000 Zeilen ausspuckt, macht dieses Problem nicht kleiner – er macht es größer, weil jetzt noch mehr ungeprüfter Code auf einmal umschlägt. Geschwindigkeit ohne das Netz ist keine Lösung, sie ist dieselbe Klippe mit mehr Anlauf.

Der zweite Trugschluss ist subtiler: dass alles, was migriert werden kann, auch migriert werden sollte. Sollte es nicht. Manches Legacy sollte man in Ruhe lassen. Ein stabiles, laufendes, änderungsarmes System – der Batchjob, der seit zwölf Jahren klaglos die Nachtabrechnung fährt, das Modul, das niemand mehr anfasst, weil es einfach funktioniert – ist kein Problem, das auf seine Lösung wartet. Es ist ein gelöstes Problem. Es zu modernisieren, nur weil es alt ist, tauscht ein bewährtes System gegen das Risiko eines neuen, ohne dass jemand aus dem Wechsel einen Nutzen zieht. Der ehrliche Auslöser für eine Migration ist nie das Alter allein, sondern der Schmerz: Das System blockiert konkret ein Feature, es reißt Sicherheitslücken auf, es kettet an eine Plattform, die wirklich verschwindet. Fehlt der Schmerz, ist Stillhalten die überlegene Strategie.

Beide Trugschläge laufen auf denselben Punkt hinaus. Die Ökonomie der Modernisierung hat sich verbessert – aber die Disziplin zählt dadurch mehr, nicht weniger. Inkrementell statt in einem Rutsch. Test-abgesichert statt auf Hoffnung. Menschlich verifiziert statt maschinell durchgewunken. KI senkt die Kosten jedes einzelnen dieser Schritte dramatisch. Sie erlaubt es nicht, einen davon zu überspringen.

Fazit

Legacy-Modernisierung war jahrzehntelang in einem einzigen, brutalen Kostenfaktor gefangen: Niemand konnte es sich leisten, alten Code gründlich genug zu verstehen, um ihn sicher abzulösen. KI-Agenten lösen genau diesen Faktor auf. Sie lesen im großen Maßstab, sie erklären, sie spannen das Sicherheitsnetz aus Tests, das vorher fehlte. Eine ganze Klasse von Projekten, die für immer eingefroren schien, ist damit plötzlich rechenbar geworden.

Aber die Verschiebung betrifft die Kosten, nicht die Methode. Die richtige Reihenfolge ist dieselbe geblieben, die schon vor der KI galt – mit Charakterisierungstests festschreiben, was das System tut, verstehen, was dahintersteht, Stück für Stück migrieren, gegen das Netz verifizieren. Wer diese Reihenfolge durch „lass das Modell alles neu schreiben" ersetzt, hat sich kein modernes System gebaut, sondern nur eine neuere, ungetestete Legacy, die niemand gelesen hat.

Genau so gehen wir bei NH Labs an Legacy heran. Wir setzen Agenten ein, um Codebasen zu verstehen, die kein Mensch mehr im Kopf hat, und um die fehlenden Tests zu erzeugen, bevor wir eine einzige Zeile bewegen. Dann migrieren wir inkrementell, in Stücken, die ein Mensch prüfen und verantworten kann – nie als blinder Big-Bang-Rewrite. Am Ende steht kein maschinell übersetzter Monolith, den niemand versteht, sondern ein System, das ein Team wirklich beherrscht. Das ist der ganze Unterschied zwischen einem modernisierten System und einer neuen Legacy, die nur jünger aussieht.