Wenn das Altsystem selbst Fehler enthält
In seinem Beitrag auf CIO.com beschreibt IT-Architekt Krishna C. Mukherjee den sogenannten Shadow Mode: Das neue System verarbeitet Geschäftsvorfälle parallel zur bisherigen Plattform, ohne selbst produktive Zahlungen auszulösen oder Kundenbenachrichtigungen zu versenden. Die Ergebnisse beider Systeme werden anschließend auf Transaktionsebene verglichen.
Dabei könnten auch bislang unentdeckte Fehler des Altsystems sichtbar werden, etwa bei Rundungen, der Verarbeitung von Sonderfällen oder Zeitzonenwechseln. Mukherjee empfiehlt deshalb, Abweichungen nach ihrer Ursache zu unterscheiden: Handelt es sich um einen Fehler der neuen Anwendung, einen bislang undokumentierten Legacy-Fehler oder eine bewusst geänderte Verarbeitungsregel?
Dass gewachsene Bankensysteme Datenprobleme über längere Zeit mitführen können, zeigen auch aktuelle Feststellungen der britischen Bankenaufsicht Prudential Regulation Authority (PRA). Wie wir bereits berichtet haben, würden Datenfehler bei einigen Instituten erst in nachgelagerten Verarbeitungsschritten erkannt und manuell korrigiert. Die PRA bezieht sich dabei auf Daten zur Berechnung erwarteter Kreditverluste nach IFRS 9, nicht unmittelbar auf Systemmigrationen.
Vor der Abschaltung eines Altsystems müssten nach Mukherjees Darstellung neben den Transaktionsergebnissen auch Kontostände, Datensatzanzahlen, Datenbeziehungen und die Verfügbarkeit historischer Prüfunterlagen überprüft werden.
ConnectPay: Täglicher Abgleich über mehrere Monate
Wie aufwendig eine solche Absicherung ausfallen kann, zeigt eine Fallstudie des Technologieanbieters SERDIS über den litauischen Zahlungsdienstleister ConnectPay. Das Unternehmen migrierte seine bisher extern betriebene Kernbankplattform auf eine selbst kontrollierte Infrastruktur.
Nach Angaben des Anbieters wurden Alt- und Neusystem zunächst parallel mit identischen Produktkonfigurationen und Ereignisdaten betrieben. In einer anschließenden mehrmonatigen Phase seien täglich sämtliche Kontostände und Transaktionen abgeglichen worden. Dabei festgestellte Abweichungen habe man durch Anpassungen der Zuordnungslogik behoben.
Erst nach vollständiger Abstimmung der Kontostände erfolgte die endgültige Umstellung an einem Wochenende. Laut Anbieter kam es dabei zu keinen für Kunden sichtbaren Ausfällen.
Commonwealth Bank: Fünf Generalproben statt drei
Einen anderen Ansatz zur Absicherung einer Migration beschreibt die australische Commonwealth Bank. Sie verlagerte 2025 ihre SAP-basierte Kernbankplattform in die Cloud. Das System unterstützt rund 16 Millionen Kundenkonten und verarbeitet nach Bankangaben 40 Prozent des australischen Zahlungsverkehrs.
Wie die Bank in einem Erfahrungsbericht vom März 2026 erläutert, waren 54 Teams an den Tests beteiligt. Wiederkehrende Probleme mit der Stabilität der Testumgebungen führten zu zusätzlichem Aufwand. Statt der ursprünglich geplanten drei vollständigen Umstellungsproben absolvierte die Bank schließlich fünf.
Beim eigentlichen Wechsel war das Kernsystem drei Stunden vollständig abgeschaltet. Eine zusätzliche Verfügbarkeitsschicht habe dafür gesorgt, dass Kunden weiterhin Bankdienstleistungen nutzen konnten. Anders als bei ConnectPay dokumentiert die Bank damit keinen mehrmonatigen Parallelbetrieb, sondern die intensive Vorbereitung und technische Absicherung des Umstellungstermins.
Die Beispiele verdeutlichen unterschiedliche Möglichkeiten, Migrationsrisiken zu begrenzen. Der von Mukherjee beschriebene Parallelbetrieb wirft darüber hinaus eine grundlegende Frage auf: Wie verlässlich ist das Altsystem als Referenz, wenn sich bei der Verarbeitung von Geschäftsvorfällen Unterschiede zeigen? Vor seiner endgültigen Abschaltung müssen deshalb nicht nur technische Fehler behoben, sondern auch fachliche Abweichungen geklärt werden. (td)
