Altsysteme mit KI-Agenten neu bauen: Umfang, Tests, Daten

Code ist nur ein Teil des Risikos

Viele Unternehmen betreiben Software, die 15 oder 25 Jahre gewachsen ist. Beim Softwarehersteller ist es das eigene Produkt, etwa eine Branchenlösung oder eine Plattform für Kunden und Partner. Im Anwenderunternehmen ist es eine selbst entwickelte Fachanwendung, an der Vertrieb, Service oder Verwaltung hängen, oder ein ERP. Jede Änderung dauert lange, und die Entwickler, die das System kennen, gehen in Rente. KI-Coding-Agenten senken die Kosten für das Schreiben von Code. Ob das einen Neubau dieser Größe trägt, ist noch nicht belegt.

Belegt ist: Schnellerer Code löst nur einen Teil des Problems. Bekannte gescheiterte Systemwechsel gingen an Systemen zugrunde, die beim Go-live nicht bereit waren, an zu knappen Tests und an Anpassungen, die nicht zum Standard passten. Beispiele sind die Plattformumstellung der britischen Bank TSB (PRA Final Notice) und die ERP-Einführung der Stadt Birmingham auf Oracle, die trotz Warnsignalen live ging (Grant Thornton, Report in the Public Interest). Dazu kommt das Kostenrisiko: Eine Auswertung von 5.392 IT-Projekten zeigt, dass wenige Projekte das Budget um ein Vielfaches sprengen (Flyvbjerg et al., 2022). Ein Neubau sollte deshalb in kleinen Schritten laufen, die man einzeln abbrechen kann.

Den Umfang aus der Nutzung ableiten

Der naheliegende Auftrag lautet: Das neue System soll alles können, was das alte kann. Diese Vorgabe heißt Feature-Parität. Praktiker aus der Ablösung von Altsystemen warnen, dass der Aufwand dafür fast immer stark unterschätzt wird (Cartwright, Horn, Lewis: Feature Parity). Schon die Einigung darauf, was das alte System genau tut, kostet viel Aufwand. Außerdem erzwingt Parität meist eine große Umstellung am Ende statt vieler kleiner. Und sie baut Funktionen nach, die niemand mehr nutzt.

Welche Funktionen genutzt werden, zeigen die Produktionsdaten. Fast jedes Geschäftssystem speichert Datensätze mit Zeitstempel, etwa Aufträge, Tickets, Verträge oder Buchungen. Dazu kommen Änderungsprotokolle, die Historie der Hintergrundjobs und Anwendungslogs. Ein Skript zählt pro Prozess und Kunde oder Standort, wie oft er läuft und wann zuletzt. Wo Logs fehlen, schalten Sie eine schlanke Nutzungsprotokollierung sofort ein, denn ab diesem Tag läuft die Messung.

Wie lang das Messfenster sein sollte, zeigt ein Beispiel aus der ERP-Welt. SAP empfiehlt seinen Kunden, die Nutzung ihres eigenen Zusatzcodes 6 bis 18 Monate lang im Produktivsystem zu messen, und zwar über mindestens einen Jahresabschluss (SAP Learning). Ein kurzes Messfenster lässt alles ungenutzt aussehen, was nur einmal im Jahr läuft, etwa Jahresabschluss, Vertragsverlängerungen oder Jahresmeldungen an Behörden. Ein Jahresabschluss läuft einmal im Jahr und ist trotzdem Pflicht. Läuft das System bei mehreren Kunden oder an mehreren Standorten, vergleichen Sie außerdem alle Installationen, bevor Sie etwas streichen. Code, der bei einem Kunden nie läuft, kann bei einem anderen täglich laufen.

Aus den Daten entsteht für jeden Prozess eine Entscheidung: unverändert übernehmen, neu gestalten, auf einen Marktstandard vereinfachen, als Erweiterung für einzelne Kunden auslagern oder streichen. Die Regeln dafür laufen als Skript, Ausnahmen entscheiden die Produktverantwortlichen. Streichen ist nur erlaubt, wenn die Datenbasis genug Installationen und Monate abdeckt. Die unveränderte Übernahme braucht ebenfalls eine Begründung, etwa hohe Nutzung oder eine gesetzliche Vorgabe. Sie ist kein Standardfall.

Das Altsystem als Prüfmaßstab

Für jeden übernommenen Prozess muss das neue System bei gleicher Eingabe dasselbe Ergebnis liefern wie das alte. Lässt man einen KI-Agenten den Altcode lesen und die Regeln aufschreiben, fehlt viel. In einem Benchmark mit neun Java-Projekten übersahen Sprachmodelle je nach Ebene 26 bis 65 Prozent der Anwendungsfälle (Xiao et al., UCRBench, 2025). In einer Fallstudie migrierte ein Coding-Agent Funktionen einer Unternehmensanwendung, eines ERP-Systems, von Visual Basic 6 nach C#. Von 100 Abweichungen waren 94 fehlende Logik und 6 falsch umgesetzte (Alves et al., 2026). Eine fehlende Regel fällt bei einer Durchsicht kaum auf.

