Die wichtigste Entscheidung einer Modernisierung betrifft nicht das neue Framework. Sie betrifft den Nachweis, dass das System danach noch dasselbe tut.
Ein gewachsenes Fachsystem kann technisch veraltet und fachlich trotzdem unverzichtbar sein. Es enthält Regeln, Ausnahmen und Abläufe, die über Jahre entstanden sind. Ein Teil davon steht in Dokumentationen. Ein anderer Teil lebt nur im Verhalten der Anwendung, in der Datenbank oder im Wissen einzelner Mitarbeiter.
Genau deshalb ist ein vollständiger Neubau selten die risikoärmste Antwort. Wer alles gleichzeitig ersetzt, bündelt Technik, Fachlichkeit, Datenmigration und Betriebsumstellung in einem einzigen Freigabepunkt. Das sieht auf einem Projektplan klar aus. Im Betrieb ist es ein Sprung ohne Geländer.
Unser öffentliches migration-lab zeigt einen anderen Weg: Eine realitätsnahe Java-Anwendung aus dem Jahr 2016 wird in sechs reproduzierbaren Etappen modernisiert. Der Ausgangsstand mit Java 8, Spring Boot 1.5 und AngularJS bleibt dabei ausführbar. Der Zielstand mit Java 25, Spring Boot 4.1 und Angular 22 läuft parallel. Beide werden mit demselben Sicherheitsnetz geprüft.
Das Altsystem ist zunächst die Spezifikation
Bei einem zehn Jahre alten System ist die vorhandene Dokumentation fast nie vollständig genug, um daraus eine neue Anwendung zu bauen. Das ist kein Vorwurf. Fachliche Regeln entstehen im Alltag: ein Sonderfall für eine Abrechnung, eine Reihenfolge beim Statuswechsel, ein Feld, das nur bei bestimmten Datensätzen gesetzt wird.
Vor der ersten technischen Änderung muss deshalb feststehen, wie sich das bestehende System tatsächlich verhält.
Charakterisierungstests schreiben nicht vor, wie eine ideale Anwendung funktionieren sollte. Sie halten fest, was die bestehende Anwendung heute beobachtbar tut. Im migration-lab prüfen 47 solcher Tests Schnittstellen und Datenbankverhalten. Ergänzt werden sie durch 34 End-to-End-Szenarien für vollständige Arbeitsabläufe.
Das ist ein wichtiger Unterschied: Ein einzelner API-Test kann grün sein, obwohl der Ablauf aus Sicht des Nutzers bereits gebrochen ist. Ein einzelner Oberflächentest kann funktionieren, während im Hintergrund falsche Daten geschrieben werden. Erst die Kombination macht aus Tests ein belastbares Sicherheitsnetz.
Dasselbe Sicherheitsnetz muss Alt und Neu prüfen
Tests nur gegen den neuen Stand beantworten eine begrenzte Frage: Funktioniert das, was neu gebaut wurde, so wie die Entwickler es erwarten?
Für eine Modernisierung braucht es eine zweite Frage: Verhält sich der neue Stand in den relevanten Abläufen wie der alte?
Im migration-lab laufen dieselben Charakterisierungs- und End-to-End-Tests gegen beide Systemstände. Dadurch wird funktionale Äquivalenz nicht aus Screenshots oder Erinnerung abgeleitet, sondern kontinuierlich geprüft.
Absolute Gleichheit ist trotzdem nicht immer das Ziel. Wenn der Altbestand beispielsweise ein unsicheres Verhalten enthält, darf die neue Version dieses Verhalten nicht aus falsch verstandener Kompatibilität übernehmen. Solche Abweichungen müssen ausdrücklich entschieden, dokumentiert und in den Tests sichtbar gemacht werden. Ein stiller Unterschied ist ein Fehler. Eine begründete, freigegebene Abweichung ist eine Modernisierungsentscheidung.
Sechs Etappen sind besser als ein großer Umschalttermin
Das Labor teilt die Modernisierung in sechs ausführbare Zustände. Jede Etappe besitzt einen eigenen Git-Tag, einen lauffähigen Stand und dokumentierte Prüfergebnisse.
Der konkrete Technologiepfad führt unter anderem von Spring Boot 1.5 über Zwischenstände auf Spring Boot 4.1 und von Java 8 auf Java 25. Das AngularJS-Frontend wird nicht in einem unübersichtlichen Hybrid dauerhaft mitgeschleppt, sondern hinter einer klaren URL-Grenze schrittweise durch Angular 22 ersetzt.
Für eine Organisation ist diese Struktur wichtiger als die Versionsnummern:
- Fortschritt wird an ausführbaren Zuständen gemessen, nicht an Prozentangaben im Projektplan.
- Fehler lassen sich einer begrenzten Änderung zuordnen.
- Fachliche Freigaben können je Etappe erfolgen.
- Der Bestand bleibt während der Übergangsphase erreichbar.
- Eine Rückkehr zum letzten freigegebenen Stand bleibt möglich.
Eine Etappe ist erst abgeschlossen, wenn das System läuft, das Sicherheitsnetz besteht und die Entscheidung nachvollziehbar dokumentiert ist. „Der Code ist fertig” ist dafür kein ausreichendes Kriterium.
Modernisierung endet nicht beim Anwendungscode
Viele Migrationsprojekte konzentrieren sich auf Frameworks und Oberflächen. Das ist sichtbar, aber unvollständig. Ein geschäftskritisches System besteht ebenso aus Datenbank, Schemaführung, Protokollierung, Gesundheitsprüfungen, Sicherungen und Wiederherstellung.
Deshalb umfasst der Zielstand des migration-lab auch den Betrieb: containerisierte Auslieferung, TLS, Health-Prüfungen, Backups und eine tatsächlich ausgeführte Wiederherstellungsprobe. Eine Sicherung, die nie zurückgespielt wurde, ist kein Nachweis. Sie ist eine Annahme.
Für Auftraggeber bedeutet das: Der Abnahmegegenstand darf nicht nur „moderne Anwendung” heißen. Er muss auch beschreiben, wie der neue Stand überwacht, gesichert, aktualisiert und im Störungsfall wiederhergestellt wird.
KI kann beschleunigen, aber keinen Nachweis ersetzen
Ein Teil des Projekts untersucht KI-gestützte Testgenerierung unter einem vorab festgelegten Protokoll. Dokumentiert wurden 24 Modellaufrufe mit Kosten von 0,65 Euro. 88 generierte Testmethoden wurden nach Prüfung übernommen.
Der interessanteste Befund war nicht eine besonders hohe Kennzahl, sondern eine zunächst irreführende: Die ersten Ergebnisse wirkten nahezu perfekt, berücksichtigten aber nur jene Testklassen, die überhaupt kompilierten. Nach der Reparatur lagen die gemessenen Werte bei 90,5 Prozent Zeilenabdeckung und 73,2 Prozent Mutation Score.
Das ist kein Argument gegen KI. Es ist ein Argument gegen ungeprüfte Automatisierung. Ein Werkzeug kann Tests schnell erzeugen. Ob diese Tests relevante Fehler erkennen, muss weiterhin durch reproduzierbare Messung und fachliche Prüfung belegt werden.
Was eine belastbare Modernisierung auszeichnet
Wer ein bestehendes Fachsystem modernisieren lässt, sollte vor der Beauftragung fünf konkrete Antworten verlangen:
- Wie wird der heutige Funktionsumfang festgehalten? Eine Funktionsliste allein reicht nicht, wenn kritische Abläufe nur im Systemverhalten sichtbar sind.
- Welche Tests laufen gegen Alt- und Zielstand? Ohne gemeinsamen Vergleich bleibt funktionale Äquivalenz eine Behauptung.
- Welche ausführbaren Zwischenstände gibt es? Ein Projekt, das erst am Ende erstmals vollständig läuft, verschiebt jedes wesentliche Risiko nach hinten.
- Welche Abweichungen sind erlaubt und wer gibt sie frei? Sicherheit, Datenschutz und neue fachliche Anforderungen können bewusste Unterschiede notwendig machen.
- Wie werden Betrieb und Wiederherstellung nachgewiesen? Monitoring-Konzept und Backup-Datei sind keine Wiederherstellungsprobe.
Diese Fragen sind unabhängig davon, ob das Ausgangssystem Java, .NET, PHP oder eine andere Plattform verwendet. Die Technologien ändern sich. Das Risikomuster bleibt gleich.
Ein öffentlicher Referenzfall statt einer Folie
Das vollständige Repository auf GitHub enthält Quellcode, sechs Migrationsstände, Architekturentscheidungen, Messprotokolle, bekannte Grenzen und einen deutschsprachigen Leitfaden. Der modernisierte Zielstand ist zusätzlich als Live-Demonstrator erreichbar.
Sebastian Kern erklärt den Aufbau und die wichtigsten Entscheidungen außerdem in einem elfminütigen Fachvideo.
Wir veröffentlichen dieses Projekt, weil Modernisierungskompetenz schwer durch eine Leistungsbeschreibung zu belegen ist. Ein reproduzierbarer Ausgangsstand, ein prüfbarer Migrationspfad und offen dokumentierte Ergebnisse sind aussagekräftiger als die Behauptung, man kenne sich mit Legacy-Systemen aus.
Wer ein gewachsenes System ablösen oder schrittweise modernisieren muss, kann uns die Ausgangslage über die Kontaktseite schildern. Für eine erste Einordnung genügen Technologie, Betriebsalter, vorhandene Tests, Datenvolumen und der fachlich kritischste Ablauf.