Altsysteme ablösen: welche Migrationsstrategie passt?

Welche vier Wege gibt es, wenn ein Altsystem an seine Grenzen stößt?

Bevor jemand über Technik spricht, gehört die Grundsatzfrage auf den Tisch: Was soll mit dem Bestand überhaupt geschehen? Vier Wege stehen offen, und drei davon sind billiger als der vierte. Wer sofort mit „wir bauen neu“ startet, überspringt eine Prüfung, die oft Monate und ein sechsstelliges Budget spart.

Ein Maschinenbauer mit einer Fertigungssteuerung aus dem Jahr 2004 muss nicht zwingend neu bauen. Häufig genügt es, zwei Module herauszuschneiden und den Rest hinter einer sauberen Schnittstelle weiterlaufen zu lassen, bis das Geschäft eine vollständige Ablösung wirklich erzwingt.

• Weiterbetreiben: Das System bleibt, Sie investieren nur in Sicherheitsupdates, Pflege der Betriebsumgebung und einen dokumentierten Notfallplan.
• Kapseln: Der Bestand bleibt intern unverändert, bekommt aber eine moderne Schnittstelle, über die neue Anwendungen ihn ansprechen.
• Neu bauen: Die fachliche Logik wird neu erhoben und als eigene Anwendung umgesetzt — der teuerste, aber auch freieste Weg.
• Ersetzen: Eine Standardlösung übernimmt den Bereich, Ihre Abläufe passen sich dem Produkt an statt umgekehrt.

Diese vier Wege schließen einander nicht aus. Größere Vorhaben kombinieren sie: Der Auftragsteil wird neu gebaut, die Stammdatenpflege durch ein Standardprodukt ersetzt, das Archiv bleibt lesend im Altsystem stehen. Genau diese Mischung ist der Normalfall, nicht die Ausnahme.

Um die Wahl zu treffen, brauchen Sie drei Angaben je Bereich: Wie oft ändert sich dort etwas, wie stark unterscheidet sich Ihr Vorgehen vom Marktüblichen, und wie eng hängt der Bereich an anderen Teilen? Häufige Änderungen bei gleichzeitig branchentypischen Abläufen sprechen für Standardsoftware. Seltene Änderungen an einem Alleinstellungsmerkmal sprechen für Kapseln und Weiterbetreiben.

Warum geht der Wechsel an einem Stichtag so selten gut?

Der Stichtagswechsel — alles Alte aus, alles Neue an, an einem Wochenende — klingt nach klarer Linie und ist in gewachsenen Systemen die riskanteste Variante. Sie sammeln über Monate Änderungen an, die niemand einzeln prüfen kann, und sämtliche Fehler treffen gleichzeitig auf einen produktiven Montagmorgen.

Hinzu kommt ein psychologischer Effekt: Weil ein Rücksprung teuer wäre, wird er nicht ernsthaft geplant. Teams reden sich den Zustand schön, statt zurückzurollen. Kleine, jederzeit rücknehmbare Schritte verhindern genau diese Dynamik.

Ein Umstieg, den Sie nicht am selben Nachmittag zurücknehmen können, ist kein Umstieg, sondern eine Wette.

Wie läuft eine schrittweise Ablösung nach dem Strangler-Fig-Muster ab?

Das Bild stammt von der Würgefeige, die einen Wirtsbaum umwächst, bis der alte Stamm überflüssig ist und verschwindet. Übertragen heißt das: Vor das Altsystem tritt eine Weiche, die jede Anfrage entweder an den Bestand oder an einen neuen Baustein leitet. Sie verschieben Funktion für Funktion, und das Altsystem schrumpft.

Praktisch braucht es dafür drei Dinge: eine Stelle im Datenstrom, an der sich Verkehr umlenken lässt, klar abgegrenzte fachliche Einheiten und die Möglichkeit, den Schalter pro Funktion einzeln umzulegen.

• Weiche einziehen: Ein vorgeschalteter Dienst nimmt alle Aufrufe entgegen und verteilt sie — anfangs zu hundert Prozent an das Altsystem.
• Ersten Baustein herauslösen: meist ein Randbereich mit wenig Verflechtung, etwa Reklamationen oder Stammdatensuche.
• Umschalten: erst für interne Nutzer, dann für einen Standort, dann für alle.
• Alten Code entfernen: der Schritt, den fast alle vergessen — solange beide Fassungen existieren, zahlen Sie doppelte Pflege.

