Zehn DWH-Migrations-Mythen, die KI-Readiness ausbremsen

Wer heute über Datenplattform-Modernisierung spricht, landet schnell bei denselben Einwänden. Zu teuer. Zu riskant. Zu komplex. Diese Argumente begegnen uns bei Callista regelmässig -- und sie sind nicht unbegründet. Aber sie erzählen oft nur die halbe Geschichte. Databricks hat kürzlich einen interessanten Blog-Beitrag veröffentlicht, der zehn verbreitete Mythen rund um Data-Warehouse-Migrationen adressiert. Wir nehmen das zum Anlass, diese Mythen einzuordnen und mit eigenen Erfahrungen aus der Praxis zu ergänzen.

Warum das Thema gerade jetzt relevant ist

Fast jede grössere KI-Initiative - ob Predictive Analytics, Empfehlungssysteme oder die Nutzung von Large Language Models für die Analyse von Unternehmensdaten - steht und fällt mit der Qualität und Zugänglichkeit der Datenbasis. Wer seine Daten in einem fragmentierten Legacy-DWH hält, das vor zehn Jahren für Reporting-Zwecke konzipiert wurde, wird bei KI-Projekten früher oder später an eine Wand laufen.

Das bedeutet nicht, dass jedes Unternehmen sofort migrieren muss. Aber es bedeutet, dass man die Entscheidung bewusst treffen sollte - und nicht auf Basis von Mythen, die sich über Jahre eingeschliffen haben.

Die Mythen im Überblick

Mythos 1: Man muss alles migrieren

Das ist vermutlich der hartnäckigste Irrtum. In vielen Legacy-Systemen schlummern hunderte von Tabellen, Stored Procedures und ETL-Jobs, die seit Jahren nicht mehr produktiv genutzt werden. Der Reflex, alles eins zu eins zu übertragen, führt dazu, dass man technische Schulden einfach auf die neue Plattform verschiebt.

Der bessere Ansatz: Zuerst die bestehende Umgebung mit der Hilfe von KI analysieren und dokumentieren. So geschäftskritischen Workloads identifizieren, dann gezielt migrieren. In der Praxis sieht man, dass Unternehmen, die diesen Schritt ernst nehmen, 30 bis 50 Prozent weniger Objekte migrieren als ursprünglich geplant - und trotzdem alle relevanten Use Cases abdecken.

Mythos 2: Tool-basierte Migration löst das Problem automatisch

Tools wie Lakebridge oder Claude Code sind wertvoll. Sie automatisieren SQL-Konvertierung, Schema-Mapping und Datenvalidierung. Aber ein Tool allein ersetzt kein Migrationskonzept. Wer proprietäres T-SQL oder Teradata-BTEQ blindlings konvertiert, ohne die zugrundeliegende Logik zu hinterfragen, übernimmt ineffiziente Patterns auf die neue Plattform. Deshalb nutzen wir KI Agenten für die Analyse, die Dokumentation, das Mapping der alten auf die neue Architektur und definieren so ein sinnvolles Refactoring.

Tools beschleunigen die Migration. Aber sie ersetzen nicht das Denken.

Mythos 3: Migrationen brauchen riesige Teams

Die Vorstellung, dass man 20 oder mehr Spezialisten braucht, stammt aus einer Zeit, in der jede Konvertierung von Hand geschrieben wurde. Moderne Migrationstools mit KI-gestützter SQL-Übersetzung wie Claude Code reduzieren den manuellen Aufwand erheblich. Ein erfahrenes Kernteam von fünf bis acht Personen, ergänzt durch spezialisierte Partner, reicht in vielen Fällen aus.

Mythos 4: Die Migration ist ein reines IT-Projekt

Dieser Mythos ist aus unserer Erfahrung der gefährlichste. Wenn die Fachbereiche nicht von Anfang an eingebunden sind, migriert man zwar Daten - aber nicht die Fähigkeit, mit diesen Daten Entscheidungen zu treffen. Erfolgreiche Migrationen beginnen mit Geschäftsfragen: Welche Daten brauchen wir, um welche Entscheidungen schneller oder besser zu treffen?

