Ein Big-Bang wirkt auf dem Whiteboard verlockend: altes System abschalten, neue Plattform aktivieren, technische Schulden hinter sich lassen. In realen Geschäftssystemen hängen jedoch Daten, Schnittstellen, Sonderfälle und operative Routinen zusammen, die selten vollständig dokumentiert sind. Je größer der Sprung, desto mehr unbekannte Annahmen müssen gleichzeitig stimmen.
Modernisierung beginnt mit Beobachtbarkeit
Bevor Komponenten ersetzt werden, muss sichtbar werden, wie das bestehende System tatsächlich arbeitet. Welche Schnittstellen werden genutzt? Wo treten Fehler auf? Welche Datenpfade sind kritisch? Welche manuellen Eingriffe halten Abläufe heute stabil?
Logs, Metriken, nachvollziehbare Deployments und gezielte Tests sind deshalb nicht nur spätere Qualitätsmaßnahmen. Sie schaffen die Grundlage, Veränderungen überhaupt kontrolliert bewerten zu können.
Einen technischen Schnitt wählen
Der erste Modernisierungsschritt sollte klein genug sein, um sein Risiko zu verstehen, und relevant genug, um echte Erkenntnis zu liefern. Geeignete Schnitte können eine klar begrenzte API, ein isolierbarer Hintergrundprozess, eine besonders fehleranfällige Integration oder ein Frontend-Bereich mit stabilen Backend-Verträgen sein.
Für jeden Schnitt sollten fünf Punkte feststehen:
- erwartetes Ergebnis und klare Grenze,
- betroffene Daten und Abhängigkeiten,
- Abnahmekriterien und relevante Tests,
- Beobachtbarkeit nach dem Release,
- Rückfallweg, falls Annahmen nicht tragen.
Verträge stabilisieren, Implementierung bewegen
APIs und Ereignisse können als kontrollierte Grenze zwischen Alt und Neu dienen. Wichtig ist, den Vertrag nicht nur für den Happy Path zu entwerfen. Authentifizierung, Validierung, Idempotenz, Timeouts, Retry, Fehlerzustände und Monitoring bestimmen, ob die Integration im Betrieb belastbar ist.
Wo direkte Entkopplung nicht möglich ist, kann eine Zwischenschicht bestehende Formate übersetzen und Änderungen schrittweise ermöglichen. Diese Schicht ist kein Selbstzweck; sie braucht eine klare Rolle und einen Plan, wie lange sie bestehen soll.
Datenmigration ist ein eigener Workstream
Daten sind häufig riskanter als Anwendungscode. Formate, Pflichtfelder und fachliche Regeln haben sich über Jahre verändert. Eine belastbare Migration prüft deshalb Datenqualität vorab, protokolliert Transformationen, behandelt Ausnahmen bewusst und kann Ergebnisse abgleichen.
Statt alles in einem Lauf umzuschalten, können Dual-Read-, Shadow-Write- oder gestufte Importverfahren sinnvoll sein. Welche Variante passt, hängt von Konsistenzanforderungen und Betriebsrisiko ab.
Fortschritt anders messen
Modernisierung ist nicht nur dann erfolgreich, wenn alter Code verschwindet. Ein guter Schritt reduziert ein konkretes Risiko: Releases werden reproduzierbarer, Fehler früher sichtbar, eine Abhängigkeit kleiner oder eine Schnittstelle verlässlicher. Diese Wirkung lässt sich pro Inkrement prüfen.