Historisch gewachsene Systeme sind selten schön – aber sie tragen das Tagesgeschäft. Warum die riskante Komplettablösung häufig die falsche Antwort ist und wie ein schrittweiser Umbau im laufenden Betrieb gelingt.
Das Big-Bang-Missverständnis
Fast jedes etablierte Unternehmen kennt sie: die eine Anwendung, die seit fünfzehn Jahren läuft, an der niemand mehr gerne etwas ändert und ohne die trotzdem nichts geht. Solche Systeme sind kein Versagen der Vergangenheit – sie sind das Ergebnis funktionierender Geschäftslogik.
Das macht ihre Ablösung so heikel: Man renoviert ein Haus, in dem gewohnt wird.
Die naheliegende Idee lautet: einmal komplett neu bauen, sauber und modern. In der Praxis ist die Komplettneuentwicklung „auf der grünen Wiese“ jedoch einer der riskantesten Wege. Der Grund ist nicht allein die Technik, sondern Wissen: In gewachsenen Systemen steckt über Jahre kodifizierte Fachlogik – inklusive unzähliger Sonderfälle, die niemand vollständig dokumentiert hat.
Ein Big-Bang-Rewrite bedeutet deshalb häufig doppelte Pflege über Jahre, ein bewegliches Ziel, weil das Altsystem weiterlebt, und einen Wertbeitrag, der erst ganz am Ende entsteht. Eine schrittweise Legacy-Modernisierung setzt genau an diesem Risiko an.
Strangler Fig: der Umbau im laufenden Betrieb
Der bewährte Gegenentwurf ist das Strangler-Fig-Muster, benannt nach der Würgefeige, die einen Baum langsam umschließt und schließlich ersetzt.
Übertragen auf Software heißt das: Neue Funktionalität entsteht neben dem Altsystem. Eine vorgeschaltete Routing- oder Integrationsschicht entscheidet, welche Anfrage bereits die neue und welche weiterhin die alte Implementierung erreicht.
Stück für Stück wandert Verantwortung vom alten ins neue System, bis der Altbestand schrumpft und am Ende abgeschaltet werden kann. Der entscheidende Vorteil: Wert wird kontinuierlich geliefert und das Risiko bleibt in jedem Schritt beherrschbar. Ein Increment lässt sich zurücknehmen – ein Big Bang nur schwer.
Bebauungsplan statt Bauchgefühl
Vor der ersten Zeile Code steht die Bestandsaufnahme: Fähigkeiten, Abhängigkeiten und die lohnendsten Schnitte.
Modernisierung beginnt nicht im Editor, sondern mit Transparenz. Eine Fähigkeitslandkarte („Capability Map“) und eine belastbare Architektur- und Abhängigkeitsanalyse zeigen, wo das System eng verwoben ist und wo natürliche Schnittstellen liegen.
Für die Priorisierung eines ersten Modernisierungsschritts sind vor allem zwei Kriterien entscheidend:
- Geschäftswert: Wo verursacht das Altsystem heute konkret Nachteile – etwa durch lange Entwicklungszeiten, hohe Fehlerkosten, steigende Betriebskosten oder ein schlechtes Kundenerlebnis?
- Herauslösbarkeit: Welcher fachliche oder technische Baustein lässt sich mit überschaubarem Aufwand sauber vom bestehenden System trennen?
Ein guter erster Schnitt verbindet hohen Geschäftswert mit möglichst geringer technischer Kopplung. So entsteht früh sichtbarer Nutzen, ohne unnötig große Risiken einzugehen.
Der ideale erste Schnitt hat hohen Geschäftswert und geringe Kopplung. Er liefert früh sichtbaren Nutzen und schafft Vertrauen für die nächsten Schritte. Eine sogenannte Anti-Corruption Layer schützt dabei das neue Design davor, Altlasten einfach zu übernehmen.
„Nicht das alte System ist das eigentliche Risiko, sondern der Stillstand. Entscheidend ist eine Modernisierung, die Schritt für Schritt Nutzen schafft und dabei beherrschbar bleibt.“
Technische Leitplanken
Damit der schrittweise Umbau nicht zum Blindflug wird, gehören einige Praktiken von Anfang an dazu:
- Tests als Sicherheitsnetz. Charakterisierungstests bilden das Ist-Verhalten ab, bevor Sie es verändern – so merken Sie frühzeitig, wenn etwas kippt.
- Klare Schnittstellen. Explizite APIs und Contract-Tests halten alt und neu sauber getrennt.
- Observability von Tag eins. Ohne Metriken und Logs sehen Sie nicht, ob ein Increment wirklich trägt.
- Daten als schwierigsten Teil ernst nehmen. Migration, Synchronisation und Dual-Writes brauchen einen expliziten Plan – hier entscheidet sich oft der Projekterfolg.
- Automatisierte Auslieferung. Erst günstige und wiederholbare Deployments machen kleine Schritte wirtschaftlich.
Der Business Case
Modernisierung ist kein Selbstzweck, sondern eine Investitionsentscheidung. Ihrem Aufwand muss der Preis des Nichtstuns gegenübergestellt werden: steigende Wartungsanteile am IT-Budget, wachsende Sicherheitsrisiken, schwindende Verfügbarkeit von Fachwissen für alte Technologien und eine Agilität, die immer teurer erkauft werden muss.
Der schrittweise Ansatz hat hier einen unterschätzten Vorteil: Jedes Increment hat einen eigenen, messbaren ROI und kann den nächsten Schritt mitfinanzieren. Statt einer Großwette auf ein fernes Zieldatum entsteht ein Strom kleiner, belegbarer Verbesserungen.
Das Wichtigste in Kürze
- Der Big-Bang-Rewrite ist meist der riskanteste Weg – ungeschriebenes Fachwissen lässt sich nicht auf Knopfdruck neu bauen.
- Das Strangler-Fig-Muster ersetzt Altsysteme schrittweise im laufenden Betrieb und hält das Risiko klein.
- Erst Transparenz, dann Umbau: Priorisieren Sie nach Geschäftswert und Herauslösbarkeit.
Gewachsene IT ist kein Grund zur Resignation. Mit einem klaren Bebauungsplan, den richtigen Leitplanken und dem Mut zum ersten kleinen Schnitt wird aus der Altlast wieder eine tragfähige Grundlage – Schritt für Schritt, ohne den Betrieb unnötig zu gefährden.
FAQ – Legacy-Modernisierung
Sie erneuert Architektur, Technologien, Datenbanken, Schnittstellen und Betriebsprozesse eines Altsystems kontrolliert und schrittweise.
Nein. Stabile Geschäftslogik und funktionierende Komponenten können erhalten und mit modernen Modulen kombiniert werden.
Durch Analyse, Dokumentation, automatisierte Tests, fachliche Abnahmen und schrittweise Migration.
Ja. Pilotmodule, modulare Zielarchitektur und priorisierte Migrationsphasen reduzieren Risiken.
Transparenzhinweis: Bei der Erstellung dieses Beitrags wurde generative KI unterstützend eingesetzt. Inhalt, Faktenprüfung und finale Redaktion erfolgten durch Ancud
