Architektur & Migration

Legacy raus, ohne den Kunden zu zerlegen

Eine 15 Jahre alte Codebasis ist kein Problem. Der Reflex, sie „endlich sauber neu zu schreiben", schon.

„Rewrite" klingt nach Fortschritt. In der Praxis ist es meist die teuerste Art, ein funktionierendes System zu verlieren: Monate ohne Auslieferung, Features, die niemand mehr versteht, und am Ende ein neues System mit den alten Bugs plus ein paar frischen.

Wir migrieren gerade eine Java-Anwendung von WildFly/Vaadin auf Quarkus mit React-Frontend. Die nicht verhandelbare Regel: Byte-Kompatibilität. Was vorher rauskam, kommt nachher identisch raus — Formate, Schnittstellen, Verhalten.

Warum so streng? Weil der Kunde nicht für „moderner" zahlt, sondern dafür, dass nichts kaputtgeht. Modernisierung ist kein Selbstzweck.

Der Weg ist das Strangler-Pattern, nicht der Urknall: Modul für Modul ablösen, jederzeit lauffähig, jederzeit zurückrollbar — vom risikoärmsten Teil aufwärts. Quarkus bringt dabei den konkreten Gewinn: schnellerer Start, kleinerer Footprint, sauber containerisierbar, kein Application-Server-Ballast mehr. Aber das ist die Folge der Migration, nicht ihr Zweck.

Die ehrlichste Modernisierung sieht von aussen langweilig aus: Es läuft weiter, nur besser wartbar.

Wie haltet ihr es — Strangler oder mutiger Schnitt?

◰ Alle Insights