Daten & Technologie
Vom Legacy-Data-Warehouse zu Snowflake: Die Brücke, damit Marketing, Sales und Service direkt arbeiten können
Keine Big-Bang-Migration: Wie Banken Legacy-DWH und Snowflake verbinden und Daten aktivieren.
•
acceleraid Redaktion
5 Min. Lesezeit

Teil 2 von 2 unserer Serie „Data is the Key for AI" — und Abschluss der Serie. Teil 1 hat gezeigt, warum KI-Projekte an der Datenschicht scheitern (Data is the key for AI: Warum KI-Projekte an der Datenschicht scheitern). Dieser Teil zeigt, wie die technische Brücke zwischen Legacy-Systemen und einer modernen Datenplattform konkret aussieht.
Die Spaghetti-Architektur als Bremse
Viele Banken kennen das Problem aus eigener Erfahrung: Datenflüsse, die über Jahre gewachsen sind, ohne dass jemals ein einheitliches Zielbild dahinterstand. McKinsey beschreibt dieses Muster in seiner Analyse zur Datenarchitektur im Banking präzise als „Spaghetti-Architektur" — gekennzeichnet durch fragmentierte Data Warehouses und Data Lakes sowie den parallelen Betrieb alter und neuer Plattformen. Die Folgen sind konkret messbar: verzögerte Entscheidungen, erhöhte Sicherheits- und Compliance-Risiken sowie steigende Kosten für den Unterhalt mehrerer komplexer Umgebungen gleichzeitig (McKinsey, Getting the data architecture right in banking).
Der wirtschaftliche Hebel, die richtige Architektur zu wählen, ist erheblich. Banken, die die passende Datenarchitektur-Archetype wählen, können laut McKinsey die Implementierungszeit halbieren und die Kosten um 20 Prozent senken. Fünf identifizierte Best Practices bringen zusätzlich 20 Prozent niedrigere Plattform-Baukosten, 30 Prozent schnellere Time-to-Market und 30 Prozent geringere Change-Kosten (McKinsey). Das deckt sich mit der in Teil 1 beschriebenen Erkenntnis: Die Datenschicht entscheidet über Erfolg oder Scheitern von KI- und Digitalisierungsprojekten — hier zusätzlich mit einem klaren Preisschild versehen.
Warum Cloud-Datenplattformen im Finanzsektor Standard werden
Dass diese Neuausrichtung nicht nur eine theoretische Empfehlung ist, zeigt die Marktdurchdringung von Cloud-Datenplattformen im Finanzsektor. Bereits 2021 nutzten rund 57 Prozent der Financial-Services-Unternehmen aus der Fortune-500-Liste Snowflake, mit Referenzkunden wie Allianz, AXA, BlackRock, Capital One, NYSE, Refinitiv, Square, State Street, Western Union und Wise (Snowflake, Launch der Financial Services Data Cloud). Snowflake selbst benennt das adressierte Legacy-Problem explizit: veraltete Prozesse des Duplizierens von Daten und des Hin-und-Her-Schickens von Dateien zwischen Systemen.
Zum 31. Januar 2026 zählt Snowflake mehr als 13.900 Kunden weltweit, davon 790 aus der Forbes-Global-2000-Liste — ein Plus von 5 Prozent gegenüber dem Vorjahr. Der Produktumsatz im vierten Quartal lag bei 1,23 Milliarden US-Dollar, ein Plus von 30 Prozent gegenüber dem Vorjahresquartal; im Geschäftsjahr 2026 wurden 4,47 Milliarden US-Dollar Umsatz erzielt, ein Plus von 29 Prozent. Snowflake nennt „highly-regulated markets such as financial services" explizit als Wachstumsmarkt und führt Capital One als Referenzkunde (Snowflake, Q4/FY2026 Financial Results). Quantifizierte Kundenergebnisse aus dem Finanzsektor unterstreichen den Effekt: State Street berichtet laut Anbieter von 25-mal höherer Produktivität der Data-Operations-Teams und 87 Prozent weniger falschen Datenfehler-Alerts; Chicago Trading Company erzielte nach Ablösung von managed Spark eine Kostenersparnis von 54 Prozent (laut Anbieter Snowflake, AI Data Cloud for Financial Services).

