Geschäftskritische Systeme modernisieren. Änderungen gezielt absichern.

Viele Java-Anwendungen müssen technisch erneuert werden, während Betrieb und fachliche Weiterentwicklung weiterlaufen. Große Versionssprünge, veraltete Komponenten und geringe Testabdeckung erhöhen dabei das Risiko unerwünschter Änderungen.

Ich modernisiere solche Systeme schrittweise – von der technischen Bestandsaufnahme bis zur Umsetzung. Relevante Abläufe und Ergebnisse werden vor der Änderung festgehalten und nach jedem Migrationsschritt erneut geprüft. Dadurch lassen sich Regressionen früh erkennen und Ursachen gezielt eingrenzen.

Typische Modernisierungssituationen

• Java-Versionswechsel und Migrationen von Java EE zu Jakarta EE.
• Framework- und Application-Server-Upgrades.
• Nicht mehr unterstützte Plattformen und Bibliotheken sowie Security- und Compliance-Anforderungen.
• Ablösung von CMP/EJB-2-Persistenz durch JPA sowie Hibernate-/JPA-Upgrades.
• Modernisierung etablierter Java-Webanwendungen, beispielsweise mit JSF.
• Erhalt der Kompatibilität bestehender REST-Schnittstellen.
• Geringe Testabdeckung und schwer einschätzbare Regressionsrisiken.
• Gezielte Architekturänderungen, Austausch einzelner Komponenten oder Herauslösen eines Services.

Je nach Ziel kann die Modernisierung innerhalb des bestehenden Systems erfolgen oder die Architektur stärker verändern – bis hin zur Aufteilung in Services oder einer Cloud-Migration. Das technische Vorgehen richtet sich nach den fachlichen Anforderungen, den Betriebsbedingungen und der angestrebten Zielarchitektur.

Vorgehen und Ergebnisse

1. Bestand und Risiken klären. Code, Abhängigkeiten, kritische Abläufe und technische Randbedingungen werden untersucht. Daraus werden Umfang und Reihenfolge der Migrationsschritte abgeleitet.
2. Referenzverhalten festhalten. Vorhandene Tests werden genutzt und an entscheidenden Stellen ergänzt. Relevante Ergebnisse und Messwerte bilden die Vergleichsbasis für die Migration.
3. In überschaubaren Schritten migrieren. Kleine, prüfbare Änderungen vereinfachen Fehlersuche und Abstimmung. Wiederholbare Quellcode-Änderungen werden soweit sinnvoll automatisiert; KI unterstützt bei Analyse, Tests und Implementierung.
4. Ergebnisse vergleichen und stabilisieren. Die relevanten Szenarien werden erneut ausgeführt. Unerwartete Unterschiede werden analysiert; beabsichtigte Änderungen werden dokumentiert.

Je nach Auftrag gehören dazu ein technischer Befund mit Stufenplan, Baseline-Tests und Prüfkriterien, die eigentlichen Migrationsänderungen, dokumentierte Vergleichsergebnisse und Empfehlungen für die weitere Arbeit.

Was lässt sich vergleichen?

• Persistenz: fachliche Ergebnisse, Transaktions- und Ladeverhalten, Änderungen in der Datenbank, SQL, Ausführungspläne, Anzahl der Abfragen und Laufzeiten.
• REST-Schnittstellen: Statuscodes, Payloads, relevante Header und Seiteneffekte.
• Weboberflächen: gerendertes HTML, visuelle Darstellung und wichtige Interaktionen.

Die Vergleichskriterien werden vor der Migration festgelegt und auf die kritischen Abläufe der Anwendung abgestimmt. Bei Persistenzänderungen wird auch das erzeugte SQL geprüft – etwa auf korrekte Filter und Joins, unerwartete N+1-Abfragen, Anzahl der Abfragen und auffällige Ausführungspläne. Performance- und Datenbankvergleiche basieren auf reproduzierbaren Daten und einer geeigneten Testumgebung.