Der letzte Punkt ist der wunde Punkt. Ohne konsequenten Rückbau endet die Ablösung in einer dauerhaften Zwitterlandschaft, die teurer ist als jeder der beiden Ausgangszustände — und die niemand mehr vollständig überblickt.

Damit das Muster trägt, muss die Weiche pro Funktion und pro Nutzergruppe schalten können, nicht nur global. Sonst bleibt Ihnen doch wieder nur ein großer Schalter, und Sie haben den Stichtag lediglich verschoben. Diese Schaltfähigkeit ist selbst ein Stück Software mit Aufwand, Tests und Dokumentation — kalkulieren Sie sie mit ein.

Wozu dient eine Fassade und was ist ein Anti-Corruption-Layer?

Eine Fassade ist eine schlanke Schicht vor dem Altsystem, die dessen Eigenheiten nach außen verbirgt. Aufrufer sprechen mit einer sauberen, dokumentierten Schnittstelle und müssen nicht wissen, dass dahinter eine Datenbank mit Feldnamen wie KZ_STAT_07 liegt.

Ein Anti-Corruption-Layer geht weiter: Er übersetzt nicht nur technisch, sondern begrifflich. Wenn das Altsystem den Kunden als Rechnungsempfänger führt, die neue Anwendung ihn aber als Vertragspartner mit mehreren Lieferadressen versteht, vermittelt diese Schicht zwischen beiden Weltbildern — damit die schiefen Begriffe des Bestands nicht in das neue Modell einsickern.

Beide Schichten sind bewusst Wegwerfcode. Sie leben genau so lange wie der Parallelbetrieb und verschwinden mit dem letzten abgeschalteten Altmodul. Planen Sie sie von Anfang an als temporär und geben Sie ihnen keine eigene Fachlogik, sonst entsteht dort ein drittes System, das niemand ablösen will.

Wie sichern Sie Parallelbetrieb und Rückfallebene ab?

Parallelbetrieb heißt, dass Alt und Neu eine Zeit lang gleichzeitig laufen. Im einfachsten Fall bearbeitet nur eine Seite Schreibvorgänge, während die andere mitliest. Anspruchsvoller, aber sehr aussagekräftig ist der Schattenbetrieb: Die neue Anwendung verarbeitet dieselben Anfragen im Hintergrund, ihre Ergebnisse werden protokolliert und mit dem Bestand verglichen, ohne nach außen zu wirken.

• Legen Sie vor jedem Umschalten fest, wer entscheidet und innerhalb welcher Frist zurückgeschaltet wird.
• Halten Sie die Rückfallebene technisch scharf: Ein Rücksprung, der erst getestet werden muss, ist keiner.
• Vermeiden Sie doppelte Schreibpfade auf denselben Datenbestand — sonst diskutieren Sie hinterher, welche Fassung gilt.
• Begrenzen Sie den Parallelbetrieb zeitlich; üblich sind vier bis zwölf Wochen je Baustein.

Bei einer Hausverwaltung mit rund 6.000 Einheiten lief der Schattenbetrieb für die Nebenkostenabrechnung sechs Wochen mit. Übrig blieben am Ende Abweichungen in drei Sonderfällen mit Gewerbeflächen — Konstellationen, die kein vorab geschriebener Testfall gefunden hätte.

Was tun Sie, wenn Dokumentation fehlt und die Entwickler im Ruhestand sind?

Der Normalfall bei zwanzig Jahre alten Systemen ist nicht die schlechte Dokumentation, sondern gar keine. Was existiert, beschreibt meist einen Stand, den drei Sonderanpassungen später niemand mehr wiedererkennt. Verlassen Sie sich deshalb auf das laufende System selbst statt auf Papier.

• Lesen Sie den Datenverkehr mit: Welche Schnittstellen werden tatsächlich aufgerufen, wie oft, von wem?
• Werten Sie Datenbankinhalte aus — belegte Felder verraten mehr über gelebte Abläufe als jedes Lastenheft.
• Führen Sie moderierte Sitzungen mit Sachbearbeitern und lassen Sie sich echte Vorgänge zeigen, nicht beschreiben.
• Beauftragen Sie den pensionierten Entwickler stundenweise, solange er erreichbar ist — das ist selten teuer und fast immer wertvoll.

