Legacy-System ablösen, ohne den Betrieb zu gefährden

Ein veraltetes System abzulösen ist selten eine rein technische Entscheidung - es ist ein Risiko für den laufenden Betrieb. Die zentrale Frage ist nicht "wie bauen wir das Neue", sondern "wie kommen wir dorthin, ohne dass das Alte vorher ausfällt oder das Neue am Tag eins alles lahmlegt".

Warum ein harter Umstieg selten funktioniert

Ein "Big Bang"-Umstieg - am Freitag das alte System abschalten, am Montag läuft das neue - klingt einfach, ist aber riskant. Jeder unentdeckte Fehler im neuen System trifft sofort den vollen Betrieb, ohne Fallback. Bei geschäftskritischen Systemen ist das ein Risiko, das sich meist nicht rechtfertigen lässt. Das gilt besonders, wenn das Altsystem über Jahre gewachsene Sonderfälle abbildet, die in der neuen Lösung leicht übersehen werden - etwa eine Rabattregel, die nur für drei Bestandskunden gilt, aber seit Jahren stillschweigend im Code steckt.

Strangler Fig: Schrittweise ablösen statt ersetzen

Das Strangler-Fig-Muster (benannt nach dem Würgefeigenbaum, der einen Wirtsbaum langsam umschließt) löst ein Legacy-System Stück für Stück ab, statt es auf einmal zu ersetzen. Konkret bedeutet das:

Einzelne Funktionsbereiche werden identifiziert und einzeln migriert - zum Beispiel zuerst die Kundenverwaltung, danach erst die Auftragsabwicklung.
Neue und alte Funktionalität laufen parallel, oft über eine Zwischenschicht (Proxy oder Routing), die entscheidet, welches System für welche Anfrage zuständig ist.
Nach und nach wandert mehr Funktionalität ins neue System, bis das alte irgendwann ganz abgeschaltet werden kann.

Der Vorteil: Fehler im neuen System betreffen nur den bereits migrierten Teilbereich, nicht den gesamten Betrieb. Der Nachteil: Die Zwischenschicht selbst ist zusätzlicher Aufwand, und der Gesamtprozess dauert typischerweise länger als ein harter Umstieg - oft mehrere Monate bis über ein Jahr, je nach Größe des Systems.

Parallelbetrieb: Beide Systeme gleichzeitig laufen lassen

Bei Parallelbetrieb laufen altes und neues System für einen definierten Zeitraum gleichzeitig, oft mit denselben Daten. Nutzer arbeiten während dieser Phase noch mit dem gewohnten System, während das neue im Hintergrund validiert wird - etwa indem beide Systeme dieselben Eingaben verarbeiten und die Ergebnisse verglichen werden. Erst wenn das neue System nachweislich zuverlässig läuft, erfolgt der eigentliche Wechsel.

Der Aufwand für Parallelbetrieb wird oft unterschätzt: Beide Systeme müssen synchron mit denselben Daten versorgt werden, und jemand muss die Abweichungen zwischen beiden Systemen systematisch auswerten - nicht nur stichprobenartig. Für einen aussagekräftigen Vergleich sind meist mehrere Wochen mit echtem Produktionsbetrieb nötig, nicht nur ein paar Testtage.

Datenmigration ist oft das unterschätzte Risiko

Nicht die neue Software selbst ist meist das größte Risiko, sondern die Übertragung bestehender Daten aus dem Altsystem - insbesondere wenn Datenstrukturen über Jahre gewachsen und inkonsistent geworden sind. Typische Fallstricke:

Dubletten und inkonsistente Formate: Adressen, Kundennamen oder Artikelnummern, die über Jahre auf unterschiedliche Weise erfasst wurden.
Fehlende referenzielle Integrität: Datensätze, die im Altsystem über technische Umwege verknüpft waren, die im neuen Datenmodell nicht mehr existieren.
Stille Zeichenkodierungsprobleme: Ältere Systeme nutzen manchmal andere Zeichensätze, was bei Umlauten oder Sonderzeichen erst nach der Migration auffällt.
Löschfristen und DSGVO-Konformität: Bei der Migration personenbezogener Daten muss geprüft werden, ob Löschfristen aus dem Altsystem korrekt ins neue System übernommen werden.

Plane für die Datenmigration einen eigenen Testlauf mit echten (anonymisierten) Daten ein, bevor der produktive Wechsel stattfindet - inklusive einer stichprobenartigen manuellen Prüfung der migrierten Datensätze durch jemanden, der die Fachdaten kennt.

Ein Big Bang mit Sicherheitsnetz - für kleinere Systeme

Nicht jedes System braucht Strangler Fig oder Parallelbetrieb. Für kleine, klar abgegrenzte Systeme mit überschaubarer Nutzerzahl kann ein sorgfältig vorbereiteter harter Umstieg die günstigere und schnellere Wahl sein - vorausgesetzt, ein Sicherheitsnetz ist eingeplant:

ein vollständiges, getestetes Rollback auf das Altsystem, das innerhalb weniger Stunden aktivierbar ist
ein fester Zeitpunkt mit geringer Nutzung (z. B. Wochenende oder Feiertag) für den Umstieg
ein Team, das am Umstellungstag bereitsteht, um sofort auf Fehler reagieren zu können

Checkliste vor dem Umstieg

