Legacy-Modernisierung: Altsysteme ablösen, ohne den Betrieb zu stoppen

Eine Legacy-Modernisierung löst ein Altsystem ab, ohne den laufenden Betrieb zu unterbrechen: Funktion für Funktion wandert in eine neue Umgebung, während das alte System weiterläuft. Der große Neustart am Wochenende ist die Ausnahme, weil er das gesamte Risiko auf einen Zeitpunkt bündelt. Was zuerst abgelöst wird, entscheidet der fachliche Nutzen.

Legacy-Modernisierung: wann ein System als Altsystem gilt

Nicht das Alter macht ein System zum Altsystem, sondern die Frage, ob es noch änderbar ist. Typische Merkmale: Der Hersteller liefert keine Aktualisierungen mehr, die verwendete Sprachversion bekommt keine Sicherheitsauffrischungen, niemand im Haus kennt den Code vollständig, Tests fehlen, und jede Änderung erzeugt an anderer Stelle Fehler.

Ein System, das seine Aufgabe erfüllt und selten geändert wird, ist trotz hohen Alters kein Fall für eine Ablösung. Kritisch wird es, wenn Fachbereiche warten müssen, weil sich niemand an das System herantraut. Wie sich dieser Zustand aufbaut, beschreibt der Artikel über technische Schulden.

Warum Unternehmen modernisieren

• Sicherheit. Nicht mehr gepflegte Bibliotheken und Betriebssysteme sind offene Türen und in Prüfungen ein Befund.
• Fachliche Blockade. Neue Anforderungen aus Vertrieb oder Produktion lassen sich nicht umsetzen, weil das Datenmodell sie nicht kennt.
• Personal. Für alte Technologien findet sich kaum jemand, und das Wissen hängt an wenigen Köpfen.
• Betriebskosten. Eigene Server, teure Wartungsverträge und manuelle Arbeitsschritte summieren sich.
• Datenschutz. Ohne Rollenmodell und Löschfunktionen ist ein Altsystem schwer nachzuweisen – siehe DSGVO-konforme Softwareentwicklung.

Vor der Entscheidung steht eine nüchterne Frage: Was kostet das Nichtstun? Beantworten lässt sie sich, indem man die Wartezeiten der Fachbereiche, die Störungen des letzten Jahres und den Aufwand für manuelle Umwege zusammenträgt. Erst gegen diesen Wert lässt sich ein Vorhaben bewerten, das über mehrere Etappen läuft.

Strategien von der Kapselung bis zum Neubau

Zwischen Nichtstun und Neubau liegen mehrere Stufen, die sich kombinieren lassen:

• Kapseln. Das Altsystem bleibt, bekommt aber eine definierte Schnittstelle. Neue Anwendungen sprechen nur noch mit dieser Fassade.
• Umziehen. Dieselbe Anwendung läuft in einer neuen Umgebung – geringes Risiko, geringer fachlicher Gewinn.
• Anpassen. Aktualisierung von Sprachversion, Bibliotheken und Datenbank, ohne die Fachlogik zu ändern.
• Neu bauen. Eine Fachdomäne wird neu entwickelt und übernimmt schrittweise den Betrieb.
• Stilllegen. Funktionen, die seit Jahren niemand mehr aufruft, werden abgeschaltet statt übernommen – der günstigste Teil jeder Ablösung.
• Ersetzen. Ein Standardprodukt übernimmt den Bereich; sinnvoll, wenn der Ablauf nicht unternehmensspezifisch ist. Die Abwägung dazu behandelt der Artikel Individualsoftware oder Standardsoftware.

Die Wahl fällt je Fachbereich, nicht für das ganze System. Buchhaltung ersetzen und Disposition neu bauen kann im selben Vorhaben richtig sein.

Legacy-Modernisierung nach dem Strangler-Muster

Das verbreitetste Vorgehen legt eine Weiche vor das Altsystem. Anfragen laufen zunächst vollständig ins alte System; sobald eine Funktion im neuen fertig ist, leitet die Weiche genau diese Anfragen um. Der Umfang des Altsystems schrumpft, bis nichts mehr übrig ist.

Damit das funktioniert, braucht es drei Dinge: eine saubere Schnittstelle zum Altsystem, einen Weg für Daten in beide Richtungen während der Übergangszeit und die Möglichkeit, jede Umleitung sofort zurückzunehmen. Die Datenwege werden dabei wie ein eigenes Projekt behandelt, siehe API-Integration.

Datenmigration ohne Datenverlust

Der aufwendigste Teil ist selten der Code, sondern der Datenbestand. Bewährt hat sich ein wiederholbarer Ablauf: Bestand analysieren, Regeln für Bereinigung und Zuordnung schriftlich festhalten, Migration als Skript ausführen, Ergebnis gegen die Quelle prüfen, Lauf so oft wiederholen, bis die Prüfung sauber ist – und erst dann umschalten.

Ein anonymisiertes Beispiel aus unserer Arbeit: In einem Lieferantenverzeichnis standen 138 Schreibweisen für 75 tatsächliche Lieferanten; erst nach der Zusammenführung waren 1 922 Positionen auswertbar. Solche Bereinigungen gehören vor die Migration, nicht danach. Als Zielstruktur bewährt sich eine Datenbank, die strukturierte und flexible Felder zugleich trägt und Prüfregeln selbst durchsetzt.

Wie wir eine Ablösung planen

Wir beginnen jede Legacy-Modernisierung mit einer Bestandsaufnahme: Welche Fachbereiche hängen am System, welche Datenflüsse laufen hinein und hinaus, was ist dokumentiert und was nur im Kopf einzelner Personen. Daraus entsteht eine Reihenfolge nach fachlichem Nutzen und Risiko, und jede Etappe liefert einen abnehmbaren Stand mit Rückweg. Was zu einem solchen Vorhaben gehört, steht auf der Seite Softwareentwicklung.