Legacy modernisieren ohne Big Bang: Strangler-Fig, Schnittstellen und wann ihr stoppen müsst
Warum komplette Rewrites oft scheitern, wie ihr Funktionalität Stück für Stück ablöst — und welche technischen Voraussetzungen ihr schaffen solltet, bevor das erste Team „nur mal“ parallel baut.
4. Februar 2025 · Abbattista
Ein Rewrite klingt nach Freiheit. In der Praxis bedeutet er oft: zwei Systeme parallel, doppelte Business-Logik und ein Jahr später die Frage, ob das neue System jemals alles kann, was das alte „irgendwie“ konnte.
Das Strangler-Pattern in Klartext
Ihr lasst das Altsystem laufen und fangt neue oder riskante Teile an einer Kante ab: API-Gateway, BFF, oder eine schmale neue Domäne (z. B. Auth, Checkout, Reporting). Traffic wird schrittweise umgeleitet. Das alte System schrumpft, statt in einem Tag abgeschaltet zu werden.
Schnittstellen vor Features
Ohne stabile Grenzen (Contracts, Versionierung, Fehlersemantik) wird jede Extraktion zum Ratespiel. Investiert früh in:
- klare API- oder Event-Verträge,
- Contract-Tests oder Consumer-driven Checks,
- dokumentierte Deprecation-Politik.
Datenmigration als eigenes Risiko
Oft ist Code das kleinere Problem — Daten sind es. Plant idempotente Migrationen, Reconciliation-Jobs und Rollback-Pfade. Ein Read-Model für Reporting kann schneller entkoppeln als ein komplettes Schema-Redesign in einem Rutsch.
Wann ihr stoppen solltet
Wenn das Team nicht mehr erklären kann, welche Nutzer welche Teile des Altsystems noch brauchen, oder wenn jedes Sprint-Ziel „nur noch schnell fixen“ ist: Pause. Ohne Produkt- und Architektur-Klarheit wird stranglen zur Endlosschleife.
Fazit
Modernisierung ist ein Produktproblem mit Technikfolgen. Das Strangler-Pattern gibt euch eine ökonomische und psychologisch erträgliche Kurve — wenn ihr die Schnittstellen ernst nehmt.
Mehr Struktur für die Ersteinschätzung: Legacy Readiness Playbook. Umsetzung und Oberflächen gehören oft zu Webdesign & Entwicklung.
Teilen