Legacy-Modernisierung schließt die Stilllegung alter Pfade ein

Auch nach dem Start eines Nachfolgesystems können produktive Abhängigkeiten vom Legacy-System bestehen. Beispielsweise nutzt die Oberfläche bereits den neuen Dienst, während ein nächtlicher Job weiterhin eine Datei für den Bestand erzeugt. Ein anderer Aufrufer kennt nur die alte Schnittstelle; eine manuelle Korrektur greift direkt auf die bisherige Datenbank zu. Solange ein Geschäftsprozess auf sie angewiesen ist, bleibt die Verantwortung zwischen Alt und Neu geteilt.

Übergangsarchitektur und Bestandsaufnahme

Das Azure Architecture Center beschreibt Strangler Fig als schrittweise Verlagerung einzelner Funktionen. Eine Fassade nimmt Aufrufe entgegen und leitet sie je nach Migrationsstand an das alte oder neue System weiter. Dieses Vorgehen begrenzt die Größe einzelner Umstellungen.

Es vergrößert jedoch vorübergehend die Architektur und macht die Fassade selbst zu einem möglichen Engpass oder Ausfallpunkt. Welche Funktion sich als Nächstes ablösen lässt, ergibt sich deshalb nicht allein aus einer Dokumentation. Aufgerufene Schnittstellen, Datenbankzugriffe, Dateiübertragungen, Zeitpläne und Betriebsprotokolle zeigen, was tatsächlich noch verwendet wird. Auch eine regelmäßig ausgeführte Handkorrektur gehört zum produktiven Ablauf, wenn der Vorgang ohne sie nicht zuverlässig endet. Zu jedem aktiven Pfad gehört die fachliche Frage: Welcher Vorgang wartet darauf, wer erkennt eine Abweichung, und welcher Datenstand gilt anschließend?

Der Zuschnitt eines Modernisierungsschritts folgt einer benannten fachlichen Verantwortung. Für ihre Übergabe müssen Zustände, Berechtigungen, Datenformat, Versionierung und Fehlerverhalten feststehen. Können beide Systeme denselben Vorgang verbindlich verändern, wurde die Verantwortung zunächst verdoppelt. Das kann für einen begrenzten Übergang nötig sein, braucht aber einen eindeutigen führenden Pfad und ein Kriterium für sein Ende.

Rolle der Fassade

Der Beitrag „Transitional Architecture“ von Ian Cartwright, Rob Horn und James Lewis auf martinfowler.com beschreibt solche Hilfskonstruktionen: Sie unterstützen einen bestimmten Übergang und sollen entfernt werden, sobald ihre Aufgabe erfüllt ist.

Microsoft nennt allerdings eine begründete Ausnahme. Die Fassade kann als Adapter für Legacy-Clients weiterbestehen, wenn diese nicht gleichzeitig migriert werden können. Dann ist sie keine vergessene Übergangsschicht, sondern ein bewusst betriebener Teil der Zielarchitektur mit eigener Verantwortung. Ein lokales Abbaukriterium benennt mehr als einen Termin: Welche Aufrufer müssen migriert sein, welcher Datenbestand führt, welche Antwort- und Fehlerwege deckt das Ziel ab, und wie wird die Nichterreichbarkeit des alten Pfads geprüft? Bis dahin bleibt die Abhängigkeit im Architektur- und Betriebsinventar sichtbar. Ein verschobener Termin ändert ihre technische Wirkung nicht.

Parallelbetrieb und Datenmigration

Im Parallelbetrieb können Alt- und Neupfad vorübergehend dasselbe Eingangsmaterial erhalten, während nur einer das verbindliche Ergebnis liefert. Der Vergleich darf sich nicht auf Statuscodes oder Laufzeiten beschränken. Fachliche Summen, Beziehungen, Vollständigkeit, Reihenfolge und Dubletten können trotz technisch erfolgreicher Verarbeitung voneinander abweichen. Welche Unterschiede zulässig sind und welcher Befund zum Abbruch führt, wird vor dem Versuch festgelegt. Für Datenmigrationen gilt derselbe Anspruch. Quelle, Transformation und Zielregeln müssen wiederholbar beschrieben sein; verarbeitete wie zurückgewiesene Datensätze bleiben nachvollziehbar. Gleiche Zeilenzahlen beweisen bei verknüpften Daten wenig. Ein Auftrag kann vorhanden sein, obwohl Positionen, Belege oder Berechtigungszuordnungen fehlen. Spontane Korrekturen gehören deshalb in die nächste reproduzierbare Migrationsregel und nicht in eine private Nebenliste.

Sicherheitsverbesserungen müssen nicht bis zur Ablösung des gesamten Monolithen warten. Die Secure-by-Design-Leitlinie der CISA beschreibt die schrittweise Verbesserung bestehender Produkte. Für den jeweils übernommenen Verantwortungsbereich lassen sich also bereits eigene Zugänge, Protokollierung und sichere Standardwerte durchsetzen. Eine solche Verbesserung belegt allerdings noch nicht, dass der alte Zugangsweg verschwunden ist.

Die aktuelle Microsoft-Dokumentation beschreibt für die Datenübernahme ein domänenweises Vorgehen: Historische Daten werden zunächst übertragen, laufende Änderungen anschließend etwa per Change Data Capture nachgeführt. Vor der Umschaltung wird die Konsistenz geprüft; erst danach übernimmt das Ziel die führende Datenhaltung für die betreffende Domäne. Das ist eine mögliche Umsetzung des Musters. Ob sie passt, hängt unter anderem davon ab, ob sich Änderungen im Bestand zuverlässig erfassen und die Aufrufe gezielt umlenken lassen. Der Rückweg verändert sich während dieses Übergangs. Solange Altbestand und Synchronisation erhalten sind, bestehen andere Rückfallmöglichkeiten als nach dem Entfernen alter Tabellen, Prozeduren und Datenabgleiche.

Microsoft weist darauf hin, dass eine spätere Rückkehr die Wiederherstellung dieser Objekte und das Nachspielen zwischenzeitlicher Änderungen erfordern kann. Aus dieser Einschränkung folgt für die Planung: Rückfallentscheidung und endgültiger Datenrückbau sollten getrennte Freigabepunkte erhalten. Die Umschaltung eines Aufrufpfads belegt noch keine verlustfreie Rückkehr der Daten.

Nach der Umschaltung

Nach der Umschaltung beginnt die eigentliche Stilllegung. Aufrufer werden entfernt, Zeitpläne beendet, technische Konten und Firewallregeln entzogen. Daten sind nach den geltenden Vorgaben zu archivieren oder zu löschen. Auch Monitoring, Sicherungen und Betriebsanweisungen, die nur für die alte Verbindung existieren, brauchen eine Entscheidung. Andernfalls bleibt nicht nur Code zurück, sondern ein weiterhin betreuter oder unbemerkt erreichbarer Produktionspfad.

Abgeschlossen ist die Ablösung des Legacy-Systems, wenn der neue Teil die benannte Verantwortung trägt, Daten- und Fehlerwege geprüft sind und kein produktiver Aufruf mehr auf den Bestand zeigt. Die Fassade entfällt dann ebenfalls, sofern sie nicht als begründeter Adapter für verbliebene Legacy-Clients eine eigene Zielrolle behält. Eine abgeschaltete Oberfläche, hinter der Konten, Jobs oder Schnittstellen weiterwirken, erfüllt den Stilllegungsnachweis nicht.

Hinweis: Diese Einordnung ersetzt keine Prüfung des Einzelfalls.