Core‑Banking‑Migration: vom Datenprofil bis zum sicheren Cutover

Eine Core-Banking-Migration ist der Wechsel einer Bank von ihrem bestehenden Kernbankensystem auf eine neue Plattform, inklusive aller Kundendaten, Konten, Positionen, Historien und Schnittstellen. Ob das Projekt gelingt, entscheidet sich selten an der Wahl der Software. Es entscheidet sich an drei Dingen: an sauber validierten Daten, an einem mehrfach geprobten Cutover und an einem Rollback, der im Ernstfall tatsächlich funktioniert. In diesem Leitfaden gehen wir mit Ihnen Schritt für Schritt durch die Migration, mit dem Blick auf Schweizer Banken, Privatbanken und Vermögensverwalter.

TL;DR

• Eine Core-Banking-Migration ist vor allem ein Daten- und Betriebsprojekt: Entscheidend ist, ob die Bank am ersten Geschäftstag nach dem Umstieg normal arbeiten kann, nicht nur, ob die Konvertierung durchgelaufen ist.
• Planen Sie Datenmigration als wiederholbare Abfolge aus Profiling, Mapping, Transformation, Validierung und Reconciliation, und testen Sie mit vollständigen oder repräsentativ vollständigen Datenmengen.
• Der Cutover braucht ein detailliertes Runbook, ein Freeze-Window, eine klar benannte Go/No-Go-Instanz und einen Rollback-Punkt, der operativ wiederherstellbar ist.
• Big Bang, gestaffelte Migration und Parallelbetrieb haben jeweils eigene Risiken. Die richtige Wahl hängt von Produktbreite, Umsystemen und Risikobereitschaft ab.
• KI-gestützte Engineering-Methoden beschleunigen Mapping, Testfall-Erstellung und Abgleiche, ersetzen aber keine fachliche Abnahme.

Inhaltsverzeichnis

• Inhalt
• Was eine Core-Banking-Migration umfasst
• Migrationsstrategien im Vergleich
• Datenmigration in sechs Schritten
• Der Cutover: Runbook, Freeze, Go/No-Go und Rollback
• Was am ersten Geschäftstag sichtbar wird
• Besonderheiten für Banken in der Schweiz
• Wo KI die Migration heute beschleunigt
• Unsere Perspektive
• Wie S-PRO Ihre Migration unterstützt
• FAQ
• Quellen

Inhalt

1. Was eine Core-Banking-Migration umfasst
2. Migrationsstrategien im Vergleich
3. Datenmigration in sechs Schritten
4. Der Cutover: Runbook, Freeze, Go/No-Go und Rollback
5. Was am ersten Geschäftstag sichtbar wird
6. Besonderheiten für Banken in der Schweiz
7. Wo KI die Migration heute beschleunigt
8. Unsere Perspektive
9. FAQ

Was eine Core-Banking-Migration umfasst

Das Kernbankensystem ist das Hauptbuch der Bank: Es führt Konten, Salden, Zinsen, Gebühren, Kredite, Wertschriftenpositionen und die Buchungshistorie. Rund um diesen Kern hängen Dutzende Umsysteme, vom E-Banking über den Zahlungsverkehr und das Kartengeschäft bis zu Meldewesen, Compliance-Tools und Data Warehouse.

Eine Migration betrifft deshalb immer mehrere Ebenen gleichzeitig:

• Daten: Stammdaten, Verträge, offene Positionen, Salden und Historien müssen vollständig und fachlich korrekt in das Zielsystem gelangen.
• Prozesse: Tagesend- und Tagesbeginnverarbeitung, Zinsläufe, Gebührenberechnung und Abschlüsse laufen auf der neuen Plattform anders.
• Schnittstellen: Jedes Umsystem muss neu angebunden, getestet und abgenommen werden. Wie Sie diese Integration regulatorisch sauber aufsetzen, beschreiben wir ausführlich in unserem Beitrag zur Kernbankensystem-Integration und ihren Compliance-Anforderungen.
• Organisation: Mitarbeitende im Frontoffice, Backoffice und Betrieb arbeiten ab dem Stichtag mit neuen Masken, Abläufen und Kontrollen.

Ein Fachbeitrag zu Datenmigrationen in Implementierungsprojekten von Standard-Bankensoftware von Klaus Haller beschreibt drei Hauptdimensionen der Datenmigration, die zusammen den Projektumfang bestimmen. Die Botschaft dahinter ist praxisnah: Wer Migration als technischen Nebenschritt der Einführung behandelt, unterschätzt Aufwand und Risiko systematisch.

