Was wir von der AISM 2026 in München mitnehmen – und warum Legacy-Modernisierung für uns bei den Geschäftsprozessen beginnt und nicht beim Quellcode.

Eine Anwendung läuft seit zwanzig Jahren. Sie hat mehrere Generationen von Mitarbeitenden überlebt, verschiedene Strategiewechsel begleitet und unzählige Sonderfälle aufgenommen. Heute würde sie niemand mehr genauso bauen. Trotzdem hängt ein wesentlicher Teil des Geschäfts weiterhin von ihr ab.

Irgendwann fällt der Satz: „Das müssen wir endlich modernisieren.“

Doch was bedeutet Modernisierung eigentlich? Den Code in eine neue Sprache übersetzen? Die Oberfläche erneuern? Die Anwendung in die Cloud verschieben? Oder die Gelegenheit nutzen, um zu hinterfragen, wie das Unternehmen in Zukunft arbeiten möchte?

Für uns beginnt genau hier die entscheidende Diskussion. Nicht bei der Wahl der Programmiersprache oder der Architektur, sondern bei einer grundlegenderen Frage: Was braucht das Unternehmen – und welche Rolle soll die Software dabei spielen?

Mit dieser Perspektive waren wir auf der AISM 2026 in München im Rahmen der ASE vertreten und haben gemeinsam mit Prof. Sandra Greiner unseren Beitrag vorgestellt. Unser Paper trägt den Titel „LLM-Based Legacy Application Re-engineering Platform: An Experience Report of Migrating a Web Application“.

Legacy-Modernisierung ist mehr als Code-Übersetzung

Das Programm der AISM zeigte unterschiedliche Ansätze für KI-gestützte Modernisierung: von COBOL-zu-Java-Übersetzung und agentenbasierter C-zu-Rust-Migration über das Verstehen bestehender Anwendungen bis hin zur Rekonstruktion von Architekturentscheidungen und der Verbindung von KI mit klassischer Programmanalyse.

Schon diese Bandbreite macht deutlich: Legacy-Modernisierung lässt sich nicht auf eine einzige technische Aufgabe reduzieren.

Ein Beitrag brachte eine wichtige Unterscheidung bereits im Titel auf den Punkt: „Passing Parity Is Not Preserving Behaviour“. Bestandene Vergleichstests bedeuten also nicht automatisch, dass eine migrierte Anwendung tatsächlich das Verhalten des ursprünglichen Systems bewahrt.

Aus Business-Sicht möchten wir noch einen Schritt weitergehen: Selbst wenn eine neue Anwendung exakt dasselbe tut wie die alte: Tut sie damit schon das Richtige für das Unternehmen?

Diese Frage steht im Zentrum unseres Ansatzes mit Legacy Revive.

Das eigentliche Problem ist nicht die alte Programmiersprache

Stellen wir uns einen technischen Großhändler vor. Seine zentrale Anwendung verarbeitet Angebote, individuelle Preise, Freigaben und Bestellungen. Aus rein technischer Sicht könnte das Ziel lauten:

Die Anwendung soll künftig auf einer modernen Plattform laufen.

Aus geschäftlicher Sicht stellen sich jedoch ganz andere Fragen. Warum benötigen bestimmte Angebote drei Freigaben? Welche Preisregeln sind heute noch relevant? Wo müssen Mitarbeitende dieselben Daten mehrfach erfassen? Welche Sonderbehandlungen sind echte Wettbewerbsvorteile? Und welche existieren lediglich, weil das alte System keine bessere Lösung zuließ?

Das Beispiel ist fiktiv. Es verdeutlicht aber einen entscheidenden Unterschied: Ein bestehendes System technisch zu übertragen ist nicht dasselbe, wie den dahinterliegenden Geschäftsprozess sinnvoll weiterzuentwickeln.

Wer beides gleichsetzt, kann am Ende eine moderne Anwendung erhalten, die dieselben unnötigen Umwege wie zuvor verlangt. Die Technologie ist neu. Das Problem bleibt.

Unser Differentiator: Business first statt Code first

