Löst euer Altsystem ab und behaltet jeden Sonderfall.
KI-Agenten schreiben als Tests auf, was euer Altsystem wirklich tut. Das neue System läuft parallel zum alten und muss jeden dieser Tests bestehen.
- AS/400, COBOL, Delphi, PL/SQL, SAP
- das Ergebnis gehört eurem Team
Vom Altsystem zum neuen System
- 01
Altsystem
Code, Oberflächen, APIs
- 02
Anforderungen
in Klartext, von euren Fachleuten geprüft
- 03
Neues System
nach Fachdomänen geschnitten
Sichert das Wissen, noch bevor ihr migriert
Wie das System wirklich funktioniert, wissen nur noch wenige, und die gehen in Rente oder wechseln. Dieses Wissen festzuhalten lohnt sich schon allein: Ob ihr später migriert oder gar nicht, es ist dokumentiert und euer Team kann es abfragen.
Euer Team bekommt eine Systemkarte zum Abfragen: Anforderungen in Klartext, Abhängigkeitsgraphen und Impact-Analyse an einem Ort.
Das Wissen steckt heute an vier Orten. Eine Karte hält es fest, wenn Menschen gehen.
Der Code
Agenten kartieren ihn, auch bei einem proprietären Framework, das die Modelle nicht kennen.
Trigger und Prozeduren
Code und Datenbank-Logs nebeneinander gelesen bringen die versteckte Logik ans Licht.
Wenige Köpfe
Strukturierte Interviews, früh, oft mit der einen Person, die das System gebaut hat.
Die alte Oberfläche
Agenten bedienen sie und zeichnen daraus Abnahmetests auf.
Das Verhalten des Altsystems wird zur Spezifikation
Zeile für Zeile übersetzen
Aus jeder alten Funktion wird eine neue Klasse.
- Der neue Code erbt die alte Struktur samt Kopplung.
- Ihr bezahlt eine Migration und habt am Ende dasselbe Knäuel in einer neueren Sprache.
Aus dem Verhalten neu bauen
Das Altsystem ist die Spezifikation.
- Der neue Code sieht den alten nie, nur dessen Oberflächen und APIs.
- Erst steht die Architektur, geschnitten nach Fachdomänen.
So migrieren wir, Schnitt für Schnitt
Langsam ist schnell: Die ersten Schnitte begleiten wir eng, denn eine Migration, die zu früh Tempo macht, verliert an Qualität.
- 01
System kartieren, Wissen sichern
Agenten kartieren die Codebasis, wir interviewen die Menschen, die die Sonderfälle kennen.
- 02
Anforderungen ableiten, nach Domänen schneiden
Agenten beschreiben, was der alte Code tut, eure Fachleute korrigieren. Die Domänen folgen dem Geschäft.
- 03
Gegen die alten Schnittstellen bauen
Zuerst der Test-Harness. Wir planen, dass eure Entwickler:innen die ersten 5 bis 20 Prozent der Stories mit den Agenten umsetzen, die Factory den Rest.
- 04
Alt und neu parallel betreiben
Beide bekommen dieselben Eingaben, bis sich das neue genauso verhält wie das alte.
Alt und neu laufen parallel, das neue wächst mit
Alt und neu laufen parallel, das neue wächst mit
Das Altsystem läuft weiter, während ein Schnitt nach dem anderen umzieht. Abgeschaltet wird es erst, wenn das neue alles trägt.
Neues System Altsystem
- Erster Schnitt Neues System 10 %, Altsystem 90 %
- Schnitt 2 Neues System 25 %, Altsystem 75 %
- Schnitt 3 Neues System 45 %, Altsystem 55 %
- Schnitt 4 Neues System 70 %, Altsystem 30 %
- Altsystem aus Neues System 100 %, Altsystem 0 %
Beispielhaft.
Erst ein Pilot-Schnitt, dann übernimmt die Factory die wiederholbaren
Erst ein Pilot-Schnitt, dann übernimmt die Factory die wiederholbaren
Vom Assessment bis zum Betrieb des neuen Systems durch euer Team.
-
01
Readiness Assessment
Wir kartieren das System, interviewen eure Fachleute und entscheiden mit euch, was ihr migriert, was ihr modernisiert und was bleibt.
-
02
Factory Pilot
Ein echter Schnitt, an eurem Code neu gebaut und gegen die alten Schnittstellen getestet.
-
03
Die Factory migriert den Rest
Die wiederholbaren Schnitte laufen durch die Factory. Eure Leute prüfen die Belege.
-
04
Euer Team betreibt es
Agenten kümmern sich um Alerts, Dependency-Updates und Sicherheitspatches. System und Factory gehören eurem Team.
Was ihr braucht und wo ihr anfangt
Was ihr braucht und wo ihr anfangt
Zuerst kommt ein überschaubarer Schnitt mit klaren Anforderungen. Der schwierigste Teil des Altsystems ist selten der richtige Anfang.
Zugang zum alten Code
Aus ihm kommen die Anforderungen.
Eine Oberfläche zum Testen
Am besten eine API, sonst eine Web-Oberfläche, zur Not ein Desktop-Client.
Menschen, die die Sonderfälle kennen
Ein oder zwei reichen.
Eine verantwortliche Person mit Mandat
Jemand, der die Migration verteidigt, wenn anderes eskaliert.
Wo die Anforderungen klar sind
Anforderungen aus einem laufenden System sind besser als Anforderungen, die man bei Menschen einsammelt.
Wo der Nutzen schnell kommt
Eine laufende Migration, die zu langsam ist, oder Lizenzkosten, die wegfallen.
Erst ein begrenzter Teil
Globaler Zustand, keine referenzielle Integrität, jede Woche neue Anforderungen: Fangt an einem überschaubaren Teil an und tragt das Vorgehen dann in den Kern.
Was wir ausschließen
Eine Tool-Demo oder das ganze System in einem einzigen großen Prompt übersetzt.
Das Assessment kartiert auch das Altsystem
Das Assessment kartiert auch das Altsystem
Neben den Delivery-Signalen liest das Assessment das Altsystem selbst. Wie viel davon kartiert wird, steht in eurem Angebot.
Eine Karte des Systems
Agenten kartieren den Code und die Logik in der Datenbank, bei großen Codebasen mit einem Code-Graphen.
Ein Verhaltensinventar
Was das Altsystem tut, in Klartext, und gegen welche Schnittstellen sich das neue testen lässt.
Die Wissensträger
Strukturierte Interviews mit den Menschen, die die Sonderfälle kennen.
Der erste Schnitt, und wo ihr besser nicht anfangt
Ein Schnitt mit klaren Anforderungen und begrenztem Risiko, dazu die Entscheidung, was ihr migriert, modernisiert oder behaltet.
Jeder Schnitt muss sich an den alten Schnittstellen beweisen
Jeder Schnitt muss sich an den alten Schnittstellen beweisen
Vom ersten Schnitt an, damit der Plan auf euren eigenen Zahlen steht.
- Das neue System antwortet an den alten Schnittstellen genau wie das alte
- Parität
- Alt und neu bekommen dieselben Eingaben, bis ihr umstellt
- Parallelbetrieb
- Zeit, Tokens, Fehler und Wiederholungen
- Pro Schnitt
- Das Projekt wieder im Plan, oder die Lizenz fällt weg
- Ergebnis
Fünf Ausgangslagen und der erste Schritt für jede
Fünf Ausgangslagen und der erste Schritt für jede
Anonymisierte Ausgangslagen, mit denen IT-Verantwortliche zu uns gekommen sind.
-
Die Ablösung läuft, aber in diesem Tempo dauert sie Jahre
Jedes neue Feature braucht eine Schnittstelle zurück zur AS/400. Das Altsystem wächst also, während es abgelöst wird.
- Zuerst: ein kleinerer Produktbereich mit klaren Anforderungen.
- Am Ende: die ersten Tickets durch eine Factory auf eurem Code und ein Vorgehen, das ihr auf den Kern übertragt.
-
Wer es kennt, geht bald in Rente
Eine gemeinsame Datenbank, Logik in Triggern und Stored Procedures, kaum Unit-Tests.
- Zuerst: Agenten lesen Code und Datenbank-Logs nebeneinander und zeichnen Abnahmetests am alten Client auf.
- Am Ende: Anforderungen, die der Wissensträger geprüft hat, und Tests, die das neue System bestehen muss.
-
Jahrzehnte Code, und das Wissen in wenigen Köpfen
Niemand kann sicher sagen, was eine Änderung alles berührt.
- Zuerst: das Wissen aus Code und Interviews sichern, mit einem für lokale Tests gemockten Mainframe.
- Am Ende: eine Architekturkarte und eine belegte Entscheidung: migrieren, auf eine neue Plattform heben oder modernisieren.
-
Raus aus dem Altsystem, rein ins SAP, das wir schon betreiben
Im Ziel steckt schon eigener Code, der Aufwand liegt also in Analyse und Fit-Gap.
- Zuerst: Agenten kartieren die alten Anwendungen, dann löst einer einen kleinen Fall auf einer SAP-Testinstanz.
- Am Ende: ein Fit-Gap, aus dem Code abgeleitet, und ein erster gelöster Fall.
-
Wir zahlen Lizenzen für etwas, das uns gehören könnte
Niemand hat Luft, einen Ersatz zu bauen oder zu betreiben.
- Zuerst: Das Produkt, wie es genutzt wird, ist die Spezifikation. Seine API wird nachgebaut, damit die Integrationen bleiben.
- Am Ende: ein Business Case, der Bau, Betrieb und Weiterentwicklung einrechnet.
Teams, mit denen wir gearbeitet haben
Engineering- und Produktteams aus der Tech-Szene im DACH-Raum.
Der Preis folgt dem ersten Schnitt
Nicht vor dem ersten Schnitt: Ohne Daten ist jede Schätzung geraten.
Fragen zur Legacy-Modernisierung
Mit welchen Systemen und Sprachen arbeitet ihr?
COBOL oder RPG auf AS/400 oder Mainframe, Delphi, PL/SQL, Java-Monolithen, SAP oder ein lizenziertes SaaS-Produkt. Bei einem proprietären Framework gibt ein Code-Graph den Agenten Kontext.
Gibt es einen Referenzfall, den wir uns ansehen können?
Kundenmigrationen veröffentlichen wir nicht mit Namen. Die Referenz, die zählt, ist eure eigene: Der Factory Pilot baut einen echten Schnitt eures Systems neu, und ihr messt Parität, Zeit und Tokens selbst.
Factory PilotWer betreibt das neue System danach?
Euer Team. Für einen mittelgroßen Ersatz planen wir mit einer Produktverantwortlichen und einem Backend-Engineer. Agenten übernehmen Dependency-Updates, Sicherheitspatches und Alerts, jeweils ein paar Mal begleitet, bevor sie allein laufen.
Greifen Agenten auf unsere Produktionsdaten zu?
Nein. Sie arbeiten in isolierten Containern gegen eine produktionsnahe Testumgebung. Wo eine echte Schnittstelle wie ein Mainframe nicht erreichbar ist, springt ein Mock ein.
Das Ergebnis gehört eurem Team
Mehr zum Neubau aus dem Verhalten steht in unserer Wissensbasis.
Die Migration ist die Schulung
Eure Entwickler:innen lernen das Vorgehen, während sie die ersten Schnitte eures eigenen Systems migrieren.
Enablement
Alles bleibt bei euch
Spezifikationen, Tests, Konfiguration und Pipelines bleiben in euren Repositories.
So funktioniert EnablementWissensbasis
Modernisierung und UI-Design
Reverse Engineering, Paritätstests und eine begrenzte Abfolge.
In der Wissensbasis lesenFindet heraus, was ihr zuerst migriert
Das Readiness Assessment kartiert euer System, spricht mit den Menschen, die es kennen, und endet mit einer Entscheidung für einen echten Schnitt.
Gespräch buchen (öffnet in einem neuen Tab)