Migrationsstrategien im Vergleich

Bevor die erste Zeile Code geschrieben wird, steht die Grundsatzentscheidung: Wie kommt die Bank vom alten auf das neue System? Vier Muster haben sich etabliert.

In der Praxis kombinieren viele Institute die Muster: Eine neue digitale Linie startet auf der Zielplattform, der Bestand folgt gestaffelt, einzelne Berechnungen laufen eine Zeit lang parallel. Wenn Sie gerade erst eine neue Banklinie aufbauen, lohnt sich der Blick auf unseren Beitrag zum Aufbau eines Banking-MVP: Ein schlanker Start auf moderner Infrastruktur kann die spätere Bestandsmigration deutlich entlasten.

Drei Fragen helfen bei der Entscheidung:

1. Wie viele Umsysteme müssten bei einer gestaffelten Migration temporär mit beiden Kernen sprechen? Jede Brückenschnittstelle ist zusätzlicher Code, der getestet und später wieder abgebaut werden muss.
2. Wie gut lassen sich Kundensegmente sauber trennen? Kunden mit Konten, Hypotheken und Depots in verschiedenen Wellen erzeugen schnell Inkonsistenzen.
3. Wie lange darf der Stichtag dauern? Ein Big Bang verlangt ein Wochenende oder ein verlängertes Freeze-Window, in dem alle Migrationsläufe, Abgleiche und Freigaben Platz haben.

Datenmigration in sechs Schritten

Die Datenmigration ist das Herzstück jeder Core-Banking-Migration. Wir empfehlen, sie von Beginn an als wiederholbaren Prozess zu bauen, nicht als einmaligen Export und Import.

1. Data Profiling: Bevor Sie mappen, analysieren Sie die Quelldaten: Feldbelegungen, Dubletten, Lücken, Sonderfälle aus jahrzehntealten Produkten, manuell gepflegte Felder. Hier zeigt sich, wie viel Bereinigung nötig ist.
2. Fachliches Mapping: Jedes Quellfeld und jeder Produkttyp wird einem Zielobjekt zugeordnet, inklusive Transformationsregeln. Das Mapping gehört in die Verantwortung der Fachbereiche, nicht allein der IT.
3. Extraktion und Staging: Die Daten landen in einer Staging-Umgebung, in der Transformationen nachvollziehbar und versioniert laufen.
4. Transformation und Laden: Die Regeln werden angewendet, die Daten in das Zielsystem geladen. Achten Sie auf Ladereihenfolgen, etwa Kunden vor Verträgen, Verträge vor Buchungen.
5. Validierung im Zielsystem: Technische Prüfungen (Pflichtfelder, Referenzen, Formate) und fachliche Prüfungen (stimmen Zinssätze, Laufzeiten, Gebührenmodelle?) laufen automatisiert.
6. Reconciliation: Salden, Stückzahlen, Positionen und Historien werden zwischen Quelle und Ziel abgeglichen, auf Gesamt- und auf Einzelkontoebene. Abweichungen gehen in eine Fix-Schleife zurück zu Schritt 2 oder 4.

Dieser Kreislauf wird mehrfach durchlaufen. Jeder Probelauf liefert bessere Datenqualität, genauere Laufzeitmessungen und mehr Vertrauen bei den Fachbereichen.

Mit echten Datenvolumen testen

Ein häufiger Planungsfehler: Migrationsskripte werden mit kleinen Stichproben getestet und laufen am Stichtag plötzlich um ein Vielfaches länger. Der erwähnte Fachbeitrag weist darauf hin, dass ungünstige Transformationen quadratisch mit der Datenmenge wachsen können und Speicher, Netzwerk oder Festplatten zum Engpass werden. Testen Sie deshalb gestuft mit wachsenden und schliesslich vollständigen Datenmengen, und messen Sie bei jedem Lauf die Dauer. Nur so wissen Sie, ob das geplante Cutover-Wochenende reicht.

Datenschutz in den Testumgebungen

Vollständige Datenmengen bedeuten echte Kundendaten. Klären Sie mit Ihrer Datenschutz- und Compliance-Funktion früh, in welchen Umgebungen Produktivdaten erlaubt sind, wo anonymisierte oder pseudonymisierte Daten genügen und wer Zugriff hat. Gerade bei Banken mit Bankkundengeheimnis ist das keine Formalie, sondern eine Voraussetzung für jeden Testlauf.

