Altsysteme ablösen ohne Big Bang: Softwaremodernisierung, die funktioniert

Fast jedes gewachsene Unternehmen im DACH-Raum trägt mindestens ein System mit sich herum, das niemand mehr anfassen will: undokumentiert, von längst pensionierten Mitarbeitern gewartet, geschäftskritisch und unkündbar. Die Versuchung, es in einem großen Wurf neu zu schreiben, ist verständlich, und zugleich der zuverlässigste Weg, viel Geld zu verbrennen, ohne den Betrieb je abzulösen. Dieser Artikel beschreibt, wie sich Legacy-Systeme schrittweise ersetzen lassen, während der Laden weiterläuft.

Warum die große Neuschreibung scheitert

Die Big-Bang-Ablösung folgt einer einfachen, falschen Logik: Man baut zwei bis vier Jahre lang ein neues System, schaltet an einem Wochenende um, und am Montag ist alles besser. In der Praxis scheitert das aus drei Gründen.

Erstens liefert das Projekt über seine gesamte Laufzeit keinen Wert, es verbraucht nur. Budget, das nichts produziert, gerät unter Druck, sobald Konjunktur oder Prioritäten kippen, und genau dann wird das halbfertige neue System abgeschaltet, während das Altsystem weiterläuft.

Zweitens ist das Ziel beweglich. Während Sie das neue System bauen, steht das alte nicht still: regulatorische Anpassungen, neue Schnittstellen, Bugfixes. Je länger das Projekt dauert, desto größer der Abstand zwischen dem, was Sie gebaut haben, und dem, was das Geschäft inzwischen braucht.

Drittens steckt in jedem alten System unsichtbares Wissen: die undokumentierte Sonderbehandlung für einen Vertragstyp, der Workaround für eine Buchung über den Jahreswechsel, die Toleranz gegenüber einem fehlerhaften Upstream-Format. Diese Regeln sind oft der eigentliche Wert des Systems und tauchen in keiner Spezifikation auf. Eine Neuschreibung verliert sie und entdeckt sie erst beim ersten Produktionsfehler wieder.

Das Muster ist seit Jahrzehnten dokumentiert: Die viel zitierten CHAOS-Reports der Standish Group zeigen über Jahre hinweg, dass größere IT-Vorhaben überproportional häufig scheitern oder massiv über Budget und Zeit laufen. Die Größe des Vorhabens ist dabei die Hauptursache.

Das Strangler-Fig-Muster

Die Alternative hat Martin Fowler nach der Würgefeige benannt: einer Pflanze, die an einem Baum emporwächst, ihn nach und nach umschließt und am Ende seine Stelle einnimmt, ohne dass der Baum je auf einen Schlag fällt.

Übertragen auf Software heißt das: Sie lassen das Altsystem laufen und bauen das neue Stück für Stück daneben. Eine Funktion nach der anderen wird im neuen System nachgebaut, und sobald sie sauber läuft, wird der Verkehr dafür umgeleitet. Das Altsystem schrumpft mit jeder umgezogenen Funktion, bis nichts mehr darauf zeigt und es sich abschalten lässt.

Der entscheidende Baustein ist eine Fassade davor: ein Routing-Layer (in der Praxis ein API-Gateway, ein Reverse Proxy oder eine vorgelagerte Service-Schicht), durch den jeder Aufruf läuft. Die Clients wissen nicht, ob ihre Anfrage hinter der Fassade vom alten oder vom neuen System beantwortet wird. Genau diese Unkenntnis macht die schrittweise Umstellung möglich.

Der Vorteil gegenüber dem Big Bang ist nicht nur das geringere Risiko: Jeder umgezogene Baustein liefert sofort Wert, und Sie lernen das alte System beim Ablösen kennen, statt vorab zu raten.

Der Anti-Corruption-Layer

Solange altes und neues System parallel laufen, müssen sie miteinander reden. Und das alte Datenmodell ist meistens genau das, was Sie loswerden wollen, kryptische Feldnamen, in ein Statusfeld gequetschte Geschäftslogik, Annahmen aus den Neunzigern. Lassen Sie es ungefiltert ins neue System, haben Sie die alten Zwänge nur auf eine neue Plattform umgezogen.

Der Anti-Corruption-Layer (der Begriff stammt aus dem Domain-Driven Design) ist die Übersetzungsschicht dazwischen. Er übersetzt das alte Modell in beide Richtungen in das saubere Modell des neuen Systems. Das neue System sieht nie die Eigenheiten des Altsystems, nur das, was der Layer durchlässt. So bleibt der ganze Altlast-Schmutz an einer einzigen, klar abgegrenzten Stelle, statt sich in der neuen Architektur zu verteilen.

Das kostet Aufwand, den manche Teams sich sparen wollen. Ein Fehler: Ohne diese Schicht sickern die Zwänge des Altsystems unbemerkt ein, und in zwei Jahren haben Sie ein zweites unantastbares System.

Sequenzieren nach Geschäftswert, nicht nach Alter

Beim schrittweisen Ablösen wird die Reihenfolge zur wichtigsten Entscheidung. Der häufigste Reflex ist falsch: Man fängt nicht mit dem ältesten oder hässlichsten Code an, nur weil er am meisten stört. Die brauchbaren Kriterien sind andere. Wo bremst das Altsystem das Geschäft am meisten? Welcher Teil trägt das größte Ausfallrisiko? Und wo ist der Schnitt sauber genug, dass sich eine Funktion herauslösen lässt, ohne den halben Monolithen mitzureißen?

