In einer Bank ist eine Systemmigration kein technisches Ereignis, sondern ein Geschäftsrisiko. Hinter jeder Tabelle steht das Geld der Kunden, hinter jedem Service-Fenster die Aufsicht und Ihr Ruf. Deshalb gilt: Eine Migration von Banksystemen gelingt nicht, wenn das neue System läuft, sondern wenn der Kunde nie bemerkt hat, dass sich etwas geändert hat - Überweisungen gehen durch, Salden stimmen, und die mobile App antwortet genau wie gestern.
Nach unserer Erfahrung liegt die Schwierigkeit nicht in der Datenkonvertierung selbst, sondern darin, das Geschäft während des Umzugs am Laufen zu halten. Seit 2015 liefern wir Systemmigrationen für Geschäftskunden und Backend-Entwicklung im Bankwesen, unter anderem für eine Bank aus einer multinationalen Finanzgruppe, für die wir eine mobile App der neuen Generation gebaut haben. Dort haben wir gelernt, eine Migration vom Kunden und vom Rollback her zu planen und nicht von der neuen Architektur.
Warum ist eine Systemmigration in einer Bank so riskant?
Eine Bank unterscheidet sich von einem gewöhnlichen Unternehmen in drei Punkten zugleich: Kontinuität, Compliance und die Unumkehrbarkeit ihrer Operationen. Der Kern läuft rund um die Uhr, weil Kunden zu jeder Stunde Zugang zu ihrem Geld erwarten. Finanzdaten müssen auf den Cent stimmen, und die Aufsicht verlangt den Nachweis. Eine buchhalterische Operation lässt sich nicht „rückgängig machen” wie ein einfacher Datensatz - sie muss storniert werden, und das ist selbst ein Ereignis.
Dazu kommt eine Schicht, die leicht vergessen wird: Die Systeme einer Bank sind tief miteinander verflochten. Der Kern spricht mit dem Kartensystem, mit Anti-Fraud, dem Meldewesen, dem Mobile-Banking und Dutzenden über die Jahre angesammelten Integrationen, sodass die Migration eines Elements Fragen zu allen anderen aufwirft. Wir behandeln das als Operation am lebenden Körper.
Wie planen wir eine Bankmigration ohne Ausfallzeit?
Wir beginnen mit einer Bestandsaufnahme, nicht mit Code. Bevor jemand die Daten anfasst, kartieren wir, was mit was spricht, welche Abläufe für den Kunden kritisch sind und wo die Daten liegen, die nicht verloren gehen oder sich verdoppeln dürfen. Diese Karte sagt uns, was im Hintergrund umziehen kann und was ein enges Fenster braucht.
In der Planung halten wir uns an einige Grundsätze, die uns mehr als einmal vor einem Rollback um 3 Uhr morgens bewahrt haben:
- wir entwerfen die Migration in Etappen, statt alles in einem Zug zu verschieben,
- wir setzen harte Erfolgs- und Abbruchkriterien vor dem Start, nicht mitten im Lauf,
- wir proben das Ganze auf einer Kopie der Produktion, nicht nur auf Testdaten,
- wir planen das Rollback als vollwertiges Szenario, nicht als Notiz auf einem Zettel.
Welche Migrationsstrategien nutzen wir: schrittweise, parallel, Rollback?
Es gibt selten eine einzige richtige Strategie - wir passen sie daran an, wie kritisch ein System ist und wie schmerzhaft sein Ausfall wäre. Meist verbinden wir drei Ansätze innerhalb eines Programms.
Eine schrittweise Migration verschiebt Funktionen oder Kundengruppen in Chargen: Neues und altes System laufen nebeneinander, und wir verlagern den Verkehr allmählich, was die Wirkung eines Fehlers auf eine Etappe begrenzt statt auf die ganze Bank.
Ein Parallelbetrieb lässt beide Systeme eine Zeit lang dieselben Operationen verarbeiten, damit wir die Ergebnisse vergleichen können. Solange sie nicht auf den Cent übereinstimmen, bleibt das alte System die Quelle der Wahrheit - unser liebster Weg, vor einem Umschalten Vertrauen aufzubauen.
Ein Rollback entwerfen wir jedes Mal. Ein Umschalten ohne geprobten Rückweg ist eine Wette und kein Plan, deshalb hat jedes Migrationsfenster einen definierten Punkt ohne Wiederkehr und davor eine klare Abbruchprozedur.
Wie sichern wir die Datenintegrität bei der Datenmigration einer Bank?
Hier gibt es keinen Raum für „nah genug”. Die Datenmigration einer Bank muss zahlenmäßig abstimmbar sein - Prüfsummen, Datensatzzahlen und Salden auf beiden Seiten müssen übereinstimmen, bevor jemand den Erfolg erklärt. Deshalb bauen wir einen Prozess, in dem jede Charge automatisch geprüft wird und Abweichungen sofort auffallen und nicht erst nach einer Kundenbeschwerde.
In der Praxis halten wir mehrere Kontrollschichten vor:
- Datenprofilierung und -bereinigung vor der Migration, damit wir keinen Ballast mitnehmen,
- Feld-Mapping und Transformationsregeln, dokumentiert und versioniert statt in Köpfen gespeichert,
- Abstimmung nach jeder Charge - Vergleich von Summen, Anzahlen und Schlüsselsalden,
- einen Audit-Trail, der zeigt, woher jeder Datensatz im Zielsystem stammt.
Wie testen und validieren wir die Migration, bevor der Kunde sie sieht?
Wir testen eine Migration so, wie sie später laufen wird - auf Daten und Volumina nahe der Produktion. Ein einzelner Probelauf beweist nichts, deshalb wiederholen wir Migrationsläufe vielfach, bis der Lauf auf die Minute und auf das Ergebnis genau vorhersehbar ist, und jeder Probelauf dient zugleich als Test der Abbruchprozedur.
Über die Korrektheit der Daten hinaus prüfen wir Performance und das Verhalten der Integrationen unter Last. Es reicht nicht, dass die Daten umziehen - sie müssen in einem Fenster umziehen, das zwischen die letzte und die erste Operation des Kunden passt. Deshalb optimieren wir die Laufzeit, bis dieses Fenster minimal ist, idealerweise unsichtbar.
Wie halten wir Sicherheit und Compliance bei der Legacy-Modernisierung ein?
Legacy-Modernisierung im Bankwesen geschieht unter den Augen der Aufsicht und der Risikoteams, deshalb weben wir Compliance von Anfang an in das Projekt ein, statt sie am Ende anzuschrauben. Wir schützen sensible Daten in jedem Schritt, beschränken Zugriffe auf das strikt Nötige und dokumentieren den Prozess so, dass er sich reproduzieren und vor einer Prüfung begründen lässt; in Nicht-Produktionsumgebungen arbeiten wir mit geschützten Daten und nicht mit echten Kundennummern.
Ebenso wichtig ist, was danach geschieht: Vom ersten Tag an muss das neue System das Meldewesen und die Kontrollmechanismen genauso speisen wie das alte, sodass Compliance eine funktionale Anforderung der Migration ist und kein eigenes Projekt im Nachhinein.
Welche Kompetenzen stellen wir für ein Migrationsprojekt in einer Bank bereit?
Wir stellen das Team rund um die konkrete Phase und das konkrete System zusammen, nicht „auf Vorrat”. In Migrations- und Backend-Projekten im Bankwesen besetzen wir üblicherweise Rollen wie:
- Daten- und Migrations-Engineers, die Konvertierung und Abstimmung verantworten,
- Backend-Entwickler, die Systeme auf der Seite der Bank bauen und integrieren,
- Architekten, die alte und neue Welt zu einem funktionierenden Ablauf verbinden,
- QA- und Testautomatisierungsspezialisten, die dafür sorgen, dass das Ergebnis stimmt.
Ein solches Team kann die Migration vollständig übernehmen oder Ihre eigenen Teams dort verstärken, wo Hände oder konkretes Wissen fehlen; welches Modell zu wählen ist, behandeln wir in unserem Artikel zu IT-Kooperationsmodellen.
Wie machen wir das bei RITS?
Wir tun es als Nearshore-Partner aus Polen mit echter Bankerfahrung, die bis 2015 zurückreicht - wir verschieben Systeme und Daten so, dass der Kunde der Bank es nicht spürt und das Team der Bank die Kontrolle über den Prozess behält.
Unser deutlichster Beleg ist die Arbeit mit einer Bank aus einer multinationalen Finanzgruppe, für die wir auch eine mobile App der neuen Generation gebaut haben. Dort liefern wir Systemmigration für Geschäftskunden und Backend-Entwicklung, und diese Erfahrung fließt in jedes folgende Projekt. Meist arbeiten wir als Individualsoftware, gebaut von unserem Team, und dort, wo Kompetenzen schnell aufzustocken sind, als Team-Verstärkung der Mannschaft des Kunden.
Wo beginnen Sie mit der Migration der Systeme einer Bank?
Beginnen Sie mit einer Frage: Welcher Kundenablauf darf nicht einmal eine Minute ausfallen? Er bestimmt die Strategie, die Länge des Fensters und die Gestalt des Rollbacks. Nehmen Sie danach Daten und Integrationen auf, denn sie entscheiden meist über das wirkliche Risiko und nicht das neue System selbst.
Sie planen eine Migration oder Modernisierung der Systeme Ihrer Bank? Sprechen wir darüber - wir planen den Umzug und stellen ein Team zusammen, sodass der Kunde nichts bemerkt.