Engineering, Automatisierung und KI

Mehr als 20 Jahre Erfahrung mit Java-Systemen, Datenbanken, Schnittstellen und produktionskritischen Anwendungen bilden die technische Grundlage.

KI nutze ich regelmäßig im Entwicklungsalltag – zum Erschließen bestehender Codebasen, für Testszenarien und Testgerüste, bei Implementierung und Refactoring sowie für Dokumentation und Reviews. In Kundenprojekten erfolgt der Einsatz ausschließlich innerhalb der freigegebenen Werkzeuge und Vorgaben.

Für wiederholbare, regelbasierte Quellcode-Änderungen nutze ich OpenRewrite. Die erzeugten Änderungen bleiben prüfbar und werden mit denselben technischen Maßstäben bewertet wie manuell geschriebener Code.

Zur Modernisierung gehört auch, nicht mehr gepflegte Bibliotheken abzulösen, bekannte Schwachstellen durch geeignete Updates zu beheben und die Codequalität mit statischer Analyse kontinuierlich zu prüfen.

Strukturiertes Vorgehen

Bestandsaufnahme, Risikobewertung, Test-Baseline, Migration und Ergebnisvergleich folgen einer wiederholbaren Struktur, die an Technologie, Codebasis und Projektumfang angepasst wird. Grundlage sind meine Erfahrungen mit Java-Systemen, Persistenzmigrationen und der Weiterentwicklung bestehender Anwendungen.

Dieses Vorgehen wird schrittweise um wiederverwendbare Checklisten, Automatisierungen, Prompts und kleine Werkzeuge ergänzt.

Formen der Zusammenarbeit

Abgegrenztes Modernisierungsvorhaben: Je nach Umfang übernehme ich die vollständige Modernisierung einer Anwendung oder ein klar abgegrenztes Teilprojekt. Dazu gehören Planung, technische Umsetzung, Abstimmung und die vereinbarte Übergabe.

Mitarbeit im bestehenden Team: Hands-on-Unterstützung bei Java-/Kotlin-Backend-Entwicklung und Modernisierung – auch in langfristigen Mandaten und innerhalb bestehender Delivery-Prozesse.

Analyse oder unabhängige Prüfung: Eine Bestandsaufnahme mit Risiken und Stufenplan kann als Einstieg dienen. Ebenso möglich ist die separate Prüfung einer laufenden oder bereits umgesetzten Migration.

Die Zusammenarbeit erfolgt direkt mit mir, auf Deutsch oder Englisch. Remote-first in Deutschland und Europa mit CET-Überschneidung; Kick-offs und Workshops gerne vor Ort.

Häufige Fragen

Können wir ohne externe KI-Dienste arbeiten?

Ja. Maßgeblich sind Ihre freigegebenen Werkzeuge und Vorgaben zum Umgang mit Daten. Möglich sind intern betriebene Modelle, genehmigte externe Dienste oder eine Umsetzung ohne KI. Kundencode wird nicht ohne Abstimmung an externe Dienste übertragen.

Was, wenn kaum Tests vorhanden sind?

Dann werden zunächst die wichtigsten Abläufe mit wenigen verlässlichen Charakterisierungs- und Integrationstests abgesichert. KI kann beim Finden weiterer Szenarien und beim Erstellen von Testgerüsten unterstützen; die fachliche Aussagekraft muss anschließend geprüft werden.

Muss die Anwendung neu gebaut werden?

Nein. Meist sind überschaubare Änderungen im bestehenden System der bessere Weg. Eine größere Umstrukturierung oder Service-Extraktion sollte ein konkretes technisches oder fachliches Problem lösen.

Ihr Modernisierungsvorhaben

Welche Anwendung soll modernisiert werden, welche Upgrades stehen an und welche Abläufe müssen stabil bleiben? Eine kurze Beschreibung genügt für den Einstieg.