Ein vielversprechender Ansatz ist, dass Führungskräfte ein bis zwei messbare Business-Use-Cases (etwa Fraud Detection oder Kundensegmentierung) definieren, die in den ersten 90 Tagen auf der neuen Plattform laufen sollen. Das schafft Sichtbarkeit und Momentum.

Mythos 5: Man muss sich zwischen Lift-and-Shift und komplettem Neubau entscheiden

Diese Entweder-oder-Logik ist in der Praxis selten hilfreich. Der pragmatische Weg ist oft ein hybrides Vorgehen: Lift-and-Shift für stabile, unkritische Workloads, um das Legacy-System schnell abzulösen. Gleichzeitig gezieltes Redesign für die Pipelines, die von der neuen Architektur am meisten profitieren. Wir machen das genau so bei unseren Kunden, Lösungen wo Lizenzen sparen das Ziel ist oder Knowhow nicht mehr vorhanden ist, migrieren wir als Lift und Shift, andere mit mehr Value Add werden refactored.

Mythos 6: Die Kosten explodieren immer

Ja, Migrationen können teuer werden. Aber die eigentlichen Kostentreiber sind selten die Technologie selbst. Gemäss Branchenstudien scheitern rund 70 Prozent der Migrationsprojekte an ihren Zielen - und die Hauptgründe sind mangelnde Planung, unterschätztes Change Management und fehlende Governance-Strukturen. Wer diese organisatorischen Themen ernst nimmt, kann die Kosten gut kontrollieren.

Hinzu kommt: Die Kosten des Nichtstuns werden selten kalkuliert. Doppelte Lizenzkosten, manuelle Workarounds, verpasste KI-Projekte - das summiert sich.

Mythos 7: Unsere BI-Reports werden nicht mehr funktionieren

Die Sorge ist verständlich, aber oft übertrieben. Moderne Lakehouse-Plattformen wie Databricks unterstützen Standard-SQL und bieten Konnektoren für gängige BI-Tools. In der Praxis erfordern vielleicht 10 bis 15 Prozent der Reports Anpassungen - typischerweise dort, wo Legacy-spezifische SQL-Dialekte oder Stored Procedures im Spiel sind.

Der Schlüssel ist eine systematische Validierung: Bestehende Reports gegen die neue Plattform testen, Abweichungen dokumentieren, gezielt anpassen.

Mythos 8: Die Governance geht bei der Migration verloren

Eher das Gegenteil: Eine Migration ist die Gelegenheit, Governance von Grund auf richtig aufzusetzen. Tools wie Unity Catalog bieten integrierte Daten-Governance, die in vielen Legacy-Systemen nur mit aufwendigen Zusatzlösungen möglich war. Wer Governance-Fragen allerdings auf "nach der Migration" verschiebt, handelt sich Probleme ein.

Unsere Empfehlung: Governance-Regeln (Dateneigentümerschaft, Zugriffskontrolle, Audit-Trails) als Teil des Migrationsprojekts definieren, nicht als Nacharbeit.

Mythos 9: Vendor Lock-in wird einfach durch einen neuen Vendor Lock-in ersetzt

Eine berechtigte Sorge - aber sie ignoriert die Architektur-Unterschiede. Die Lakehouse-Architektur basiert auf offenen Formaten (Delta Lake, Apache Parquet) und offenen Standards (Apache Spark). Daten bleiben in eurem Cloud-Storage, nicht in einer proprietären Black Box. Das ist ein fundamentaler Unterschied zu traditionellen DWH-Systemen, die Daten in geschlossenen Formaten speichern.

Natürlich entsteht eine gewisse Abhängigkeit von jeder Plattform. Aber der Grad der Abhängigkeit ist bei einer offenen Architektur definitiv geringer.

Mythos 10: Wir können die Migration aufschieben, bis wir wirklich KI brauchen

Das klingt rational, ist aber ein Trugschluss. KI-Readiness ist kein Schalter, den man umlegt. Sie entsteht durch eine Datenplattform, die hochwertige, gut strukturierte und zugängliche Daten liefert - und durch Teams, die gelernt haben, mit modernen Datentools zu arbeiten. Beides braucht Zeit.

Wer wartet, bis das erste KI-Projekt dringend wird, startet die Migration unter Zeitdruck. Und Zeitdruck ist der zuverlässigste Weg, um genau die Fehler zu machen, die man vermeiden wollte.

