Legacy-Enterprise-System in 3 Monaten ersetzen: Kompromisse, die funktionieren

„Wir haben ein altes System, aber Migration ist unrealistisch und Big-Bang-Cutover kann nicht klappen.“ Hören wir oft. Die Angst ist gesund — vor dem Rewrite, der zum 18-Monats-Projekt ohne funktionierendes Ergebnis wird. Für JUST war es umgekehrt: das Legacy-System versagte, und wir hatten 3 Monate für den vollständigen Ersatz, weil die Lizenz auslief.

Wir haben es geschafft. So — und das haben wir bewusst aus der ersten Version weggelassen, damit es geht.

Regel 1: Scope-Triage vor dem Kickoff

JUSTs Legacy-System deckte ~120 Business-Use-Cases ab. Volle Replikation = 9-12 Monate. Drei Monate geht nur, wenn Scope auf Must-have an Tag 1 Produktion geschnitten wird.

Triage mit CFO und IT-Manager in einem Raum, jedes Feature in einen von vier Buckets:

• Tag 1 MUSS (40 %): ohne das steht das Geschäft. Provisionen, Verkäufer-Bestellungen, Core-CRM.
• Tag 30 OK (25 %): fehlt, aber Admin kann 30 Tage manuell. Reporting-Dashboards, einige Admin-UIs, historische Vergleiche.
• Tag 90 OK (20 %): niemand würde es 3 Monate bemerken. Bulk-Export, einige Third-Party-Integrationen.
• Tag 360 VIELLEICHT (15 %): niemand nutzt es wirklich. Legacy-Features, die jahrelang niemand angefordert hat.

Ergebnis: 40 % an Tag 1, 65 % in einem Monat, 85 % in einem Quartal. 15 % nie geliefert — niemand hat gefragt.

Regel 2: Core-Datenmodell zuerst, UI zuletzt

Im 3-Monats-Rewrite verlockend, mit dem Frontend zu starten — das sieht der Kunde. Aber wenn Sie das Datenmodell später ändern müssen, schreiben Sie auch das Frontend um. Verlorene Zeit.

Für JUST:

• Woche 1-2: Datenmodell (SQL-Schema) + Legacy-Datenmigration
• Woche 3-5: Business-Logik (Provisionen, Bestellungen, gemeinsame Workflows) als Pure-Functions + Unit-Tests
• Woche 6-8: API auf der Business-Logik
• Woche 9-11: UI (React-Admin + Verkäufer-Portal)
• Woche 12: UAT, Dual-Run, Cutover

Frontend zuletzt bedeutet, die Core-Logik ist fertig und getestet, bevor jemand den ersten Button schreibt. Findet UAT etwas in der Business-Logik, ist der Fix einmalig — keine Kaskade durch die UI.

Regel 3: Parallelbetrieb mindestens 2 Wochen

Vor DNS-Switch / User-Cutover müssen beide Systeme parallel laufen und dieselben Transaktionen annehmen. Details:

• Das neue System bekommt eine Kopie jeder Transaktion aus dem Legacy (Read-Replica oder Event-Sourcing)
• Nutzer arbeiten weiter im Legacy
• Nächtlicher Vergleich — stimmen die Zustände beider Systeme?
• Delta > 0,1 % = Alert, Cutover verschoben

Im JUST-Parallelbetrieb fanden wir 4 Fälle, in denen sich die Systeme unterschieden. 3 waren unsere Bugs, 1 war ein Legacy-Bug, den Business nie bemerkt hatte. Cutover erfolgte, als Deltas unter 0,05 % lagen.

Regel 4: Cutover-Tag — Rollback optional, aber geplant

Cutover-Tag für JUST:

• Freitag 22:00 — Legacy-Freeze, Read-Only-Modus
• 22:15 — letzte Datendifferenz von Legacy ins Neue
• 22:30 — DNS-Switch + Nutzer auf neues System umgeleitet
• 22:45 — Smoke-Tests (Login, Bestellung anlegen, Provisionen anzeigen)
• 23:00 — „Go-Live“-Signal oder Rollback-Trigger

Rollback-Trigger: Fallen Smoke-Tests bis 22:55 durch, DNS zurück auf Legacy, Migration reset. Legacy read-only übers Wochenende, erneuter Cutover am Montag. Im 3-Monats-Projekt mit hartem Termin muss Rollback-Plan existieren — wir brauchten ihn nicht. Gute Vorbereitung eliminiert ihn.

Regel 5: Woche 1 post-launch = Bugfixing-Sprint

Produktion unterscheidet sich von Staging. Auch nach gründlichem UAT tauchen Bugs auf — Edge-Cases, die niemand getestet hat. Woche 1 ist reserviert für 100 % Team-Kapazität auf Bug-Fixes. Keine Entwicklung, keine neuen Features, nur Hot-Fixes.

In der Praxis: 10-20 Bugs Woche 1, 3-5 Woche 2, 1-2 Woche 3. Ab Woche 4 zurück zur Roadmap. Wer neue Features für Woche 1 plant, erzeugt Chaos.

Was wir nicht geliefert und nie geliefert haben

Aus den 15 % „Tag 360 VIELLEICHT“:

• Ein Custom-Report für eine alte Quartalsstruktur, die 2019 geändert wurde (niemand hat es erwähnt; Business braucht es nicht)
• Integration zu einem ERP, das der Kunde während des Projekts ersetzt hat
• 3 spezifische Boni für die Top-5-Verkäufer, ersetzt durch einen manuellen Prozess

Das Legacy-System hatte 15 Jahre Features angesammelt, die jemand einmal brauchte und später nicht mehr. Rewrite ist eine Chance zur Vereinfachung. Diesen Zyklus nicht zu wiederholen = nur Features bauen, die Business explizit anfragt.

Zum Mitnehmen

Ein 3-Monats-Legacy-Replacement ist möglich, wenn:

• Scope-Triage mit Business am Anfang, nicht in der Mitte
• Datenmodell → Business-Logik → API → UI, nicht umgekehrt
• Parallelbetrieb > 2 Wochen ohne Deltas
• Cutover-Tag mit Rollback-Plan, auch ungenutzt
• Woche 1 post-launch = Bugfixing-Sprint, keine Roadmap

Mehr Kunden passen in dieses Modell, als der Markt sagt. Die Angst vor Rewrites kommt meist aus einer anderen Geschichte — dem 12-Monats-Projekt, das ohne Triage scheiterte. Triage richtig gemacht und 3 Monate reichen.