Mit Legacy Revive setzen wir deshalb bewusst an einer anderen Stelle an. Unsere erste Frage lautet nicht „Wie übersetzen wir diesen Code?“, sondern „Was soll diese Anwendung für das Geschäft leisten?“

Das bedeutet nicht, dass der bestehende Code unwichtig ist. Im Gegenteil. Eine über Jahre gewachsene Anwendung kann enormes Wissen enthalten: Geschäftsregeln, Ausnahmen, Abhängigkeiten und Entscheidungen, die möglicherweise nirgendwo anders mehr dokumentiert sind.

Der Code ist deshalb eine wichtige Informationsquelle. Er sollte aber nicht automatisch die Blaupause für die Zukunft sein. Denn eine bestehende Implementierung beantwortet zunächst die Frage, wie etwas umgesetzt wurde. Sie erklärt nicht zwangsläufig, warum es gebraucht wird, ob es weiterhin gebraucht wird oder ob es heute eine bessere Lösung gibt.

Unser Business-first-Ansatz stellt deshalb vor der technischen Umsetzung drei Fragen:

1. Was muss erhalten bleiben?

Welche fachlichen Regeln, Fähigkeiten, Kenntnisse und Verpflichtungen sind unverzichtbar?

2. Was sollte sich verändern?

Welche Abläufe sollen einfacher, schneller oder transparenter werden?

3. Was darf verschwinden?

Welche Funktionen und Sonderfälle haben ihren ursprünglichen Zweck verloren?

Für uns sind diese Fragen kein Zusatz zur Modernisierung. Sie geben ihr die Richtung.

Bewahren, verbessern oder weglassen

Die Forderung „Die neue Anwendung muss alles können, was die alte kann“ klingt zunächst nach Sicherheit. Sie kann aber wichtige Entscheidungen verdecken.

Nehmen wir eine besondere Rabattregel für eine bestimmte Kundengruppe. Vielleicht bildet sie eine weiterhin gültige vertragliche Verpflichtung ab. Dann muss sie zuverlässig erhalten bleiben.

Vielleicht gibt es daneben eine manuelle Freigabe, die vor Jahren eingeführt wurde, weil eine Schnittstelle fehlte. Dann wäre es sinnvoller, den dahinterliegenden Kontrollbedarf zu verstehen, anstatt den alten Umweg unverändert zu übernehmen.

Und vielleicht existiert ein Bericht, den seit Jahren niemand mehr verwendet. Dann lautet die relevante Frage nicht, wie er neu implementiert wird, sondern ob er überhaupt noch gebraucht wird.

Business-first-Modernisierung unterscheidet fachliche Notwendigkeit von historischer Gewohnheit.

Dafür braucht es Gespräche mit den Menschen, die Prozesse verantworten und täglich mit ihnen arbeiten. Nicht jede bestehende Funktion ist wertvoll, aber auch nicht jede ungewöhnliche Ausnahme ist überflüssig. Die Kunst besteht darin, den Unterschied zu verstehen.

Welche Rolle sollte KI dabei spielen?

Die Möglichkeiten von KI, Code zu analysieren, zu generieren und zu transformieren, eröffnen große Chancen für die Legacy-Modernisierung. Gleichzeitig liegt eine Versuchung nahe: Wenn KI technische Arbeit automatisieren kann, scheint das Ziel schnell darin zu bestehen, möglichst viel davon zu automatisieren.

Unsere Perspektive ist eine andere: Geschwindigkeit ist wertvoll, wenn die Richtung stimmt.

Eine schnell erzeugte Lösung hilft wenig, wenn sie auf unklaren oder nicht validierten Anforderungen basiert. Ebenso genügt eine überzeugend formulierte Beschreibung eines Prozesses nicht, wenn niemand geprüft hat, ob sie die fachliche Realität tatsächlich abbildet.

Für uns sollte KI deshalb Teil eines kontrollierten, nachvollziehbaren und transparenten Modernisierungsprozesses sein. Entscheidend ist nicht nur, wie viel KI produziert. Entscheidend ist, ob ihre Ergebnisse dabei helfen, Wissen sichtbar zu machen, Abhängigkeiten zu verstehen, die richtigen Fragen zu stellen und bessere Entscheidungen vorzubereiten.

