Datenmigration bei der Ablösung eines Kernsystems: Datenhoheit, Parallelbetrieb und Umschaltung
Code lässt sich schrittweise ablösen, Daten nicht beliebig. Wie Sie die Datenhoheit je Phase festlegen, Synchronisation und Abgleich planen, den Parallelbetrieb budgetieren und die Umschaltung absichern. Für CTOs und IT-Leitungen mit gewachsenen Kernsystemen.
Das Strangler-Fig-Pattern verspricht, ein Altsystem Funktion für Funktion abzulösen. Für den Code stimmt das. Für die Daten stimmt es nur mit Einschränkungen. Ein Kernsystem mit fünfzehn Jahren Betrieb hat meist eine Datenbank, in der Verträge, Kunden, Buchungen und Dokumente über Fremdschlüssel, Trigger und gespeicherte Prozeduren zusammenhängen. Wer eine Funktion herauslöst, muss entscheiden, wem ihre Daten in der Übergangszeit gehören. Diese Entscheidung bestimmt Aufwand, Risiko und Dauer des gesamten Vorhabens.
In meinen Projekten war die Datenseite fast immer der Teil, der am längsten dauerte und am wenigsten geplant war. Der Artikel zum Strangler-Fig-Pattern beschreibt die Gesamtstrategie. Hier geht es um den Teil, der dort als Phase 5 nur angerissen wird.
Warum die Daten die Reihenfolge bestimmen
Ein Altsystem kennt meist eine Datenbank für alles. Das neue Zielbild besteht aus abgegrenzten Fachbereichen mit eigenen Datenbeständen. Zwischen beiden liegt eine Phase, in der dieselben Daten von zwei Systemen gebraucht werden.
Die wichtigste Regel für diese Phase lautet: Für jeden Datenbestand gibt es zu jedem Zeitpunkt genau ein System, das schreiben darf. Alle anderen lesen. Sobald zwei Systeme denselben Bestand ändern, entstehen Konflikte, die sich nachträglich kaum auflösen lassen. Diese Regel klingt banal. In der Praxis wird sie bei jedem Zeitdruck verletzt, weil ein schnelles Schreiben ins alte System den Freigabetermin rettet.
Daraus folgt die Reihenfolge der Ablösung. Zuerst kommen Funktionen, deren Daten wenige Abhängigkeiten in andere Bereiche haben und bei denen sich ein eindeutiger Schreiber festlegen lässt. Eine Dokumentenablage oder ein Reporting eignet sich als Pilot. Die Vertragsverwaltung mit Verknüpfungen in Buchung, Mahnwesen und Meldewesen kommt zuletzt.
Vier Muster für die Übergangszeit
Für die Zeit, in der Alt und Neu nebeneinander laufen, haben sich vier Muster bewährt. Jedes passt zu einer anderen Situation.
| Muster | Funktionsweise | Passt, wenn | Wichtigstes Risiko |
|---|---|---|---|
| Alt schreibt, Neu liest | Das neue System liest über Schnittstelle, Replikat oder Change Data Capture aus dem Altsystem | Die neue Funktion liest nur oder schreibt eigene, neue Daten | Das Lesemodell veraltet, wenn die Replikation hinterherhinkt |
| Neu schreibt, Alt liest zurück | Die Funktion ist vollständig umgezogen, das Altsystem erhält die Daten per Rücksynchronisation für Berichte und Restfunktionen | Alte Berichte, Batchläufe oder Nachbarmodule brauchen die Daten weiter | Die Rücksynchronisation wird dauerhaft, weil niemand die Restfunktionen abschaltet |
| Harter Schnitt je Datenobjekt | Ein abgegrenzter Bestand wird in einem Zeitfenster vollständig umgezogen, danach schreibt nur Neu | Der Bestand ist klar abgrenzbar und eine kurze Sperrzeit ist vertretbar | Vergessene Abhängigkeiten zeigen sich erst nach dem Schnitt |
| Doppeltes Schreiben aus der Anwendung | Die Anwendung schreibt jede Änderung in beide Systeme | Nur als kurze Brücke mit täglichem Abgleich | Beide Bestände laufen auseinander, sobald ein Schreibvorgang fehlschlägt |
Das vierte Muster steht in der Tabelle, damit es erkannt wird. Aus meiner Sicht ist es nur mit täglichem Abgleich und festem Enddatum vertretbar. Für die Synchronisation zwischen den Beständen ist Change Data Capture der übliche Weg. Dabei werden Änderungen aus dem Transaktionsprotokoll der Datenbank gelesen und als Ereignisse an das andere System übertragen. Im Projektbericht zur Finanzplattform lief die Entkopplung eines Kreditentscheidungsdienstes genau so. Ein Werkzeug für Change Data Capture hielt beide Bestände synchron, bis die Umschaltung abgeschlossen war und die Synchronisation abgeschaltet wurde.
Abgleich ist das Abnahmekriterium
Ob eine Migration gelungen ist, zeigt der Abgleich. Er vergleicht beide Bestände nach festen Regeln, automatisiert und wiederholbar. Drei Ebenen reichen dafür aus.
- Mengen und Summen. Anzahl der Datensätze je Objekt, Summen je Konto oder Vertrag, Prüfsummen über Schlüsselfelder. Das ist die schnelle tägliche Kontrolle.
- Fachliche Invarianten. Jeder Vertrag hat einen Kunden. Jede Buchung hat ein Gegenkonto. Der Saldo aus den Einzelposten entspricht dem gespeicherten Saldo. Diese Regeln kennt der Fachbereich, nicht die IT.
- Stichproben durch den Fachbereich. Ein Sachbearbeiter öffnet denselben Vorgang in beiden Systemen und vergleicht Bildschirm gegen Bildschirm. Das deckt Fehler in Formaten, Rundungen und Anzeigelogik auf, die kein Skript findet.
Legen Sie vor dem Pilot fest, welche Abweichung tolerierbar ist und wer die Abnahme unterschreibt. Ein Abgleich, der erst nach der Umschaltung entworfen wird, kommt zu spät. Er gehört in dieselbe Iteration wie die Migrationsstrecke selbst.
Der Abgleich zeigt auch, wie gut die Daten sind. Dubletten, verwaiste Verweise und Felder mit abweichender Bedeutung tauchen dort zuerst auf. Bereinigen Sie im Altsystem vor der Übernahme. Was erst im Zielsystem korrigiert wird, läuft bei der nächsten Synchronisation wieder auseinander.
Historische Daten und Nachweispflichten
Bei Finanzunternehmen bestimmen auch die Aufbewahrungspflichten, welche Daten mitkommen. Handels-, steuer- und aufsichtsrechtliche Vorgaben verlangen, dass Vorgänge über Jahre nachvollziehbar bleiben. Dafür gibt es drei Wege.
- Alles migrieren. Sauber, aber teuer, weil jede historische Variante des Datenmodells abgebildet werden muss.
- Aktive Bestände migrieren und die Historie in ein Archiv mit Lesezugriff überführen. Das Archiv braucht eine Suche, einen Export für Prüfer und ein Löschkonzept.
- Das Altsystem für die Dauer der Aufbewahrung nur lesend weiterbetreiben. Das ist der häufigste Weg und der am häufigsten unterschätzte. Lizenzen, Betrieb, Sicherheitsupdates und Wissen müssen über Jahre vorgehalten werden.
Unabhängig vom Weg muss die Änderungshistorie überleben. Wer wann was geändert hat, darf durch die Migration nicht verloren gehen. Dokumentieren Sie die Zuordnung alter zu neuen Feldern so, dass ein Prüfer sie am Ende der Aufbewahrungsfrist noch nachvollziehen kann. Löschkonzepte nach Datenschutzrecht gehören in dieselbe Planung. Eine Migration ist der beste Zeitpunkt, Daten ohne Rechtsgrundlage gar nicht erst mitzunehmen.
Parallelbetrieb kostet Geld und Aufmerksamkeit
Solange beide Systeme laufen, zahlen Sie doppelt: Lizenzen, Infrastruktur, Betrieb, Bereitschaft und Sicherheitsupdates. Dazu kommt ein Posten, der in keiner Rechnung steht. Jede fachliche Änderung, die gemeinsam genutzte Daten berührt, muss in dieser Zeit in beiden Systemen umgesetzt werden, sonst bricht die Synchronisation. Ein Parallelbetrieb von zwölf Monaten mit laufenden Produktänderungen kann deshalb mehr Entwicklungskapazität binden als die Migration selbst.
In der Business-Case-Tabelle steht der Parallelbetrieb als eigene Zeile. Setzen Sie dort eine Laufzeit in Monaten ein, die Sie begründen können. Legen Sie im Projektplan ein Enddatum fest, an dem das alte System für diesen Bereich abgeschaltet wird. Ein Parallelbetrieb ohne Enddatum wird zum Dauerzustand. Wie die Kosten insgesamt zusammenkommen, beschreibt der Artikel zu den Kosten einer Legacy-Modernisierung.
Die Umschaltung wird geprobt
Die Umschaltung eines Datenbestands ist der Moment mit dem höchsten Risiko und dem kleinsten Zeitfenster. Sie folgt einem festen Ablauf: Sicherung beider Bestände, Schreibsperre im Altsystem, letzte Übernahme der Änderungen, Abgleich, Freigabeentscheidung, Umschaltung der Anwendungen, Beobachtung. Für jeden Schritt gibt es ein messbares Kriterium und eine verantwortliche Person.
Der Rückweg hängt davon ab, ob im neuen System schon geschrieben wurde. Solange das nicht der Fall ist, ist der Rückweg ein Umschalten der Verbindung. Sobald neue Daten entstanden sind, ist der Rückweg selbst eine Migration. Legen Sie deshalb fest, wie lange nach der Umschaltung eine Rückkehr noch möglich ist und welche Daten dabei verloren gehen dürfen. Wer den Rückweg länger offen halten will, lässt nach der Umschaltung die Rücksynchronisation aus dem zweiten Muster für eine festgelegte Frist weiterlaufen.
Proben Sie den Ablauf mindestens zweimal mit Datenmengen in Produktionsgröße. Die Generalprobe liefert die tatsächliche Dauer der Übernahme, die Last auf den Datenbanken und die Fehler in den Skripten, die bei Testdaten nicht auffallen. Ein Zeitfenster, das auf einer Schätzung beruht, hält selten. Die Generalprobe braucht eine Kopie der Produktionsdaten in einer abgeschotteten Umgebung mit denselben Zugriffsregeln wie die Produktion. Klären Sie das vorher mit dem Datenschutzbeauftragten.
Was ein Pilot beantworten sollte
Ein Datenpilot nimmt einen abgegrenzten Bestand, migriert ihn, betreibt ihn einige Wochen parallel und gleicht täglich ab. Er beantwortet vier Fragen. Wie lange dauert die Übernahme je Million Datensätze? Wie groß ist der Rückstand der Synchronisation unter Last? Welche Abweichungen findet der Abgleich, und woher kommen sie? Wie viel Zeit des Fachbereichs bindet die Abnahme?
Mit diesen Antworten lässt sich der Aufwand für die übrigen Bestände schätzen. Ohne sie bleibt jede Zahl im Business Case eine Vermutung. Wie ein solcher Pilot in die Investitionsentscheidung eingebunden wird, steht in der Leistungsbeschreibung zur Legacy-Modernisierung.
Nächster Schritt
Wenn noch unklar ist, welche Daten welche Funktion tragen und wo die Abhängigkeiten liegen, hilft zuerst eine Abhängigkeitskarte des Systems. Für die Planung von Reihenfolge und Pilot ist ein Architektur-Review der passende Rahmen. Den Aufbau einer Datenplattform aus mehreren Quellsystemen mit Abgleich und Umschaltung beschreibt die Fallstudie zum Data Hub eines Leasing-Unternehmens.