Ein Legacy-.NET-System modernisieren, ohne es komplett neu zu schreiben

Der Reflex, wenn sich ein Legacy-.NET-Framework-System langsam und schwer veränderbar anfühlt, ist der Vorschlag eines kompletten Neuaufbaus. Das ist selten die richtige Entscheidung. Ein System, das alt genug wirkt, um als Legacy zu gelten, kodiert meist jahrelange Geschäftsregeln, die niemand vollständig dokumentiert hat, Regeln, die ein Neuaufbau stillschweigend fallen lässt.

Wir bevorzugen das Strangler-Pattern: Neue Funktionalität wird als separate, moderne Services (in der Regel .NET 8+ oder, wo passend, ein JS/TS-Service) gebaut, die hinter derselben Schnittstelle sitzen, die das Legacy-System bereitstellt, während alte Funktionalität Stück für Stück migriert wird, sobald sie ohnehin geändert werden muss.

Die Modernisierung der Datenbank muss meist parallel erfolgen, da Legacy-Schemas oft dieselbe Altlast tragen wie der Anwendungscode. Wir priorisieren die Tabellen und Abfragen, die tatsächlich Leistungs- oder Zuverlässigkeitsprobleme verursachen, statt alles gleichmäßig zu modernisieren.

Charakterisierungstests kommen vor jedem Refactoring, nicht danach. Bevor wir ein Modul mit undokumentierten Geschäftsregeln anfassen, schreiben wir Tests, die sein aktuelles Verhalten exakt so erfassen, wie es ist, Fehler eingeschlossen, damit wir wissen, ob eine spätere Änderung eine bewusste Korrektur oder eine versehentliche Regression war. Ohne diesen Schritt verändert die "Modernisierung" eines Legacy-Systems stillschweigend, was es tut, was oft schlimmer ist, als es nicht anzufassen.

Der Kompetenzübergang im Team ist ein realer Kostenfaktor, den Projektzeitpläne routinemäßig ignorieren. Ein Team, das ein Jahrzehnt lang .NET Framework und WebForms gepflegt hat, wird nicht an einem Wochenende durch Dokumentation lesen fließend in modernem .NET und einem neuen Frontend-Framework. Wir bauen Pairing und Wissenstransfer in das Projekt selbst ein, nicht als separaten Nachgang, damit das Team des Kunden das modernisierte System warten kann, nicht nur wir.

Das Ergebnis ist ein System, das den Geschäftsbetrieb während des gesamten Prozesses aufrechterhält, mit Risiko, das auf kleine, umkehrbare Schritte konzentriert ist, statt auf eine einzelne folgenreiche Umstellung achtzehn Monate später. Es dauert länger, bis eine vollständig moderne Codebasis erreicht ist, aber es ist die Variante, die den Geschäftsbetrieb auf dem Weg dorthin nicht aufs Spiel setzt.