Halten Sie die Erkenntnisse dabei fortlaufend fest, statt am Ende ein Dokument zu erzeugen, das niemand liest. Bewährt hat sich eine knappe Beschreibung je fachlichem Baustein: Was tut er, welche Regeln gelten, welche Sonderfälle existieren, wer ist die verantwortliche Person im Fachbereich. Zwei Seiten je Baustein genügen und überleben das Projekt.

Rechnen Sie diese Erhebung als eigenen Projektabschnitt ein. Bei mittelgroßen Systemen sind vier bis acht Wochen Analyse realistisch, bevor die erste Zeile neuer Code entsteht. Wer diesen Posten aus dem Angebot streicht, bezahlt ihn später als Änderungsaufwand — dann zu schlechteren Konditionen.

Welche Reihenfolge, welcher Zeitrahmen und welches Budget sind realistisch?

Sortieren Sie die Bausteine nach Geschäftsrisiko, nicht nach technischer Eleganz. Der Bereich, dessen Ausfall die Auslieferung stoppt oder Rechnungen verhindert, wird nicht zuerst angefasst — er wird zuerst verstanden und zuletzt umgestellt. Beginnen Sie mit einem Bereich, der schmerzhaft genug ist, um Aufmerksamkeit zu bekommen, und harmlos genug, um einen Fehlschlag zu überstehen.

Zwischen diesen beiden Polen ordnen sich die übrigen Bausteine nach zwei Kriterien ein: Wie viel Schmerz verursacht der heutige Zustand, und wie viele Nachbarsysteme hängen an dem Bereich? Ein Modul mit zwölf angebundenen Schnittstellen ist selbst dann spät dran, wenn es fachlich einfach wirkt — die Abstimmung mit allen Beteiligten dauert länger als die Umsetzung.

Für die Kosten gilt der übliche Korridor individueller Software: 15.000 bis 250.000 €. Ein einzelnes herausgelöstes Modul mit klarer Abgrenzung liegt oft bei 15.000 bis 40.000 €. Die vollständige Ablösung eines gewachsenen Kernsystems mit vielen Schnittstellen bewegt sich am oberen Ende und erstreckt sich über zwölf bis vierundzwanzig Monate.

• Analyse und Rekonstruktion der Fachlogik: 10 bis 20 Prozent der Projektsumme.
• Weiche, Fassade und Übersetzungsschicht: 10 bis 15 Prozent, vollständig temporär.
• Neubau der fachlichen Bausteine: der größte Anteil, verteilt über mehrere Ausbaustufen.
• Parallelbetrieb, Abgleich und Rückbau des Alten: 10 bis 15 Prozent, meist unterschätzt.

Halten Sie zusätzlich Mittel für den Altbetrieb bereit. Solange beide Systeme laufen, zahlen Sie Lizenzen, Hosting und Pflege doppelt — ein Posten, der in Angeboten regelmäßig fehlt und über zwei Jahre spürbar zu Buche schlägt.

Woran erkennen Sie, dass ein Ablöseschritt wirklich abgeschlossen ist?

Definieren Sie Abnahmekriterien pro Schritt, nicht nur für das Gesamtvorhaben. Sie sollten vor dem Umschalten schriftlich vorliegen und ohne Auslegungsspielraum prüfbar sein.

• Fachliche Gleichwertigkeit: definierte Vorgänge liefern im neuen Baustein dieselben Ergebnisse wie im Bestand.
• Antwortzeiten liegen nicht über denen des Altsystems, gemessen an denselben Vorgängen.
• Alle Schnittstellen, die den abgelösten Bereich aufrufen, sind umgestellt oder nachweislich stillgelegt.
• Der alte Code ist entfernt, nicht auskommentiert, und die zugehörigen Betriebskosten sind abbestellt.
• Die Fachabteilung hat den Bereich eine vollständige Periode ohne Rücksprung genutzt — bei Abrechnungen also einen kompletten Monatsabschluss.

Erst wenn der letzte Punkt erfüllt ist, gilt ein Schritt als fertig. Alles andere bleibt ein offener Vorgang, der weiter Aufmerksamkeit, Betriebskosten und Budget bindet.