.NET Legacy-Modernisierung: Wie wir monolithische Systeme schrittweise ablösen

Der Reiz eines vollständigen Neubaus ist verständlich. Angesichts einer zehnjährigen .NET-Framework-Anwendung — verhedderter Geschäftslogik, fehlenden Tests, einem Deployment-Prozess, der ein Wartungsfenster um 2 Uhr nachts erfordert — ist die Versuchung groß, von vorne anzufangen. Die Erfahrung erzählt eine andere Geschichte. Branchenerfahrung zeigt konsistent, dass Big-Bang-Rewrites entweder ihr Budget überschreiten, weniger als das Originalsystem liefern, oder beides. Schrittweiser Ersatz, strukturiert nach Martin Fowlers Strangler-Fig-Muster, übertrifft den Neuanfang-Ansatz konstant.

Warum Big-Bang-Rewrites scheitern

Big-Bang-Rewrites scheitern aus strukturellen Gründen, nicht nur aus Ausführungsfehlern. Das Originalsystem enthält Jahre angehäuften Geschäftswissens — Randfälle, regulatorische Anpassungen, hart erarbeitete Performance-Optimierungen — das im Code eingebettet, nicht dokumentiert ist. Ein Rewrite-Team muss gleichzeitig verstehen, was das alte System tut (schwieriger als es aussieht), ein neues System bauen, das dasselbe besser macht, und das alte System während der gesamten Dauer am Laufen halten. Wenn das neue System in Produktion geht, hat es unvermeidlich Lücken, die erst in der Produktion auftauchen — zu einem Zeitpunkt, an dem das Team erschöpft ist und das Unternehmen lange genug Geduld gezeigt hat.

In der Praxis liefern Big-Bang-Rewrites beim Go-live etwa 60–70 % der Funktionalität des Originalsystems, wobei die verbleibenden Lücken 6–18 Monate benötigen, um geschlossen zu werden — oft unter Krisenbedingungen.

Das Strangler-Fig-Muster: Schritt für Schritt

Das Strangler-Fig-Muster — benannt nach einem tropischen Baum, der seinen Wirt schrittweise umhüllt — funktioniert durch schrittweise Umleitung des Traffics vom Legacy-System zu neuen Services, bis das Legacy-System nichts mehr verarbeitet und stillgelegt werden kann.

Die empfohlene Implementierungssequenz:

1. API-Gateway als Fassade einführen — Sämtlicher Traffic zum Legacy-System läuft über ein Gateway (Azure API Management oder Kong in unserem typischen Stack). Zunächst proxied das Gateway alles zum Legacy-System. Dies ist eine Deployment-Änderung, keine funktionale Änderung, und kann risikofrei in Produktion gehen.
2. Ersten Extraktionskandidaten identifizieren — Mit Domain-Driven-Design-Prinzipien identifizieren wir Bounded Contexts im Monolith. Der erste Extraktionskandidat sollte ein Modul mit klaren Interfaces, begrenzter Datenkopplung und hoher Änderungsrate sein — oft ein Berichtmodul, Benachrichtigungsservice oder Benutzerauthentifizierungskomponente.
3. Neuen Service parallel aufbauen — Der neue Microservice wird gebaut, getestet und im Shadow-Mode in Produktion deployed: Er empfängt dieselben Anfragen wie die Legacy-Komponente, und seine Antworten werden protokolliert, aber nicht an Nutzer ausgespielt. Shadow-Testing deckt Diskrepanzen vor jedem Nutzerimpact auf.
4. Canary-Cutover — Traffic wird schrittweise zum neuen Service verschoben: 5 %, 25 %, 50 %, 100 %. Jeder Schritt wird mindestens 48 Stunden gehalten, mit automatischen Rollback-Triggern, wenn Fehlerquoten die Legacy-Baseline um mehr als 0,1 % überschreiten.
5. Legacy-Komponentenlöschung — Erst nachdem 100 % des Traffics 30 Tage lang auf dem neuen Service war, wird der Legacy-Komponentencode gelöscht und seine Datenbanktabellen archiviert.

Datenbank-Dekomposition

Datenbank-Dekomposition ist der schwierigste Teil der .NET-Legacy-Modernisierung. Monolithische Anwendungen haben typischerweise eine einzelne große SQL-Server-Datenbank mit umfangreicher Nutzung von Stored Procedures, Triggern und tabellenübergreifenden Joins, die Geschäftslogik enkodieren. Die Dekomposition erfordert:

• Event-Sourcing an der Grenze — Vor der Datenbankaufteilung wird Event-Publishing bei Schreiboperationen eingeführt. Neue Services abonnieren Events, anstatt die gemeinsame Datenbank abzufragen.
• Dual-Write-Periode — Während der Migration gehen Schreibvorgänge sowohl in die alte gemeinsame Datenbank als auch in die dedizierte Datenbank des neuen Services. Konsistenzprüfungen laufen stündlich, um Abweichungen zu erkennen.
• Read-Path-Cutover vor Write-Path — Neue Services lesen zunächst aus ihrer eigenen Datenbank; Schreibvorgänge verbleiben auf der Legacy-Datenbank. Dies validiert das Datenmodell, bevor das volle Schreibrisiko übernommen wird.

Zero-Downtime-Cutover in der Praxis

Zero-Downtime ist keine einzelne Technik — es ist eine Disziplin, die auf jeder Schicht angewendet wird. Datenbankschemaänderungen verwenden Expand-Contract-Migrationen (niemals DROP oder RENAME in Produktion ohne mehrstufigen Übergang). Konfigurationsmanagement nutzt Feature-Flags (LaunchDarkly oder Äquivalent) zur Entkopplung von Deployment und Release. Blue-Green-Deployment auf Infrastrukturebene stellt sicher, dass Rollback eine DNS-Änderung ist, kein Re-Deployment. Als Referenzpunkt kann eine gut durchgeführte Migration eines .NET-Framework-4.6-ERPs auf .NET-8-Microservices eine 14-monatige Migration ohne ungeplante Ausfallzeiten über 22 diskrete Service-Extraktionen erzielen.