Legacy-Systeme schrittweise modernisieren

Ein Legacy-System ist selten nur alter Code. Meist ist es zugleich Datenbestand, Arbeitsanweisung, Schnittstellenarchiv und Gedächtnis eines Geschäftsprozesses. Manche Regeln stehen in keiner Spezifikation mehr. Sie sind über Jahre in Masken, Datenbankprozeduren oder nächtlichen Jobs gewachsen. Wer ein solches System ersetzt, greift deshalb in einen laufenden Betrieb ein, dessen tatsächliche Abhängigkeiten oft erst während der Analyse sichtbar werden.

Der vollständige Austausch zu einem festen Stichtag wirkt auf dem Papier eindeutig. In der Umsetzung bündelt er jedoch Entscheidungen, Migration und Betriebsrisiko in einem einzigen Moment. Eine schrittweise Modernisierung verfolgt ein anderes Ziel: Verantwortung wird so verlagert, dass jeder Übergang einzeln verstanden, geprüft und nötigenfalls zurückgenommen werden kann.

Das Altsystem beobachten, bevor es zerlegt wird

Bevor über Plattformen oder Programmiersprachen entschieden wird, braucht es ein verlässliches Bild des Ist-Zustands. Dokumentation ist dafür ein Ausgangspunkt, aber kein Beweis. Aufgerufene Schnittstellen, Zeitpläne, Datenbankzugriffe, Protokolle und manuelle Eingriffe zeigen, welche Pfade wirklich genutzt werden. Ebenso wichtig sind scheinbare Randfälle: verspätete Dateien, wiederholte Übertragungen, unvollständige Datensätze oder ein externer Dienst, der nur zu bestimmten Zeiten antwortet.

Diese Bestandsaufnahme ist keine Inventarliste für die Ablage. Sie soll zeigen, wo eine Änderung Wirkung entfaltet, wer sie bemerkt und welcher Prozess bei einem Fehler stehen bleibt. Erst daraus entsteht eine sinnvolle Reihenfolge.

Eine Grenze, ein Verantwortungswechsel

Modernisierung entsteht nicht dadurch, dass neben dem alten System ein neuer Dienst läuft. Der neue Teil muss eine eindeutig benannte Aufgabe übernehmen. Dazu gehört ein Vertrag mit den verbleibenden Komponenten: Datenformat, zulässige Zustände, Berechtigungen, Zeitverhalten, Fehlerbehandlung und Versionierung. Solange zwei Systeme dieselbe Entscheidung treffen dürfen, wurde Verantwortung verdoppelt statt übertragen.

Das Strangler-Fig-Muster beschreibt eine solche Ablösung über eine vorgeschaltete Fassade, die Anforderungen schrittweise zwischen altem und neuem Pfad verteilt. Microsoft weist dabei auf die Kosten der Übergangsarchitektur und auf mögliche Engpässe an der Fassade hin. Der Zwischenschritt senkt das Umstellungsrisiko, ist aber nicht kostenlos und sollte nach der Migration wieder verschwinden.

Parallelbetrieb mit Ablaufdatum

Für eine begrenzte Zeit können alter und neuer Pfad dasselbe Eingangsmaterial verarbeiten, ohne dass beide produktiv entscheiden. Ihre Ergebnisse lassen sich vergleichen; Abweichungen werden untersucht, bevor die Verantwortung wechselt. Ein solcher Parallelbetrieb braucht klare Kriterien und ein Enddatum. Ohne beides wird aus dem Übergang eine zweite dauerhafte Architektur mit zusätzlichen Datenflüssen und neuen Fehlerbildern.

Die Umschaltung selbst muss beobachtbar sein. Nicht nur technische Erreichbarkeit zählt. Kommen die erwarteten Vorgänge an? Bleiben Beziehungen erhalten? Entstehen Dubletten? Ändern sich Laufzeiten oder Summen? Erst wenn diese Fragen beantwortet sind, ist der neue Pfad mehr als eine plausible Implementierung.

Datenmigration muss wiederholbar sein

Eine Migration verlangt eine festgelegte Quelle, eine nachvollziehbare Transformation und überprüfbare Zielregeln. Für jeden Lauf muss erkennbar sein, welche Datensätze verarbeitet, verworfen oder korrigiert wurden. Fachliche Summen, Identitäten und Beziehungen sind vor und nach der Übertragung abzugleichen. Das gilt auch dann, wenn die neue Struktur sauberer wirkt: Eine stillschweigende Bereinigung kann ebenso folgenreich sein wie ein technischer Fehler.

Wenn ein Lauf nur mit spontanen Handkorrekturen gelingt, fehlt ein Teil des Nachweises. Erst ein reproduzierbarer Ablauf schafft eine Grundlage für die endgültige Umschaltung.

Abschalten gehört zum Projekt

Ein alter Pfad ist nicht verschwunden, nur weil ihn die Oberfläche nicht mehr anbietet. Aufrufe müssen beendet, Zugänge entzogen, Zeitpläne angepasst und Datenbestände entsprechend ihrer Vorgaben archiviert oder entfernt werden. Die Secure-by-Design-Leitlinie von CISA und internationalen Partnern erinnert zugleich daran, dass auch bestehende Produkte über mehrere Iterationen in einen sichereren Zustand gebracht werden können. Wichtige Schutzmaßnahmen müssen also nicht bis zum letzten Migrationstag warten.

Der Zielkonflikt bleibt: Übergangsarchitektur kauft Sicherheit bei der Umstellung, erhöht aber vorübergehend die Komplexität. Ein Modernisierungsschritt ist deshalb erst abgeschlossen, wenn keine produktive Verantwortung mehr im Altteil liegt und die dafür errichteten Hilfskonstruktionen bewusst zurückgebaut wurden.