Oft beginnt man bewusst mit einem Baustein von mittlerem Wert und überschaubarer Verflechtung, an dem das Team das Muster erlernt und Vertrauen aufbaut, bevor es an die geschäftskritischen Teile geht. Was Sie vermeiden wollen: zuerst die einfachen Randfunktionen umziehen, das Budget aufbrauchen und den schwierigen Kern, den eigentlichen Grund für die Ablösung, am Ende doch wieder nicht anfassen.

Datenkonsistenz in der Übergangsphase

Solange beide Systeme laufen, stellt sich die unangenehmste Frage des Vorhabens: Wem gehören die Daten, alt oder neu? Während eine Funktion umzieht, wollen oft beide Seiten dieselben Datensätze verändern. Wird das ignoriert, bekommen Sie zwei Wahrheiten und stille Inkonsistenzen, die erst Wochen später als falsche Buchungen oder Reports auffallen.

Drei Muster haben sich bewährt. Erstens: für jeden Datenbereich ein eindeutiges führendes System mit alleiniger Schreibhoheit festlegen, während die andere Seite nur liest. Zweitens: gerichtete Synchronisation über Change Data Capture, statt beide Seiten frei schreiben zu lassen. Drittens: eine befristete Abgleichsprüfung, die beide Bestände vergleicht und Abweichungen meldet, solange der Parallelbetrieb läuft.

Welches Muster passt, hängt vom Datenbereich ab. Was nie funktioniert, ist die Hoffnung, dass sich das von allein einpendelt. Datenkonsistenz in der Übergangsphase muss explizit entworfen werden, nicht entdeckt.

Die Mainframe-Realität im DACH-Raum

Ein großer Teil der ernsthaften Legacy-Last in der DACH-Region sitzt nicht auf alten Webservern, sondern auf dem Mainframe. In Banken, Versicherungen, Logistik und großen Teilen der Verwaltung verarbeiten COBOL und PL/I auf z/OS jeden Tag den Kern des Geschäfts, oft seit Jahrzehnten und zuverlässiger als alles, was später dazukam.

Das verschiebt das Ziel: Den Mainframe komplett loszuwerden ist hier selten sinnvoll, oft teuer, riskant und geschäftlich nicht zu rechtfertigen. Realistisch ist, ihn von einem geschlossenen Block in einen ansprechbaren Dienst zu verwandeln. Genau dafür eignet sich das Strangler-Fig-Muster, weil es keine Totalablösung verlangt: Neue Funktionen entstehen in einer modernen Schicht davor, der Mainframe wird über einen sauberen Anti-Corruption-Layer angesprochen, und nur die geschäftlich lohnenden Teile wandern tatsächlich herunter. Dazu kommt ein reales Personalthema: Die Menschen, die diese Systeme verstehen, gehen in Rente, und ihr Wissen ist oft nirgends festgehalten. Die Ablösung ist deshalb auch ein Rennen gegen das Auslaufen des Wissens, nicht nur gegen die Technik.

Die Falle der scheinbaren Modernisierung

Es gibt einen Weg, der nach Modernisierung aussieht und sich gut verkaufen lässt, ohne das eigentliche Problem zu lösen. Zwei Varianten begegnen einem immer wieder.

Reines Re-Platforming (Lift-and-Shift) nimmt das Altsystem, wie es ist, und verschiebt es auf einen neuen Host, typischerweise in die Cloud. Der Betrieb wird vielleicht günstiger oder elastischer. Aber der unwartbare Code, das verklemmte Datenmodell, die fehlende Dokumentation: alles unverändert mitgezogen, dieselben Zwänge, jetzt mit einer Cloud-Rechnung obendrauf.

Reines API-Wrapping legt eine moderne Schnittstelle über das Altsystem, ohne dahinter etwas zu ändern. Als Zwischenschritt ist das sinnvoll, oft sogar der erste Baustein der Fassade. Zur Falle wird es als Ziel: Eine schöne REST-Schnittstelle vor einem intern weiter brüchigen Monolithen gibt Ihnen ein modernes Etikett und dasselbe Problem darunter.

Beides hat seinen Platz als bewusster Übergangsschritt und wird nur als Endzustand gefährlich. Die ehrliche Frage lautet immer: Haben wir den Zwang darunter aufgelöst oder nur verschoben?

Genauso ehrlich zum Zeitrahmen: Eine ernsthafte Ablösung von Legacy-Systemen über das Strangler-Fig-Muster ist kein Quartalsprojekt, bei einem geschäftskritischen System spricht man realistisch über Jahre. Der Unterschied zum Big Bang ist nicht die Gesamtdauer, sondern dass Sie ab dem ersten Baustein laufend Wert liefern und jederzeit anhalten könnten, ohne mit leeren Händen dazustehen.

Ihr Altsystem ablösen, ohne den Betrieb zu riskieren

DNA Solutions begleitet Unternehmen im DACH-Raum bei der schrittweisen Ablösung von Legacy-Systemen: von der Analyse des Bestands über die Sequenzierung nach Geschäftswert bis zur Fassade, dem Anti-Corruption-Layer und dem kontrollierten Umzug der Daten. Wenn Sie ein System tragen, das niemand mehr anfassen will, und es ablösen wollen, ohne den laufenden Betrieb zu gefährden: Sprechen Sie uns an.