Ein öffentlich überprüfbarer Referenzfall für die kontrollierte Modernisierung geschäftskritischer Java-Anwendungen.
Viele Organisationen betreiben Fachanwendungen, die fachlich unverzichtbar, technisch aber über Jahre gewachsen sind. migration-lab zeigt an einem realitätsnahen Werkstatt-CRM, wie ein solcher Bestand schrittweise modernisiert wird, ohne Funktionsumfang und Datenverhalten still zu verändern. Der entscheidende Baustein ist kein Framework, sondern ein vorab aufgebautes Sicherheitsnetz, das den alten und den neuen Stand mit denselben Szenarien prüft.
Bei gewachsenen Fachanwendungen ist die Dokumentation selten vollständig. Deshalb wird der Soll-Zustand nicht aus Annahmen rekonstruiert: Charakterisierungstests halten das beobachtbare Verhalten von Schnittstellen und Datenbank fest, End-to-End-Tests sichern die tatsächlichen Arbeitsabläufe.
Dasselbe Netz läuft gegen Alt- und Zielstand. Ein Versionssprung gilt erst dann als abgeschlossen, wenn die definierten Abläufe auf beiden Seiten grün sind. So werden gerade jene Abweichungen sichtbar, die eine moderne Oberfläche allein nicht verrät.
Die Modernisierung ist in sechs überprüfbare Zustände gegliedert. Jeder Zustand ist als Git-Tag reproduzierbar und bringt einen lauffähigen Stand, dokumentierte Entscheidungen sowie die zugehörigen Prüfergebnisse mit.
Dieses Vorgehen reduziert organisatorisches Risiko: Fortschritt, verbleibende Abhängigkeiten und zulässige Abweichungen sind jederzeit benennbar. Für Auftraggeber entsteht eine belastbare Entscheidungsgrundlage statt eines mehrmonatigen Versprechens.
Das ergänzende KI-Testexperiment wurde vor dem ersten Lauf protokolliert. Die zunächst perfekten Kennzahlen stammten nur aus den Testklassen, die überhaupt kompilierten. Nach der Reparatur fielen sie auf 90,5 Prozent Zeilenabdeckung und 73,2 Prozent Mutation Score — ein messbarer Survivorship Bias.
Genau dieser Befund ist Teil des Kompetenznachweises: Werkzeuge werden nicht nach ihrem besten Screenshot bewertet, sondern nach reproduzierbaren Ergebnissen, Grenzen und dem Aufwand bis zu einem verlässlichen Stand.
Wesentliche Entscheidungen, ihre naheliegenden Alternativen und die Gründe dahinter.
Oberflächen können identisch wirken, während Datenformate, Nebenwirkungen oder seltene Abläufe bereits abweichen. Das gemeinsame Sicherheitsnetz macht diese Unterschiede vor der Auslieferung sichtbar.
Kleine, nachweisbare Zustände begrenzen die Fehlerursache, halten den Fortschritt überprüfbar und erlauben belastbare Freigaben je Etappe.
Die klare Grenze hält Alt- und Neusystem organisatorisch wie technisch trennbar und reduziert die Kopplung während der Übergangsphase.
Eine behobene SQL-Injection darf nicht als unerwarteter Testbruch erscheinen. Zulässige Abweichungen werden entschieden, dokumentiert und für beide Stände separat geprüft.
Stand Release v1.0.0. Alle Werte stammen aus den versionierten Worklogs, ADRs, CI-Konfigurationen und Messberichten des öffentlichen Repositorys. Die KI-Messung folgt einem vorab eingefrorenen Protokoll; Einschränkungen und nicht übertragbare Zeitangaben sind dort ausdrücklich dokumentiert.
