Wie KI-Agentic-Coding hilft, Legacy-Systeme zu verstehen und zu Microservices zu migrieren

Bei jeder Legacy-Migration, die ich begleitet habe, kam früh derselbe Punkt: Nicht das Schreiben des neuen Codes war das Problem, sondern das alte System gut genug zu verstehen, um dem Umbau vertrauen zu können. Die ursprünglichen Entwickler sind längst weg, die Dokumentation beschreibt eine Version des Systems, die es seit Jahren nicht mehr gibt, und die eigentlich relevante Fachlogik steckt in einer Service-Klasse, die seit 2014 niemand mehr geöffnet hat. Genau hier verändert KI-Agentic-Coding gerade die Wirtschaftlichkeit von Legacy-Modernisierung — nicht, indem es die Microservices für Sie schreibt, sondern indem es die Zeit drastisch verkürzt, ein belastbares mentales Modell des Systems aufzubauen, das migriert werden soll.

Der Engpass war nie der Neubau — es ist das Verständnis

Martin Fowlers Strangler-Fig-Pattern ist seit Jahren der Standardansatz für Legacy-Modernisierung, aus gutem Grund: Statt eines riskanten Big-Bang-Rewrites lässt man ein neues System um das alte herum wachsen und übernimmt Funktionalität Stück für Stück, bis die Altanwendung abgeschaltet werden kann. Fowler macht dabei deutlich, dass der erste Schritt gar kein Coding ist — sondern die Zerlegung des Systems entlang von „Nähten", also den natürlichen Grenzen, an denen sich einzelne Teile herauslösen lassen. Diese Nähte zu finden ist ein Discovery-Problem, und Discovery ist genau das, was in einem gewachsenen Java-System am längsten dauert: herausfinden, welcher Batch-Job tatsächlich noch in Produktion läuft, welche von drei fast identischen Service-Klassen die aktive ist, und welche Datenbanktabellen von Code gelesen werden, der laut zwei Reorganisationen zurückliegender Aussage längst abgeschaltet sein sollte.

Wo KI-Agentic-Coding wirklich hilft

Genau das können Coding-Agenten heute gut. Mit Zugriff auf eine Codebasis kann ein Agent tausende Dateien durchsuchen, Aufruf- und Abhängigkeitsgraphen nachvollziehen, Ende-zu-Ende-Abläufe über Modulgrenzen hinweg rekonstruieren und Dokumentation für Systemteile erzeugen, die seit Jahren niemand mehr beschrieben hat — Arbeit, für die ein Mensch sonst Wochen an Code-Archäologie braucht. Branchendaten stützen das: McKinsey schätzt, dass generative KI in der Anwendungsmodernisierung technologieschuldenbezogene Kosten um rund 40 % senken und Zeitpläne um 40–50 % beschleunigen kann — größtenteils, weil sie die Discovery-Phase verkürzt, nicht das eigentliche Coding.

Die weiter fortgeschrittenen Ansätze gehen noch einen Schritt weiter als reines Prompting. Der Erfahrungsbericht von AltexSoft zu Agenten-gestützter Modernisierung beschreibt, Agenten eine graph-basierte Sicht auf die Codebasis zu geben — kartierte Struktur, Abhängigkeitsgraphen, rekonstruierte User-Flows — statt sich darauf zu verlassen, dass der Agent alles im eigenen Kontext behält. Allein diese Änderung senkte die Halluzinationsrate bei Modernisierungsaufgaben um rund 40–50 % gegenüber einem Agenten, der direkt über Rohquellcode arbeitet. Bei einem Java-Monolithen mit einem Jahrzehnt gewachsener Spring-, Hibernate- und EJB-Schichten macht diese strukturelle Verankerung den Unterschied zwischen einer real erkannten Abhängigkeit und einer souverän erfundenen.

Wo die Grenzen liegen — und warum das wichtig ist

