Ein geschäftskritisches, gewachsenes Backend-System modernisieren, ohne den laufenden Betrieb zu gefährden: Das ist eine der Situationen, in denen der Reflex "Wir bauen es neu" am teuersten wird. Aus mehreren Modernisierungsprojekten mit Legacy-Vertrags- und Backend-Systemen hat sich für mich eine klare Reihenfolge herauskristallisiert, die zuverlässig funktioniert.
Warum der Big Bang scheitert
Ein monolithisches System in einem Rutsch abzulösen, klingt auf der Roadmap-Folie sauber. In der Realität bedeutet es monatelange Parallelentwicklung ohne produktiven Mehrwert, einen Freeze für alle fachlichen Weiterentwicklungen und einen Cutover-Termin, an dem alles gleichzeitig funktionieren muss. Jede Verzögerung bei einer einzelnen Komponente verzögert das gesamte Projekt. Das Risiko wächst dabei mit jedem Monat, nicht linear, sondern strukturell.
Der bessere Weg: fachliche Zerlegung vor technischer Migration
Der wirksamere Ansatz beginnt nicht mit der Frage "Welche Technologie?", sondern mit der Frage "Welche fachlichen Domänen stecken eigentlich in diesem Monolithen?". Erst wenn eine monolithische Anwendung fachlich sauber in domänenspezifische Services zerlegt ist, auch nur auf dem Papier, lässt sich eine Migration in kontrollierbare, einzeln auslieferbare Pakete überführen.
Konkret heißt das:
- Fachliche Strukturierung der Zerlegung, bevor eine Zeile Code migriert wird
- Wertorientierte Priorisierung: welche Domäne zuerst, basierend auf Risiko und Geschäftsnutzen, nicht auf technischer Bequemlichkeit
- Durchgängige Synchronisierung von Produkt-Roadmap und Architekturstrategie, damit beide Seiten dieselbe Reihenfolge verfolgen
- Enge Abstimmung zwischen Fachbereichen, IT-Architektur und externen Dienstleistern. Gerade bei Legacy-Systemen ist Wissen oft an wenige Köpfe gebunden
Der Faktor, der am häufigsten unterschätzt wird
Legacy-Modernisierung ist fast immer auch ein Wissensproblem. Die Personen, die die ursprüngliche Systemlogik verstehen, sind selten dieselben, die die neue Zielarchitektur bauen. Ein strukturierter Modernisierungspfad macht dieses Wissen explizit: durch dokumentierte Abhängigkeiten, nachvollziehbare Entscheidungen und Coaching der Teams, die die neuen Services langfristig verantworten.
Kontrollierte Modernisierung heißt nicht langsamer. Es heißt, dass jeder einzelne Schritt für sich funktionsfähig und rückabwickelbar ist, statt auf einen einzigen Stichtag zu wetten.
Das Ergebnis ist eine strukturierte Grundlage, auf der ein geschäftskritisches System kontrolliert weiterentwickelt werden kann, ohne dass der Betrieb an einem einzigen Tag auf dem Spiel steht.