AI-First Legacy Modernization: Eine kontrollierte Transformation in 6 Schritten

Denn Künstliche Intelligenz kann heute Hunderttausende Zeilen Code lesen, analysieren und in strukturiertes Wissen übersetzen. Nicht als grobe Zusammenfassung, sondern als vollständige Dokumentation: Geschäftsregeln, Datenmodelle, Abhängigkeiten, Integrationsschnittstellen. Was früher Monate dauerte, ist jetzt in Tagen möglich. Damit sinkt der größte Unsicherheitsfaktor in jedem Modernisierungs-Business-Case: die fehlende Transparenz des Legacy-Systems.

Entgegen vieler anderer Modernisierungsansätze, die nur den Delivery-Prozess beschreiben und erst dann greifen, wenn die Entscheidung zur Modernisierung bereits gefallen ist, haben wir bei Nortal ein Modell entwickelt, das auch die Fragen beantwortet, die vorher geklärt werden müssen: Was genau tut das Altsystem? Lohnt sich die Modernisierung überhaupt? Und wenn ja: Welcher Weg ist der richtige?

Unser Modell beschreibt den ganzen Weg von der ersten Analyse bis zur produktionsreifen Lösung und besteht aus sechs Schritten, die aufeinander aufbauen sowie aus einer Reihe von Prinzipien, die über alle Schritte hinweg gelten. Die ersten drei Schritte beschreiben den Weg hin zur Entscheidung, welche Art der Modernisierung am besten passt. Die letzten drei Schritte zeigen den Weg zur Umsetzung auf und sichern das Ergebnis ab.

Bevor irgendetwas entschieden wird, muss klar sein, was das Altsystem tut. Nicht ungefähr, nicht auf Basis von Erinnerungen des Teams, sondern vollständig. „AI Legacy Archaeology“, ein KI-gestützter Prozess, der verborgenes Wissen zugänglich macht, analysiert den gesamten Code eines Systems: Geschäftsregeln, Datenstrukturen, Abhängigkeiten zwischen Modulen, technische Schulden. Dabei arbeitet die Analyse strikt nicht-invasiv. Am laufenden System wird nichts verändert. Deterministische Code-Analyse-Tools liefern die Faktenbasis. KI interpretiert und strukturiert die Ergebnisse. Menschliche Expert*innen validieren an definierten Prüfpunkten.

Das Ergebnis ist keine PowerPoint-Zusammenfassung, sondern eine strukturierte, referenzierbare Dokumentation. In wenigen Tagen entsteht ein Bild, für das traditionelle Methoden Monate gebraucht hätten.

In einem unserer Projekte wusste das Projekt-Team danach mehr über sein eigenes System als die Leute, die es seit Jahren betreut hatten. Nicht weil sie unqualifziert waren, sondern weil kein einzelner Mensch Hunderttausende Zeilen Code im Kopf behalten kann.

Systemverständnis allein erzeugt noch keinen Wert. Es muss bewertet werden: Lohnt sich eine Modernisierung? Und wenn ja, wo fängt man an?

Ein strukturiertes Assessment betrachtet vier Dimensionen.

• Risiko: Was passiert, wenn wir nichts tun?
• Business Value: Welcher Hebel entsteht durch die Modernisierung?
• Opportunitätskosten: Was kann das Unternehmen nicht tun, solange das Altsystem steht?
• TCO-Vergleich: Wie stehen die Gesamtkosten des Weiterbetriebs im Verhältnis zu den Kosten einer Modernisierung?

Der Unterschied zu herkömmlichen Assessments liegt darin, dass die Bewertung auf dem vollständigen Systemwissen aus Schritt 1 basiert, nicht auf Schätzungen und Interviews. Das macht sie belastbar.

Erst wenn Schritt 1 und 2 sauber gelaufen sind, kann fundiert entschieden werden. Und zwar pro System, nicht pauschal.

Die Optionen sind vielfältig: Neuentwicklung, Teilablösung, Migration auf eine Low-Code-Plattform oder die bewusste Entscheidung, ein System weiterzubetreiben. Jede dieser Optionen kann die richtige sein. Aber die Entscheidung muss auf Fakten basieren, nicht auf Annahmen oder der Frage, welche Plattform gerade im Trend liegt.

Wenn die Richtung steht, braucht es eine präzise Spezifikation des Zielsystems. Zielarchitektur, Schnittstellen-Design, Teststrategie, Migrationspfad. Das klingt nach klassischem Vorgehen, und das ist es auch. Mit einem entscheidenden Unterschied: Die Spezifikation basiert auf dem Wissen aus Schritt 1, nicht auf lückenhaften Anforderungsdokumenten.

Diese Phase ist der eigentliche Engpass in jedem Modernisierungsprojekt. Sie dauert nicht besonders lang, aber sie erfordert Entscheidungen, die man nicht automatisieren kann und sollte. Architekturentscheidungen, Technologiewahl, fachliche Validierung: All das bleibt die Aufgabe von Menschen. KI unterstützt, indem sie Optionen aufzeigt und die Konsistenz prüft, aber die Verantwortung liegt beim Team.

Eine gute Spezifikation macht die folgende Umsetzung vorhersagbar. Eine vage Spezifikation hingegen produziert Code, der technisch funktioniert, aber fachlich daneben liegt.

Die Umsetzung verläuft fundamental anders als in klassischen Projekten. Statt eines einzelnen Entwicklungsteams arbeiten spezialisierte KI-Agenten parallel. Ein Agent ist fürs Backend zuständig, ein anderer fürs Frontend. Einer schreibt Tests, ein weiterer Agent prüft die Architekturkonsistenz. Alle nutzen dieselbe Spezifikation als Grundlage. Ein menschliches Team orchestriert, setzt die Leitplanken und gibt frei.

Das ist kein „Vibe Coding“, bei dem jemand einem KI-Modell einen vagen Prompt gibt und hofft, dass etwas Brauchbares rauskommt. Es ist eine spezifikationsgetriebene Entwicklung mit orchestrierten Agenten. Der Unterschied ist nicht das Werkzeug, sondern die Methodik.

Das Ergebnis sind Implementierungszyklen, die sich von mehreren Wochen auf wenige Tage komprimieren. Die Qualität bleibt dabei gleich oder steigt sogar, weil Parallelisierung und automatisierte Konsistenzprüfungen Dinge abfangen, die im manuellen Prozess oft durchrutschen.

Der letzte Schritt, das Absichern der neuen Lösung, ist mindestens so wichtig wie die Umsetzung selbst. KI generiert eine umfassende Testabdeckung, während Menschen sich auf die fachliche Validierung und die risikobasierte Abnahme konzentrieren. Code Reviews prüfen den generierten Code gegen die Spezifikation. Und Governance-Prozesse stellen sicher, dass nichts in Produktion geht, was nicht validiert wurde.

Dazu gehört die Koexistenz-Strategie: Das alte und das neue System laufen parallel und die Ablösung passiert schrittweise – kein Big Bang, sondern kontrollierte Transition. Das Altsystem wird nicht abgeschaltet, bis das neue System unter realen Bedingungen funktioniert.