Der Cutover: Runbook, Freeze, Go/No-Go und Rollback

Der Cutover ist der Moment, in dem die Bank vom alten auf das neue System umschaltet. Er wird nicht improvisiert, sondern wie eine Operation geplant und geprobt.

Das Cutover-Runbook

Das Runbook listet jede einzelne Aufgabe vor, während und nach dem Umstieg: wer sie ausführt, wann, mit welcher Vorbedingung, welcher Prüfung und welchem Eskalationsweg. Eine gute Checkliste für Core-Banking-Migrationen versteht sich als Kontrolldokument, nicht als Projektkalender. Das ist der entscheidende Unterschied: Ein Kalender sagt, wann etwas passieren soll. Ein Kontrolldokument sagt, woran Sie erkennen, dass es korrekt passiert ist.

Typische Bausteine eines Runbooks:

• Freeze-Window: ab wann keine Änderungen und keine Buchungen mehr im Altsystem erfolgen
• Abschluss der letzten Tagesendverarbeitung im Altsystem und Sicherung des Stands
• Finale Extraktion, Transformation und Ladung
• Reconciliation-Checkpoints mit festgelegten Toleranzen
• Aktivierung der Schnittstellen zu Umsystemen in definierter Reihenfolge
• Smoke-Tests der wichtigsten Geschäftsvorfälle
• Go/No-Go-Entscheid und Freigabe des Betriebs

Während des Cutovers steuert ein Kontrollraum mit Vertretern aus IT, Betrieb, Fachbereichen und Risiko die Abgleiche und die Fehlerbehandlung. Wer dort sitzt, muss vorher feststehen, inklusive Schichtplan.

Go/No-Go mit klarer Verantwortung

Ein Go/No-Go-Entscheid funktioniert nur, wenn es eine benannte Person oder ein benanntes Gremium gibt, das ihn trifft, und wenn die Kriterien vorab schriftlich feststehen. Welche Reconciliation-Differenz ist akzeptabel? Welche offenen Fehler blockieren den Start, welche dürfen mit Workaround live gehen? Diese Fragen am Stichtag um drei Uhr morgens zu diskutieren, ist die teuerste Variante.

Rollback, der wirklich funktioniert

Viele Projekte haben einen Rollback-Plan auf Papier. Die Checkliste betont, dass ein Rollback-Punkt operativ wiederherstellbar sein muss: Es braucht klare Regeln, welche Transaktionen nach dem Umschalten auf welcher Seite rückgängig gemacht oder neu eingespielt werden. Proben Sie den Rollback mindestens einmal unter realistischen Bedingungen. Ein Rollback, der nie geprobt wurde, ist im Ernstfall keine Option, sondern ein zweites Risiko.

Dress Rehearsals

Planen Sie mehrere Generalproben, bei denen das komplette Runbook mit realistischen Datenmengen und in realistischer Zeit durchgespielt wird. Jede Probe liefert Erkenntnisse zu Laufzeiten, Abhängigkeiten und Engpässen, die direkt in die nächste Version des Runbooks einfliessen.

Was am ersten Geschäftstag sichtbar wird

Die Konvertierung ist durchgelaufen, die Salden stimmen, das Team feiert. Und am Montagmorgen tauchen Fehler auf, die keine Reconciliation gefunden hat. Der Grund: Viele Probleme zeigen sich erst, wenn die Daten im laufenden Geschäft verwendet werden.

Deshalb sollten Rehearsals nicht nur die Datenqualität prüfen, sondern auch die nachgelagerten Prozesse End-to-End und möglichst produktionsnah testen, wie die Migrations-Checkliste empfiehlt. Prüfen Sie konkret:

• Zahlungsverkehr: Laufen Ein- und Ausgänge korrekt, inklusive Daueraufträge und Lastschriften mit ihren Mandaten?
• Karten: Sind Karten, Limiten und Tokens den richtigen Konten zugeordnet?
• Zinsen und Gebühren: Erzeugt der erste Zins- oder Gebührenlauf die gleichen Beträge, die das Altsystem berechnet hätte? Werden Verlängerungen nicht doppelt verrechnet?
• Buchungsdetails: Sind Buchungstexte und Referenzen vollständig, damit Kunden ihre Historie im E-Banking verstehen?
• Auszüge und Feeds: Erhalten Kundenauszüge, Meldewesen und Data Warehouse die erwarteten Daten im richtigen Format?
• Tagesend- und Tagesbeginnläufe: Laufen die Batch-Jobs in der vorgesehenen Zeit und Reihenfolge?

