Legacy-Modernisierung ohne Big Bang ist dann die richtige Richtung, wenn das Altsystem nicht ausfällt, aber jede sinnvolle Änderung zäh, teuer und riskant macht. Dann bringt eine perfekte Zielarchitektur erst einmal wenig. Entscheidend ist ein erster Schnitt, der geschäftlich relevant ist, fachlich sauber abgegrenzt werden kann und den Betrieb nicht unnötig aufs Spiel setzt. Wer stattdessen auf den großen Umschalttermin hofft, kauft oft vor allem Beruhigung ein.
Viele Unternehmen merken den Engpass spät, weil der Betrieb ja noch läuft. Genau das ist das Problem. Ein System kann technisch stabil sein und geschäftlich trotzdem längst bremsen. Wenn Preisänderungen, neue Partner oder geänderte Freigaben jedes Mal mehrere Teams, Sonderlogik und manuelle Kontrollen auslösen, blockiert Legacy nicht irgendwann das Wachstum, sondern schon jetzt.
Die eigentliche Frage ist deshalb nicht, welches System am ältesten aussieht. Sie lautet: Welcher Ablauf verliert heute sichtbar Zeit, Marge oder Steuerbarkeit und lässt sich zuerst aus dem Bestand lösen, ohne den Betrieb zu gefährden?
Woran Sie erkennen, dass Legacy wirklich zum Wachstumsengpass wird
Architekturfolien helfen bei dieser Diagnose kaum. Aussagekräftiger ist der letzte echte Änderungsfall. Musste für eine kleine fachliche Anpassung an mehreren Stellen im Bestand gearbeitet werden? Gab es enge Wartungsfenster, manuelle Prüfungen oder Eskalationen nach dem Release? Dann geht es nicht mehr nur um alte Technik, sondern um fehlende Änderbarkeit.
Vier Signale sind besonders belastbar:
- Kleine Änderungen dauern unverhältnismäßig lang: Eine neue Regel, ein zusätzlicher Kanal oder eine geänderte Freigabe braucht länger als ein normaler Release-Zyklus.
- Neue Anbindungen werden jedes Mal zu Sonderprojekten: Partner, Standorte oder Vertriebskanäle lassen sich nicht wiederholbar anschließen.
- Manuelle Übergaben wachsen mit dem Volumen: Excel, E-Mail-Freigaben und Backoffice-Korrekturen verschwinden nicht, sondern werden Teil des Normalbetriebs.
- Releases bleiben operativ heikel: Änderungen sind nur nachts oder mit hoher Eskalationsbereitschaft möglich.
Ein nüchterner Test reicht oft schon: Wie lange dauert eine kleine Regeländerung bis produktiv? Wie viele Systeme müssen dafür angepasst oder getestet werden? Wie oft entstehen danach Störungen im betroffenen Prozess? Wenn mehrere Antworten schlecht ausfallen, ist Legacy kein Komfortthema mehr.
Die meisten Big-Bang-Pläne für geschäftskritische Legacy-Systeme sind kein Zeichen von Entschlossenheit, sondern von schlecht geschnittener Priorisierung.
Das ist bewusst zugespitzt. Ich halte es trotzdem für richtig. Der große Neustart verschiebt die harten Entscheidungen über Domänengrenzen, Datenhoheit und Restfälle nur nach hinten. Später kommen sie teurer zurück.
Als Denkmuster hilft das Strangler-Pattern, bekannt aus Martin Fowlers Beschreibung schrittweiser Ablösung. Das Etikett ist zweitrangig. Was zählt, ist Disziplin: kleine Übergänge, klare Verantwortlichkeiten, überprüfbare Wellen.
Welche Use Cases sich für Legacy-Modernisierung ohne Big Bang zuerst eignen
Ein guter Startkandidat hat drei Eigenschaften: Er erzeugt spürbaren Geschäftsnutzen, lässt sich fachlich sauber schneiden und zwingt den Betrieb nicht sofort in eine riskante Vollumschaltung. Fehlt einer dieser Punkte, wird die erste Welle schnell zum Gegenbeweis für das ganze Vorhaben.
Preis- und Regelwerke vor dem Kern herauslösen
Das ist oft der beste Einstieg, wenn der Kern noch zuverlässig bucht oder verarbeitet, aber die veränderliche Logik das Geschäft ausbremst. Typische Symptome: neue Konditionen dauern Wochen, Ausnahmen landen in Mailketten, Vertrieb und Operations arbeiten mit Schattenregeln, weil Änderungen im Bestand zu teuer oder zu riskant geworden sind.
Der Schnitt funktioniert, wenn Preislogik, Angebotsregeln, Freigaben oder Validierungen vor dem Kern neu aufgebaut werden können, während das Altsystem zunächst weiter für Buchung, Vertragsanlage oder Verbuchung zuständig bleibt. Das neue Modul entscheidet, der Kern verarbeitet das Ergebnis.
Warum dieser Use Case trägt: Eingaben und Ausgaben sind meist definierbar, Testfälle lassen sich aufbauen, und der Nutzen zeigt sich schnell in kürzeren Änderungszyklen. Vor allem verschiebt er die Veränderung dorthin, wo das Geschäft tatsächlich leidet.
Ein konkretes Beispiel aus dem Versicherungsumfeld: Drei Vertriebskanäle nutzen denselben Bestand, aber Tarifausnahmen und Freigaben werden über E-Mail, Tabellen und manuelle Rückfragen abgestimmt. Jede kleine Konditionsänderung zieht Regression im Kern, Abstimmung mit dem Fachbereich und ein enges Release-Fenster nach sich. In so einer Lage sitzt die eigentliche Reibung nicht im Rechenkern, sondern in der teuren Änderungsschleife davor.
Schwierig wird es, wenn Preislogik, Vertragslogik und Kernverarbeitung im Bestand so eng vermischt sind, dass schon kleine Regeländerungen mehrere Kernmodule berühren. Dann entsteht keine saubere Entkopplung, sondern nur eine zusätzliche Schicht vor einem unklaren Innenleben.
Ein häufiger Fehler ist politisch verständlich und operativ falsch: Teams starten mit der lautesten Ausnahme. Besser ist der häufige Standardfall mit hohem Volumen und begrenzten Seiteneffekten. Der erste Schnitt muss nicht spektakulär sein.
Er muss tragen.
Partner- und Kanalanbindung standardisieren
In vielen Organisationen scheitert Wachstum nicht an fehlender Fachfunktion, sondern an Integration. Ein neuer Partner soll in wenigen Wochen live gehen, daraus wird ein monatelanges Projekt. Stammdaten kommen verspätet, Statusmodelle passen nicht zusammen, Fehler landen in manuellen Rückfragen. Jede Anbindung wird wieder als Sonderfall gebaut.
Hier ist der erste Schritt meist keine neue Oberfläche und auch kein kompletter Plattformwechsel. Zuerst braucht es einen stabilen Integrationspfad: saubere APIs, klare Objektdefinitionen, nachvollziehbare Fehlerbehandlung und eine eindeutige Entscheidung, welches System in der Übergangsphase schreiben darf.
Ein sinnvoller Scope ist zum Beispiel Partner-Onboarding oder Statusrückmeldung. Das ist konkret genug, um messbar besser zu werden, und nützlich genug, um spätere Wellen vorzubereiten. Wenn neue Partner schneller angebunden werden und weniger Punkt-zu-Punkt-Logik entsteht, ist der Nutzen sofort sichtbar.