Unabhängig von der gewählten Strategie solltest du vor dem produktiven Wechsel folgende Punkte abgehakt haben:

Ist die Datenmigration mit echten (anonymisierten) Daten getestet worden?
Gibt es einen dokumentierten Rollback-Plan, falls der Umstieg scheitert?
Sind alle Sonderfälle aus dem Altsystem im neuen Lastenheft erfasst - auch die, die nur für einzelne Kunden oder Prozesse gelten?
Ist ein fester Ansprechpartner für den Umstellungstag benannt, sowohl auf technischer als auch auf fachlicher Seite?
Weiß das betroffene Team, wie und wann es informiert wird, falls es zu einem Rollback kommt?

Kommunikation: Der unterschätzte Erfolgsfaktor

Eine Systemablösung scheitert selten allein an der Technik - oft am fehlenden Informationsfluss mit den Menschen, die täglich mit dem System arbeiten. Zwei Punkte sind dabei entscheidend:

Betroffene Teams früh einbinden. Die Personen, die das Altsystem täglich nutzen, kennen die Sonderfälle, die in keiner Dokumentation stehen. Ein kurzer Workshop zu Beginn der Migration deckt oft mehr Sonderfälle auf als Wochen an Code-Analyse.

Schulung vor dem Umstieg, nicht danach. Wenn Nutzer erst am Tag des Umstiegs zum ersten Mal mit dem neuen System arbeiten, häufen sich Supportanfragen genau dann, wenn das Team am wenigsten Kapazität dafür hat. Eine kurze Einweisung während der letzten Phase des Parallelbetriebs oder der Strangler-Fig-Migration verhindert das.

Was die Ablösung mit der Anforderungsklärung für das neue System zu tun hat

Eine Migrationsstrategie beantwortet nur die Frage "wie kommen wir sicher vom Alten zum Neuen". Sie ersetzt nicht die Frage, was das neue System eigentlich können soll. Gerade bei Legacy-Systemen besteht die Versuchung, das neue System 1:1 wie das alte zu spezifizieren - inklusive aller historisch gewachsenen Umwege. Sinnvoller ist es, die Migration auch als Gelegenheit zu nutzen, den zugrunde liegenden Prozess neu zu bewerten und im Lastenheft für das neue System nur das festzuhalten, was tatsächlich noch gebraucht wird.

Welche Strategie passt zu deinem Fall?

Als grobe Orientierung: Strangler Fig eignet sich gut für große, funktional trennbare Systeme mit vielen Nutzern, bei denen ein kompletter Ausfall nicht tragbar ist. Parallelbetrieb eignet sich, wenn Datenintegrität besonders kritisch ist und du Ergebnisse beider Systeme über einen Zeitraum verlässlich vergleichen kannst. Für kleine, klar abgegrenzte Systeme kann ein sorgfältig getesteter harter Umstieg mit Rollback-Plan ausreichend und deutlich günstiger sein.

Fazit

Die Ablösung eines Legacy-Systems scheitert selten an der neuen Technologie, sondern an einer zu riskanten Migrationsstrategie. Wer schrittweise vorgeht und die Datenmigration von Anfang an als eigenes Risiko behandelt, kann den Betrieb während der gesamten Umstellung aufrechterhalten.

Häufig gestellte Fragen

Warum ist ein harter Umstieg (Big Bang) bei Legacy-Systemen riskant?

Weil jeder unentdeckte Fehler im neuen System sofort den vollen Betrieb trifft, ohne Fallback auf das alte System. Bei geschäftskritischen Systemen lässt sich dieses Risiko meist nicht rechtfertigen - insbesondere, wenn das Altsystem über Jahre gewachsene Sonderfälle abbildet, die leicht übersehen werden.

Was ist das Strangler-Fig-Muster bei der Systemablösung?

Ein Migrationsansatz, bei dem einzelne Funktionsbereiche schrittweise vom Altsystem ins neue System überführt werden, während beide parallel über eine Zwischenschicht laufen. Fehler im neuen System betreffen dabei nur den bereits migrierten Teilbereich.

Was ist beim Parallelbetrieb während einer Systemmigration zu beachten?

Beim Parallelbetrieb laufen altes und neues System gleichzeitig, oft mit denselben Daten, damit das neue System validiert werden kann, bevor der eigentliche Wechsel erfolgt. Wichtig ist ein klar definierter Zeitraum, meist mehrere Wochen, und eine verlässliche Methode, die Ergebnisse beider Systeme systematisch zu vergleichen.

Was ist das größte unterschätzte Risiko bei der Ablösung eines Legacy-Systems?

Häufig nicht die neue Software selbst, sondern die Migration bestehender, über Jahre gewachsener und oft inkonsistenter Daten aus dem Altsystem - etwa Dubletten, fehlende referenzielle Integrität oder DSGVO-relevante Löschfristen. Ein eigener Testlauf mit echten, anonymisierten Daten vor dem produktiven Wechsel reduziert dieses Risiko erheblich.

Wann reicht ein harter Umstieg statt Strangler Fig oder Parallelbetrieb?

Für kleine, klar abgegrenzte Systeme mit überschaubarer Nutzerzahl kann ein sorgfältig vorbereiteter harter Umstieg mit getestetem Rollback-Plan die schnellere und günstigere Wahl sein.