Wie wir bei Callista an DWH-Migrationen herangehen

Die zehn Mythen decken sich mit dem, was wir in unseren Projekten beobachten. Wir haben in den letzten Monaten eine KI-gestützte Migrations-Pipeline aufgebaut, die mehrere dieser Herausforderungen direkt adressiert.

Dokumentation und Discovery mit KI. Bevor eine einzige Zeile Code migriert wird, lassen wir KI-Agenten die bestehende Legacy-DWH-Umgebung systematisch dokumentieren. Tabellenstrukturen, Abhängigkeiten, ETL-Logik, Datenflüsse - alles, was in vielen Unternehmen nur in den Köpfen einzelner Entwickler existiert. Das ist der Schritt, den Mythos 1 und Mythos 4 ansprechen: Erst verstehen, was man hat, bevor man entscheidet, was man migriert.

Automatisierte Migration -- 1:1 und Refactoring. Je nach Situation setzen wir auf zwei Ansätze. Für stabile Workloads, die sich bewährt haben, migrieren wir 1:1 - der Code wird konvertiert, aber die Logik bleibt identisch. Für Bereiche, in denen sich ein Architekturwechsel lohnt, refactoren wir auf neue Patterns. Ein konkretes Beispiel: SAS DI Jobs, die auf das Databricks Medallion-Pattern umgestellt werden - von monolithischen Batch-Jobs zu einer sauberen Bronze-Silver-Gold-Architektur.

Verification: LLM-basiert und deterministisch. Das ist der Teil, den viele unterschätzen. Wenn KI Code generiert, braucht es eine belastbare Qualitätssicherung. Wir setzen dafür spezialisierte Agenten ein, die den generierten Code auf zwei Ebenen prüfen: LLM-basiert (semantischer Vergleich - macht der neue Code dasselbe wie der alte?) und deterministisch (Datenvergleiche auf Zeilen- und Spaltenebene, Hash-Validierungen). Gerade bei 1:1-Migrationen, wo Abweichungen sofort auffallen müssen, ist diese Kombination entscheidend.

Self-Healing Loop. Wenn die Verification Abweichungen findet, korrigiert ein weiterer Agent den Code automatisch und durchläuft die Prüfung erneut. Das Ganze läuft in einem iterativen Loop, bis der Code die Qualitätskriterien erfüllt - oder die Abweichung als menschliche Entscheidung eskaliert wird. Jeder Schritt wird im Repository dokumentiert: Originalcode, generierter Code, Verification-Ergebnisse, Korrekturen.

Das ist kein theoretisches Framework. Wir setzen diese Pipeline produktiv ein - unter anderem bei einer grossen Schweizer Versicherung für die Synapse-zu-Databricks-Migration.

Was wir daraus mitnehmen

Databricks hat mit den zehn Mythen einen nützlichen Rahmen geschaffen. Drei Punkte möchten wir besonders hervorheben:

Erstens: Discovery vor Migration. Die Rationalisierung bestehender Workloads ist kein optionaler Schritt. Sie ist der Schritt, der über Erfolg oder Misserfolg entscheidet. Wer nicht weiss, was er hat, kann nicht planen, was er braucht.

Zweitens: Organisatorische Readiness schlägt technische Perfektion. Eine neue Plattform verstärkt die bestehende Organisationskultur. Wer keine klaren Verantwortlichkeiten, keine Versionskontrolle und keine Governance hat, wird diese Schwächen auf Databricks genauso spüren wie auf dem alten System.

Drittens: Iterativ starten, nicht perfekt planen. Ein Pilotprojekt mit einem klar definierten Use Case, das innerhalb von drei Monaten Ergebnisse liefert, ist wertvoller als ein detaillierter Migrationsplan, der sechs Monate in der Abstimmung hängt.

Die Frage ist nicht, ob eine Modernisierung sinnvoll ist. Die Frage ist, ob man sie bewusst steuert - oder ob man wartet, bis die Umstände einen dazu zwingen.

Quellen

- Databricks, "How Databricks Simplifies Data Warehouse Migrations with Proven Strategies and Tools"
- DSS Consulting, "Databricks Migration from a Leadership Perspective"
- Databricks, "New in Migrations: Faster and More Predictable"