Planen Sie zudem eine Hypercare-Phase mit verstärktem Support, kurzen Eskalationswegen und täglichen Abgleichen. Die ersten Wochen nach dem Go-live entscheiden, ob Kundschaft und Mitarbeitende Vertrauen in die neue Plattform fassen.

Besonderheiten für Banken in der Schweiz

Schweizer Institute migrieren in einem besonderen Umfeld. Einige Punkte sollten Sie früh im Projekt adressieren:

• Aufsicht: Ein Kernbankenwechsel berührt operationelle Risiken, Geschäftskontinuität und oft auch Auslagerungen. Klären Sie mit Ihrer Compliance-Funktion und Ihrer Prüfgesellschaft rechtzeitig, welche FINMA-Anforderungen greifen und ob eine Information an die Aufsicht angezeigt ist.
• Betriebsmodelle: Viele Schweizer Banken betreiben ihr Kernbankensystem nicht selbst, sondern beziehen es als Service eines spezialisierten Betreibers oder im Verbund. Dann ist die Migration ein Dreiecksprojekt zwischen Bank, Plattformanbieter und Betreiber, mit klar zu regelnden Verantwortlichkeiten.
• Mehrsprachigkeit und Mehrwährung: Korrespondenz in mehreren Landessprachen, Fremdwährungskonten und grenzüberschreitende Kundschaft erhöhen die Zahl der Sonderfälle im Mapping.
• Wealth-Management-Tiefe: Privatbanken und Vermögensverwalter migrieren nicht nur Konten, sondern Depots, Mandate, Anlageprofile und Gebührenvereinbarungen, oft mit individuellen Konditionen.
• Archivierung: Daten, die nicht migriert werden, müssen trotzdem gemäss Aufbewahrungspflichten revisionssicher zugänglich bleiben.

Wie wir Software für diese Anforderungen bauen, zeigen wir auf unserer Seite zu Software für regulierte Finanzinstitute. Für Teams, die regulatorische Änderungen während eines mehrjährigen Migrationsprojekts im Blick behalten müssen, kann zudem unsere Regulatory-Intelligence-Plattform RegRadar eine Hilfe sein.

Wo KI die Migration heute beschleunigt

Künstliche Intelligenz verändert nicht die Grundlogik einer Migration, aber sie verkürzt viele Arbeitsschritte, die bisher Wochen gebunden haben:

• Analyse von Altcode und Datenstrukturen: KI-Werkzeuge helfen, undokumentierte Logik in gewachsenen Systemen zu lesen und Mapping-Vorschläge zu erstellen, die Fachleute anschliessend prüfen.
• Testfall-Generierung: Aus Produktbeschreibungen und Mapping-Regeln lassen sich Testfälle und Prüfregeln für Validierung und Reconciliation ableiten.
• Abweichungsanalyse: Bei tausenden Reconciliation-Differenzen gruppiert KI Fehlerbilder und zeigt, welche Ursache die meisten Fälle erklärt.
• Schnittstellenentwicklung: Adapter zwischen Umsystemen und neuem Kern entstehen schneller, wenn Engineering-Teams mit KI-unterstützten Methoden arbeiten.

Wichtig bleibt: Jede KI-gestützte Transformation braucht nachvollziehbare Regeln, Versionierung und eine menschliche Freigabe. In einem regulierten Umfeld muss jede Datenänderung erklärbar sein. Wie wir das in der Praxis umsetzen, beschreiben wir in unserem Ansatz zum KI-nativen SDLC für Bank-Features in Tagen statt Wochen.

Unsere Perspektive

Wir arbeiten mit Banken, Privatbanken, Vermögensverwaltern und Fintechs an Legacy-Modernisierung und Core-Banking-Integration. Unsere wichtigste Beobachtung: Eine Migration scheitert selten an der Zielplattform. Sie gerät ins Stocken, wenn die Arbeit rund um den Kern unterschätzt wird, also die Schnittstellen, die Datenbereinigung, die Testautomatisierung und die vielen kleinen Anpassungen, die erst im Probelauf sichtbar werden.