Die Brücke statt der Big-Bang-Migration
Der entscheidende Unterschied zur klassischen Migrationsstrategie liegt im Ansatz: nicht Ablösung, sondern Anbindung. Eine Big-Bang-Migration, bei der Core-Banking-Systeme, Kartenverarbeitung und CRM in einem Schritt auf eine neue Zielarchitektur umgestellt werden, ist für die meisten Institute weder finanziell noch operativ vertretbar — die von McKinsey beschriebenen Risiken paralleler Systemlandschaften würden sich in der Übergangsphase eher verschärfen als auflösen. Der praktikablere Weg ist die Brücke: Legacy-Data-Warehouse und Data Lake bleiben zunächst bestehen, werden aber über Konnektoren an eine moderne Cloud-Datenplattform wie Snowflake angebunden, sodass Echtzeit-Aggregation aus CRM, Core Banking und Kartenverarbeitung möglich wird, ohne die bestehenden Systeme sofort abzulösen.
Technisch macht das insbesondere Snowflakes Secure-Data-Sharing-Funktion attraktiv: Beim Zero-Copy-Sharing wird laut Anbieter keine tatsächliche Kopie der Daten zwischen Accounts übertragen. Das Sharing läuft über die Services-Schicht und den Metadaten-Store der Plattform; geteilte Daten verbrauchen beim Empfänger keinen zusätzlichen Speicherplatz und erzeugen dort keine Storage-Kosten — abgerechnet wird nur die tatsächliche Rechenleistung. Neue oder aktualisierte Objekte in einem Share stehen allen Empfängern sofort zur Verfügung, der Zugriff bleibt jederzeit widerrufbar (Snowflake Docs, About Secure Data Sharing). Für Banken bedeutet das: Die immer wieder kritisierte Praxis des Datei-Hin-und-Her-Schickens zwischen Abteilungen und Systemen entfällt, ohne dass Legacy-Systeme sofort ersetzt werden müssen.
Von der Aggregation zur Aktivierung im Marketing
Eine konsolidierte Datenbasis in der Cloud ist die Voraussetzung, aber noch nicht die Aktivierung. Der letzte Schritt der Brücke führt die aggregierten Daten aus dem Warehouse zurück in die Systeme, in denen Marketing, Sales und Service täglich arbeiten — über Reverse ETL. Anbieter wie Hightouch lesen Daten direkt aus dem Snowflake-Warehouse und synchronisieren nur die tatsächlich veränderten Datensätze in nachgelagerte Zielsysteme, verbunden etwa über Snowflake Partner Connect. Ab einer Größenordnung von mehr als 100.000 Zeilen empfiehlt der Anbieter dafür eine Sync-Engine mit Change-Data-Capture direkt in eigenen Snowflake-Schemata (Hightouch Docs, Snowflake Source).
Konkret sieht der Aktivierungspfad in eine Customer-Engagement-Plattform so aus: Hightouch synchronisiert ein Warehouse-Modell oder eine Audience in eine Braze Cohort; daraus entsteht in Braze ein Segment, das als Filter für Campaigns oder Canvas genutzt werden kann. Wichtig dabei: Es werden keine neuen Nutzerprofile angelegt, sondern nur bestehende Braze-Profile der Cohort hinzugefügt oder daraus entfernt (Braze Docs, Hightouch Cohort Import). Diese Warehouse-zentrierte Architektur ist längst Mainstream: 71 Prozent der befragten Martech- und Marketing-Operations-Profis haben ein Cloud Data Warehouse oder Data Lake im Stack, wobei 47 Prozent Daten einseitig in das Warehouse einspeisen und 29,2 Prozent Daten einseitig aus dem Warehouse in Martech-Anwendungen synchronisieren (chiefmartec/MartechTribe, „Martech for 2025").
Phase | Kernaufgabe | Technischer Hebel |
|---|---|---|
Anbinden | Legacy-Systeme ohne Ablösung verbinden | Konnektoren zu Core Banking, Kartenverarbeitung, CRM |
Aggregieren | Konsolidierte, konsistente Datenbasis schaffen | Zero-Copy-Sharing statt Datei-Duplikate |
Aktivieren | Daten in operative Systeme zurückspielen | Reverse ETL (z. B. Cohort Import in Engagement-Plattform) |
Was das für Banken in der DACH-Region bedeutet
Für Institute, die weiterhin mit Finastra-, Temenos- oder SAP-Banking-basierten Core-Systemen arbeiten, ist die Brücken-Architektur der realistischere Weg gegenüber einer vollständigen Neuimplementierung. Die acceleraid-Plattform bietet dafür entsprechende Konnektoren zu Finastra, Temenos und SAP Banking sowie eine Anbindung an Snowflake, sodass bestehende Core-Banking- und Kartenverarbeitungssysteme mit der modernen Datenschicht verbunden werden können, ohne dass ein Big-Bang-Austausch nötig wird (acceleraid Platform). Damit lässt sich die in Teil 1 beschriebene governete Datenbasis — System of Record, Consent, Lineage, PII-Schutz — auch dann realisieren, wenn ein Institut noch nicht bereit ist, sein Kernbankensystem vollständig zu ersetzen (acceleraid Banking).
Diese Brücken-Logik greift auch bei der Anbindung bestehender Martech-Systeme: Wie sich Plattformen wie Braze, Adobe oder Salesforce Marketing Cloud ohne Rip-and-Replace in die bestehende Systemlandschaft integrieren lassen, haben wir im ersten Teil unserer Serie „Future-Ready Martech" beschrieben (No Rip and Replace: Seamless Integration mit Braze, Adobe, Salesforce). Zusammen mit der in Teil 1 dieser Serie beschriebenen Data-Governance-Grundlage ergibt sich ein vollständiges Bild: Governance und Architektur sind zwei Seiten derselben Voraussetzung dafür, dass KI im Banking tatsächlich produktiv wird — nicht als einmaliges Migrationsprojekt, sondern als kontinuierlich weiterentwickelte Brücke zwischen bestehenden Systemen und neuen Fähigkeiten.
Illustration: KI-generiert. KI-gestützte Inhalte: Bei der Erstellung unserer Beiträge setzen wir KI-Technologien und automatisierte Agenten ein, unter anderem von Microsoft, Google, OpenAI, Anthropic und weiteren Anbietern. Themen, fachliche Ausrichtung und finale Freigabe liegen bei unserem Team.
Weitere Insights
Wir verwenden Cookies 🍪
Unbedingt erforderliche Cookies, etwa für Pipedrive-Formulare, bleiben aktiv. Mit Ihrer Einwilligung nutzen wir außerdem Google Analytics zur Analyse und Leadfeeder zur Besucheridentifikation. Weitere Informationen finden Sie in unserer Datenschutzerklärung.
Ablehnen
Alle akzeptieren