Es wäre unehrlich, hier aufzuhören. Derselbe AltexSoft-Bericht benennt die Grenzen offen: Context-Window-Beschränkungen verhindern nach wie vor, dass eine einzelne Agenten-Session eine wirklich große Codebasis vollständig im Blick behält, und die meisten Tools haben keine Persistenz zwischen Sessions — Erkenntnisse aus der Analyse eines Moduls übertragen sich nicht automatisch auf das nächste. In einem im Bericht zitierten Modernisierungsprojekt fehlten nach der Migration 17 REST-Endpunkte — entdeckt erst einen Monat nach dem Go-Live, weil kein einzelner Durchgang, weder menschlich noch KI-gestützt, die komplette Aufrufer-Landschaft der Legacy-API erfasst hatte.

Das ehrliche Fazit von Teams, die solche Projekte tatsächlich durchgeführt haben, ist unmissverständlich: „In dem Moment, in dem Sie Entscheidungen an die KI abgeben, sind Sie kein Engineer mehr." Entscheidungen über Service-Grenzen, Reihenfolge, Risikotoleranz und Produktionsvalidierung bleiben fest in der Hand des Architekten. Was sich ändert, ist, wie viel von der mühsamen Vorarbeit — Kartierung, Nachverfolgung, Dokumentationsentwürfe — ein Agent übernehmen kann, bevor dieses Urteilsvermögen zum Einsatz kommt.

KI-Agentic-Coding und Strangler-Fig kombinieren

In der Praxis passen beide Ansätze gut zusammen, angelehnt an Fowlers vier Aktivitäten:

• Ziele festlegen — bleibt ein menschliches und geschäftliches Gespräch; kein Agent kann Ihnen sagen, was „fertig" für Ihr Unternehmen bedeuten soll.
• System zerlegen — hier verdient sich ein Agent seinen Nutzen: Module kartieren, Abhängigkeiten nachverfolgen und Kandidaten für Nähte vorschlagen, die Sie prüfen und korrigieren, statt jede Aufrufkette selbst nachzuvollziehen.
• Schrittweise liefern — Agenten können die für Strangler-Fig nötigen Übergangs-Adapter und Routing-Logik zwischen Alt- und Neusystem entwerfen, während Sie jeden Schnitt gegen das reale Produktionsverhalten validieren, bevor er live geht.
• Organisation transformieren — eine reine Menschen- und Prozessfrage, die kein Tooling abkürzt.

Das Muster ändert sich nicht. Was sich ändert: Die zeitaufwändigste Aktivität — die Zerlegung — startet jetzt mit einer KI-generierten Karte des Systems statt mit einem leeren Whiteboard, vorausgesetzt jemand mit echter Java- und Architekturerfahrung prüft diese Karte, bevor auch nur eine Service-Grenze gezogen wird.

Wie ich das in der Praxis einsetze

Bei Mittelstandskunden starte ich jedes Modernisierungsprojekt mit derselben Frage — mit oder ohne KI im Prozess: Was tut dieses System heute tatsächlich? Ich nutze Agentic-Coding-Tools in genau dieser Discovery-Phase — der Java-Modernisierungsanalyse, die ich anbiete —, um Architektur, Abhängigkeiten und technische Schulden in der Codebasis schneller zu kartieren, und wende dann 25 Jahre Java- und Spring-Erfahrung an, um das Ergebnis des Tools zu prüfen, die echten Nähte zu bestimmen und die Migration so zu takten, dass der Betrieb nie stillsteht. Der Agent verkürzt die Archäologie. Er ersetzt nicht den Architekten, der entscheiden muss, wo geschnitten wird.

Fazit

KI-Agentic-Coding wird Ihr Legacy-Java-System nicht von allein zu Microservices migrieren, und jedes Versprechen, das etwas anderes suggeriert, überspringt den Teil, in dem 17 Endpunkte klammheimlich verschwinden. Was es gut kann, ist genau der Teil, der bisher am teuersten war: schnell ein strukturell fundiertes Verständnis eines Systems aufzubauen, das niemand mehr vollständig überblickt. Kombiniert mit einem disziplinierten Strangler-Fig-Rollout und erfahrenem menschlichem Urteilsvermögen an den Schnittstellen verkürzen sich Modernisierungszeiträume, die früher Jahre gedauert haben, spürbar.

Weiterführende Quellen:

• Martin Fowler — StranglerFigApplication
• AltexSoft — Legacy Modernization Using AI Agents: Hands-On Experience
• awesome-agentic-software-modernization (GitHub)