Fachliche Entscheidungen bleiben fachliche Entscheidungen. Welche Risiken sind akzeptabel? Welche Ausnahme ist geschäftskritisch? Welche Prozesse sollten verändert werden? Was schafft einen echten Mehrwert für Mitarbeitende und Kunden? Diese Fragen lassen sich nicht allein aus einer Programmiersprache ableiten.

Ein gemeinsames Zielbild für Fachbereich und IT

Business first ist kein Gegenmodell zur IT. Im Gegenteil. Der Ansatz soll die Zusammenarbeit zwischen Fachbereich und IT verbessern. Beide Seiten brauchen ein gemeinsames Verständnis davon, was am Ende erreicht werden soll.

„Das System muss moderner werden“ ist dafür zu ungenau. Auch „Wir brauchen eine neue Architektur“ beschreibt zunächst eine technische Absicht, aber noch keinen geschäftlichen Erfolg.

Hilfreicher sind konkrete Ziele, zum Beispiel:

• Ein Angebot soll ohne doppelte Dateneingabe erstellt werden können.
• Eine Geschäftsregel soll geändert werden können, ohne den gesamten Prozess neu aufzusetzen.
• Eine Freigabe soll für alle Beteiligten nachvollziehbar sein.
• Ein neuer Mitarbeitender soll einen Standardfall ohne informelles Spezialwissen bearbeiten können.

Solche Ziele ersetzen technische Entscheidungen nicht. Sie geben ihnen einen Maßstab.

Erfolg endet nicht mit dem Go-live

Wer mit Geschäftszielen beginnt, sollte Modernisierung auch daran bewerten.

Für unseren fiktiven Großhändler könnten beispielsweise die Bearbeitungszeit eines Angebots, die Anzahl mehrfacher Dateneingaben, die Zeit bis zur Umsetzung einer neuen Geschäftsregel oder die Nachvollziehbarkeit von Entscheidungen relevante Messgrößen sein.

Das sind keine versprochenen Ergebnisse von Legacy Revive. Es sind Beispiele dafür, wie ein Business-first-Projekt definieren kann, was Erfolg tatsächlich bedeutet.

Ein erfolgreicher Go-live ist ein wichtiger Meilenstein. Der geschäftliche Nutzen ist das eigentliche Ziel.

Legacy Revive: vom Business zum System

Bei insinno verstehen wir Legacy Revive nicht als technische Erneuerung um ihrer selbst willen. Unser Ansatz ist die geschäftlich begründete Modernisierung bestehender Anwendungen.

Unser Differentiator lässt sich einfach formulieren: Wir kommen vom Business zum System – nicht vom Code zu einer neuen Version desselben Systems.

Wir wollen verstehen, was eine Anwendung für das Unternehmen wertvoll macht. Welches Wissen bewahrt werden muss. Was verbessert werden sollte. Was nicht mehr benötigt wird. Und wie daraus eine belastbare Grundlage für die technische Umsetzung entsteht.

Die wichtigste Frage kommt vor der ersten neuen Zeile Code

Die AISM 2026 hat gezeigt, wie vielfältig die technischen Möglichkeiten inzwischen sind, Legacy-Systeme zu analysieren, zu verstehen, zu validieren und zu transformieren.

Unsere Schlussfolgerung daraus ist, dass diese technischen Möglichkeiten mit etwas ebenso Wichtigem verbunden werden müssen: geschäftlicher Klarheit.

Die entscheidende Frage lautet deshalb nicht nur „Können wir diese Anwendung neu bauen?“, sondern: „Welche Anwendung braucht unser Unternehmen künftig – und was müssen wir aus der bestehenden Lösung dafür wirklich bewahren?“

Genau dort setzt Legacy Revive an.

Sie planen die Modernisierung einer geschäftskritischen Anwendung? Sprechen wir zuerst über Ihr Geschäft. Über den Code sprechen wir danach.

Mehr über Legacy Revive:
legacy-revive.insinno.eu