Deshalb setzen wir auf drei Prinzipien. Erstens: Migration ist Engineering, nicht nur Projektmanagement. Wiederholbare Migrationsläufe, automatisierte Validierungen und Reconciliation-Berichte gehören in Code, nicht in Tabellenblätter. Zweitens: Das Team, das die Schnittstellen baut, sollte auch die Integration in Ihre IT-Umgebung verantworten. So gehen beim Übergang zwischen Konzept und Umsetzung keine Details verloren. Drittens: Wir nutzen KI-unterstützte Entwicklungsmethoden und erprobte Feature-Module, damit regulatorisch konforme Banking-Software in Tagen statt Wochen bereitsteht. Das schafft Zeit für das, was bei einer Migration wirklich zählt: mehr Probeläufe, mehr Abgleiche, mehr Sicherheit vor dem Stichtag.

Eine Core-Banking-Migration ist auch eine Chance. Wer seine Daten einmal gründlich bereinigt und seine Schnittstellen sauber über APIs anbindet, schafft die Grundlage für alles, was danach kommt: digitale Produkte, Embedded Finance und KI-Agenten, die auf verlässlichen Daten arbeiten.

— Igor

Wie S-PRO Ihre Migration unterstützt

Unsere Senior-Engineering-Teams begleiten Kernbankenprojekte dort, wo Plattformanbieter und interne IT an Kapazitätsgrenzen stossen: bei der Migrationsstrategie, der Entwicklung von Schnittstellen und Migrationsskripten, der IT-Infrastruktur und der Verstärkung bestehender Teams. Ob Sie eine Produkt-Migrationsstrategie, IT-Infrastruktur-Engineering oder eine gezielte Team-Erweiterung brauchen: Wir steigen dort ein, wo Ihr Projekt gerade steht. Für die vorgelagerte Planung bieten wir zudem Technologieberatung, IT-Strategie und Roadmap an. Sprechen Sie mit unserem Team in Zürich über Ihre Ausgangslage.

FAQ

Was ist ein Kernbankensystem?

Ein Kernbankensystem ist die zentrale Software einer Bank, die Konten, Salden, Buchungen, Zinsen, Gebühren und Kundenverträge führt. Es bildet das Hauptbuch, an das E-Banking, Zahlungsverkehr, Karten, Meldewesen und weitere Umsysteme angeschlossen sind. Moderne Plattformen sind modular aufgebaut und über APIs angebunden.

Wie lange dauert eine Core-Banking-Migration?

Das hängt von Grösse, Produktpalette, Zahl der Umsysteme und gewählter Strategie ab. Ein verlässlicher Zeitplan entsteht erst, wenn erste Probeläufe mit realistischen Datenmengen echte Laufzeiten und Fehlerquoten liefern. Planen Sie deshalb früh mehrere Migrationsläufe ein und leiten Sie den Stichtag aus deren Ergebnissen ab.

Big Bang oder gestaffelte Migration: Was ist sicherer?

Keine Variante ist grundsätzlich sicherer. Der Big Bang konzentriert das Risiko auf einen Stichtag, vermeidet aber Brückenschnittstellen und Doppelbetrieb. Die gestaffelte Migration verteilt das Risiko, verlangt jedoch temporäre Schnittstellen und eine saubere Trennung der Kundensegmente.

Warum ist die Reconciliation so wichtig?

Die Reconciliation weist nach, dass Salden, Positionen und Historien nach der Migration mit dem Altsystem übereinstimmen. Sie ist die Grundlage für den Go/No-Go-Entscheid und für die Nachweise gegenüber Revision und Prüfgesellschaft. Ohne sie bleibt unklar, ob Daten nur konvertiert oder fachlich korrekt übernommen wurden.

Kann man das Altsystem nach dem Go-live sofort abschalten?

In der Regel nicht. Das Altsystem bleibt meist eine Zeit lang lesend verfügbar, damit Rückfragen geklärt und Rollback-Szenarien abgedeckt sind. Daten, die nicht migriert wurden, müssen ausserdem gemäss Aufbewahrungspflichten revisionssicher archiviert werden.

Quellen

• Klaus Haller: Data Migration Project Management and Standard Software
• remwm: Core banking migration checklist

Empfehlungen

• Kernbankensystem-Integration: Compliance und Strategien
• Core- & Legacy-Modernisierung mit KI
• Banking MVP: Entwicklung und Beispiele

Created with BabyLoveGrowth, the AI writing tool