Der Prüfmaßstab ist deshalb das aufgezeichnete Verhalten des Altsystems. Reale Fälle laufen auf einer Kopie mit anonymisierten Produktionsdaten, Eingaben und Ergebnisse werden gespeichert. Von einer KI geschriebene Tests ersetzen diese Aufzeichnung nicht. Erwartete Werte stammen aus den Aufzeichnungen oder von Fachexperten, und der Agent, der den Code baut, kann sie nicht ändern. Wie man solche Tests aufbaut, beschreibt der Essay Legacy-Systeme mit KI-Agenten neu bauen auf jenslaufer.com im Detail. Für die Planung zählt: Menschen geben die Spezifikation jedes Prozesses frei und prüfen jede Abweichung. Diese Prüfstunden bestimmen das Tempo des Projekts.

Anpassungen und Schnittstellen erhalten

Geschäftssoftware wird angepasst und angebunden. Bei Standardsoftware tun das die Kunden, bei Eigenentwicklungen die Fachabteilungen und die Teams der Nachbarsysteme. Typisch sind zusätzliche Felder, Einsprungpunkte für eigenen Code, Skripte, eigene Berichte, geänderter Programmcode, direkte Datenbankabfragen und Schnittstellen zu anderen Systemen. Bricht der Neubau diese Anpassungen, verweigern Kunden das Upgrade, und intern fallen angebundene Abläufe aus. Dabei gilt eine Erfahrungsregel aus der Softwareentwicklung bei Google: Bei genug Nutzern ist es egal, was der Vertrag verspricht. Irgendjemand verlässt sich auf jedes beobachtbare Verhalten des Systems (Hyrum's Law). Eine Tabelle, die ein Kunde oder ein Nachbarsystem per SQL abfragt, ist dafür eine Schnittstelle, auch wenn sie nie dafür gedacht war.

Der erste Schritt ist ein Inventar aller Anpassungen und Schnittstellen. Gibt es viele Installationen, reicht für den Entwurf der neuen Erweiterungspunkte eine Stichprobe: die am stärksten angepassten Installationen, die größten Kunden, jede Basisversion. Vor der Umstellung eines bestimmten Kunden oder Bereichs brauchen Sie dagegen dessen vollständiges Inventar. Ähnliche Anpassungen werden gruppiert. Was viele gleich angepasst haben, wird Standardfunktion. Für den Rest entstehen wenige allgemeine Erweiterungspunkte, etwa Ereignisse, zusätzliche Felder und Programmierschnittstellen. Ein eigener Erweiterungspunkt für jede einzelne Anpassung würde das Altsystem nachbauen.

Erweiterungspunkte sind eine öffentliche Schnittstelle und brauchen Regeln für ihre Weiterentwicklung: Stabilitätsstufen, Versionierung, einen Kalender für abgekündigte Punkte und einen Weg, auf dem Kunden und Partner neue Punkte beantragen. Ein Beispiel aus der ERP-Welt: Microsoft hat die Anwendungsmodelle von Dynamics 365 Finance & Operations versiegelt, seitdem sind nur noch Erweiterungen erlaubt. Code, der das Standardprodukt direkt überschreibt, hat Microsoft ab November 2017 drei Jahre lang unterstützt, aber nicht in neue Versionen übernommen (Microsoft Learn). Eine Übergangsschicht für alte Anpassungen hilft, wenn sie ein festes Enddatum hat.

Ob eine neue Version Anpassungen oder Schnittstellen bricht, prüfen automatische Tests je Kunde oder angebundenem System. Salesforce beschrieb 2013 ein Verfahren namens Hammer: Vor jeder Freigabe laufen alle Kundentests auf der aktuellen und auf der kommenden Version, die Ergebnisse werden verglichen (Salesforce Developers, archiviert). Für einen Neubau heißt das: Schlagen die Tests eines Kunden fehl, wird dieser Kunde nicht umgestellt. Vor jedem Upgrade erhält der Kunde eine Liste der Anpassungen, die sich nicht übertragen ließen.

Datenmigration

Die Datenmigration läuft pro Fachbereich und, wo es mehrere Installationen gibt, pro Kunde, während der Rest des Systems weiterläuft. Diese Punkte müssen geklärt sein:

• Bereinigung: Dubletten, verwaiste Datensätze und ungültige Schlüssel werden erfasst. Die Fachseite, also der Kunde oder die zuständige Abteilung, entscheidet je Regel, ob vorher, während der Migration oder gar nicht bereinigt wird. Das ist eine fachliche Entscheidung und keine IT-Aufgabe.
• Offene Vorgänge: Für offene Aufträge, laufende Tickets, Genehmigungen in Bearbeitung und offene Rechnungen wird je Prozess festgelegt, ob sie im Altsystem auslaufen, mit Status migriert werden oder zum Periodenende wechseln.
• Bestände und Salden: Führt das System Bestände, Guthaben oder Kontensalden, ziehen sie als abgestimmte Anfangswerte um.
• Nummernkreise: Wo das Gesetz lückenlose Belegnummern verlangt, laufen sie ohne Lücke weiter.
• Historie: Alte Daten werden migriert, mit Lesezugriff archiviert oder im Altsystem schreibgeschützt behalten. Gesetzliche Aufbewahrungsfristen gelten in jedem Fall.

Vor der Umstellung laufen mehrere Generalproben auf vollständigen Produktionsdaten mit Zeitmessung. Jede Probe muss in das Umstellungsfenster passen, und die Abstimmung zwischen alten und neuen Daten darf keine ungeklärte Differenz zeigen. Generalproben mit Teildaten reichen nicht. Sie finden den einen fehlerhaften Datensatz aus 2009 nicht, an dem der vollständige Lauf abbricht.

Schrittweise umstellen

Beginnen Sie mit einem kleinen Pilotbereich, der wenig mit anderen Bereichen verflochten ist und trotzdem genutzt wird. An ihm laufen alle Schritte einmal vollständig durch: Nutzung messen, Verhalten aufzeichnen, neu bauen, Daten migrieren, Kunden umstellen. Erst danach entscheiden Sie, ob weitere Bereiche folgen. Wie man allgemein vom Pilotprojekt zum Rollout kommt, beschreibt unser Artikel Vom Pilotprojekt zum Rollout.

Neue Module laufen eine Zeit lang neben dem Altsystem und übernehmen Stück für Stück dessen Aufgaben, bis das Altsystem abgeschaltet werden kann. Martin Fowler nennt dieses Vorgehen nach der Würgefeige, die einen Baum langsam überwächst (Strangler Fig). Umgestellt wird Prozess für Prozess, Standort für Standort oder Kundengruppe für Kundengruppe. Bei Kunden mit eigener Installation entsteht daraus eine Matrix aus Kunde, Version und bereits umgestellten Bereichen. Als erste Pilotnutzer eignen sich Kunden oder Abteilungen mit wenigen Anpassungen und aktiver Nutzung.

Vor jedem Wechsel steht eine Prüfung: Es gibt keine offene Abweichung zum Altsystem, die Generalproben sind bestanden, die Tests für Anpassungen und Schnittstellen laufen fehlerfrei, die Key User haben abgenommen, Lasttests liefen über alle Standorte und Rechenzentren. Wie teuer eine Lücke dabei wird, zeigt die britische Bank TSB. Sie zog 2018 ihre Kunden in einem großen Migrationsereignis auf eine neue Plattform um. Die nicht-funktionalen Tests, darunter Lasttests, liefen vorher nur in einem der beiden Rechenzentren, obwohl die Plattform im Betrieb beide gleichzeitig nutzte. Nach dem Start führten Konfigurationsfehler zwischen den Rechenzentren zu Ausfällen in App und Online-Banking (PRA Final Notice).

Eine Stelle außerhalb des Projektteams bestätigt die Bereitschaft. Der Weg zurück ins Altsystem ist in einer Testumgebung geprobt, mit festgelegten Schwellenwerten für den Rückfall. Nach der Umstellung vergleichen Sie Fehlerrate, Durchsatz, Laufzeit und Support-Tickets mit dem Ausgangswert aus der Nutzungsmessung. Der Parallelbetrieb kostet jeden Monat Geld und braucht deshalb ein Enddatum, das von Beginn an geplant ist.

Checkliste vor der ersten Umstellung

• Strategie: Die Entscheidung für Neubau statt schrittweiser Sanierung ist schriftlich begründet. Feature-Parität ist ausdrücklich kein Ziel.
• Nutzung: Für jeden Prozess liegen Nutzungsdaten oder der Vermerk „keine Daten" vor, mit Angabe der Installationen und des Zeitraums.
• Entscheidungen: Jeder Prozess hat eine Entscheidung. Jede unveränderte Übernahme und jede Streichung ist begründet.
• Prüfmaßstab: Erwartete Werte stammen aus Aufzeichnungen des Altsystems oder von Fachexperten. Der bauende Agent kann sie nicht ändern.
• Anpassungen: Für jeden Pilotkunden oder Pilotbereich gibt es ein vollständiges Inventar der Anpassungen und Schnittstellen und automatische Tests, die sie prüfen.
• Daten: Die vereinbarte Zahl an Generalproben auf vollständigen Daten ist bestanden, ohne ungeklärte Differenz und im Zeitfenster.
• Rückweg: Die Rückkehr ins Altsystem ist geprobt, die Auslöser sind festgelegt.
• Kapazität: Die Planung richtet sich nach den Stunden der Fachexperten und Prüfer.

Fazit

KI-Agenten senken die Kosten, Code zu schreiben. Die Arbeit verschiebt sich dadurch zu den Fragen, die auch ohne Agenten über Erfolg oder Scheitern eines Neubaus entschieden haben: welchen Umfang das neue System braucht, woran man seine Richtigkeit erkennt, wie Anpassungen, Schnittstellen und Daten umziehen. Antworten darauf liefern Nutzungsdaten, Aufzeichnungen des Altsystems und geprobte Umstellungen.

Im Workshop prüfen wir, wo KI-Agenten in Ihrer Entwicklung heute sinnvoll sind: Unsere Beratungspakete im Überblick.