Eine Databricks Migration bezeichnet die Überführung von Daten, Datenmodellen und Transformationslogik aus einem bestehenden Data Warehouse, ETL-Tool oder einer bestehenden BI-Landschaft in eine Lakehouse-Architektur. Sie kombiniert die Skalierbarkeit eines Data Lakes mit der Governance und Verlässlichkeit eines Data Warehouse. Der richtige Migrationsansatz, Lift & Shift, Neuentwicklung oder Hybrid, hängt dabei stark vom Ausgangssystem und dem gewünschten Modernisierungsgrad ab.
Sie evaluieren gerade, ob Ihr bestehendes Data Warehouse noch die richtige Basis für die nächsten Jahre ist? Oder steht Ihr Team bereits mitten in der Entscheidung, welcher Migrationsweg der richtige ist?
Genau in dieser Situation sehen wir die meisten unserer Kunden: Das Datenvolumen wächst, die Lizenzkosten für das Legacy-System auch, und parallel soll die Organisation KI- und ML-Anwendungsfälle im Produktivsystem in Betrieb bringen, für die das alte System nie gebaut wurde.
Dieser Artikel ordnet ein, was eine Databricks Migration konkret bedeutet, warum Unternehmen überhaupt migrieren, welche Wege es gibt und welche typischen Szenarien in der Praxis vorkommen.
Was ist eine Databricks Migration?
Eine Databricks Migration ist der strukturierte Prozess, Daten, Tabellenstrukturen und Transformationslogik aus einem bestehenden System in eine Lakehouse-Architektur zu überführen, mit dem Ziel, Skalierbarkeit für Analytics und KI-Workloads zu gewinnen, ohne die bestehende Business-Logik komplett neu erfinden zu müssen. Anders als eine reine Tool-Einführung verändert die Migration nicht nur die Plattform, sondern oft auch Datenmodell, Historisierung und Teile der zugrunde liegenden Codebasis.
Der Begriff Lakehouse wurde dabei maßgeblich von Databricks geprägt. Das Lakehouse-Konzept führt den Data Lake und das Data Warehouse in einer gemeinsamen Architektur zusammen. Ausgelöst wird eine Migration meist durch technische Schulden im Altsystem, auslaufenden Herstellersupport oder den Wunsch, ML- und GenAI-Anwendungsfälle auf einer gemeinsamen Datenbasis zu betreiben.
Machen Sie Databricks zu Ihrem Wettbewerbsvorteil
Mit unserer Databricks-Beratung entwickeln Sie eine skalierbare Architektur, realisieren produktive Use Cases und befähigen Ihr Team nachhaltig.
Migration vs. Modernisierung:
- Eine reine Migration übernimmt bestehende Strukturen weitgehend unverändert auf der neuen Plattform.
- Eine Modernisierung verändert zusätzlich Datenmodell, Namenskonventionen oder Historisierungslogik.
- In der Praxis kombinieren die meisten Projekte beides, dazu mehr im Abschnitt zu den Migrationsansätzen.
Warum migrieren Unternehmen zu Databricks?
In unseren Projekten hören wir selten “wir wollen einfach eine neue Plattform”. Migrationen werden ausgelöst, weil ein konkretes Problem im Alltag spürbar wird. Die folgenden sechs Gründe sind die, die in der Praxis am häufigsten den Ausschlag geben:
Skalierung ohne monatelange Hardware-Beschaffung. Klassische Data Warehouses stoßen bei wachsendem Datenvolumen an Grenzen, die sich nur durch neue Hardware lösen lassen. Bestellung, Einbau und Inbetriebnahme können Monate dauern, bevor ein neues Datenprojekt überhaupt starten kann. Cloud-native Plattformen skalieren dagegen sofort nach oben und unten, ohne größere Vorabinvestition.
Kosteneffizienz durch Pay-as-you-go statt Kapitalbindung. Cloud-native Data Warehouses laufen meist nutzungsbasiert ab, statt hohe Vorabkosten für Hardware zu binden. Für Unternehmen bedeutet das: Budget fließt in tatsächliche Nutzung statt in Kapazität, die im Zweifel ungenutzt bleibt.
Grundlage für Advanced Analytics und KI. Eine moderne Plattform unterstützt Echtzeit-Datenverarbeitung, KI-gestützte Auswertungen und Predictive Modeling deutlich besser als klassische Warehouses, welche dafür nie ausgelegt wurden.
Warum Lakehouses die Daten-Architektur der Zukunft sind
In unserem Whitepaper erfahren Sie:
- Wie sich ein Data Lakehouse von anderen Architekturen unterscheidet.
- Wie Sie durch ein Lakehouse KI-Anwendungen schneller umsetzen.
- Wie Sie ihr internes Team befähigen selbstständig KI Projekte zu implementieren.
Bessere Governance und Sicherheit. Moderne Plattformen bringen eingebaute Sicherheitsfunktionen wie Verschlüsselung, Zugriffskontrollen und Compliance-Werkzeuge mit, anstatt dass jedes Team eigene Lösungen dafür bauen muss.
Flexibilität bei neuen Use Cases und Datenquellen. Anders als starre Legacy-Systeme lassen sich cloud-basierte Plattformen schneller an neue Anwendungsfälle und zusätzliche Datenquellen anpassen.
Kein Vendor-Lock-in durch offene Formate. Offene Formate erlauben es, verschiedene Best-of-Breed-Tools zu kombinieren, statt an einen einzelnen Hersteller gebunden zu sein. Wiederkehrende Migrationen alle paar Jahre entstehen häufig genau daraus, dass Unternehmen von einem proprietären System ins Nächste wechseln, statt einmal auf offene Standards zu setzen.
Welche Migrationsansätze gibt es?
Nach der Frage “warum” kommt fast immer die Frage “wie”. Drei Ansätze haben sich in der Praxis etabliert, und keiner davon ist grundsätzlich richtig oder falsch, sondern abhängig von Ihrer Ausgangslage:
| Ansatz | Vorteil | Nachteil |
| Lift & Shift | Schnellster Weg, das Altsystem abzulösen, viel automatisierte Konvertierung möglich | Neue Business Cases bleiben stark eingeschränkt, technische Schulden wandern mit |
| Komplette Neuentwicklung | Vollständige Modernisierung von Datenmodell und Logik, Raum für neue Use Cases wie ML-Anwendungsfälle | Deutlich längere Time-to-Market, höheres Projektrisiko, hohe Komplexität |
| Hybrid-Ansatz | Schnelle erste Migration, Architektur wird aber bereits so gebaut, dass neue Use Cases später ergänzt werden können | Erfordert von Anfang an etwas mehr Planungsaufwand als reines Lift & Shift |
Wer schnell von einem Altsystem herunterkommen muss, sollte ernsthaft Lift & Shift prüfen, das ist unsere Empfehlung aus der Projektpraxis. Wer dagegen ohnehin plant, neue ML- oder GenAI-Anwendungsfälle einzuführen, sollte gleich in Richtung Hybrid-Ansatz denken. Eine reine 1:1-Übertragung verschiebt die technischen Schulden nur auf die neue Plattform, statt sie zu reduzieren.
In welcher Reihenfolge migrieren: ETL first oder BI first?
Neben dem grundsätzlichen Ansatz stellt sich eine zweite, oft unterschätzte Frage: Womit fangen Sie an?
- Ingestion & ETL first: Sie bauen zuerst das Datenfundament neu auf, Quellen, Transformationslogik, Datenmodell, und binden Reports und Dashboards erst am Ende an die neue Plattform an. Vorteil: solides Fundament, saubere Basis für alles Weitere. Nachteil: Fachbereiche sehen lange keinen sichtbaren Nutzen, was die Akzeptanz bremsen kann.
- BI first: Sie replizieren zuerst die Serving-Schicht, sodass Fachbereiche schnell mit vertrauten Reports auf der neuen Plattform arbeiten können, und modernisieren Ingestion und ETL im Hintergrund nach. Vorteil: schneller sichtbarer Nutzen, höhere Akzeptanz. Nachteil: Sie müssen mehrere Schichten parallel managen, das braucht einen strikten Plan.
In unseren Projekten empfehlen wir BI first vor allem dann, wenn Stakeholder-Vertrauen ein kritischer Erfolgsfaktor ist. Ingestion/ETL first empfehlen wir, wenn technische Sauberkeit klar Priorität vor einem schnellen Showcase hat.
Unser KI-gestützter Migrationsansatz
Die Übersetzung von Legacy-Code, SQL-Prozeduren, ETL-Mappings oder Reporting-Logik, ist in klassischen Projekten der größte Zeitfresser, unabhängig davon, welchen der drei Ansätze Sie wählen. Genau hier setzt unser eigener KI-gestützter Migrationsansatz an: Custom-entwickelte Agenten übernehmen die automatisierte Übersetzung von Legacy-Code in produktionsreife Databricks-Pipelines und reduzieren die Projektlaufzeit in unseren Projekten um bis zu 70%, ohne dass Business-Logik oder Historisierung dabei verloren gehen.
Hinweis von Laurenz, CTO bei Datasolut:
Der größte Hebel unseres Ansatzes liegt nicht in der reinen Code-Generierung, sondern darin, dass wir Kontext wie Schema, Schlüssel und bestehende Transformationslogik vorab strukturiert erfassen. Je vollständiger dieser Kontext, desto schneller und sicherer läuft die eigentliche Migration.
Im Gegensatz zum klassischen Einsatz von Lakebridge für eine Migration (Lift & Shift), ergänzen wir das Verfahren dahingehend, dass wir eine nachhaltige Modernisierung anstreben.
Welche typischen Migrationsszenarien gibt es?
Je nach Ausgangssystem sieht eine Migration in der Praxis sehr unterschiedlich aus. Im Folgenden haben wir fünf klassische Migrationsszenarien in einem kurzen Überblick dargestellt. Zu jedem Szenario haben wir typische Gründe einer anstehenden Migration bzw. vorhandene Problemstellungen aufgelistet:
| # | Szenario | Gründe/Problemstellungen |
| 1 | Von einem klassischen On-Premise Data Warehouse (z.B. Teradata, Oracle) | Auslaufender Support, hohe Lizenzkosten, Skalierung nur über neue Hardware möglich |
| 2 | Von einem Cloud Data Warehouse (z.B. Snowflake, BigQuery, Synapse) | Konsolidierung mehrerer Plattformen, Kostenoptimierung, Vendor-Lock-in vermeiden |
| 3 | Von bestehenden ETL-Tools (z.B. Informatica, Prophecy) | Tausende gewachsene Mappings, hohe Übersetzungskomplexität, Tribal Knowledge |
| 4 | Von Hadoop-Altplattformen | End-of-Life-Druck, hohe Betriebskomplexität, eigene Partitionierungslogik |
| 5 | Aktualisierung bestehender BI-Landschaften (z.B. Power BI, Tableau, AtScale) | Serving Layer wird neu aufgesetzt, oft im Rahmen einer BI-first-Migration |
Bei den Szenarien 1 bis 4 sehen wir in der Praxis meist Ingestion/ETL-first als sinnvolleren Startpunkt, weil das Datenfundament ohnehin neu aufgebaut werden muss. Bei Szenario 5 spricht dagegen vieles für BI first, da die Reporting-Schicht hier bereits der eigentliche Ausgangspunkt der Migration ist.
Für wen lohnt sich die Migration?
Eine Lakehouse Migration lohnt sich besonders, wenn:
- Ihr bestehendes Data Warehouse an Skalierungsgrenzen stößt oder der Hersteller-Support ausläuft
- Ihr Team parallel mehrere BI-Tools und Datensilos pflegen muss
- Sie ML- oder GenAI-Anwendungsfälle produktiv bringen wollen, für die das Altsystem nicht gebaut ist
- Ihre Lizenzkosten für das Legacy-System jährlich steigen, ohne dass neue Funktionen dazukommen
Eine Migration ist nicht die richtige Priorität, wenn:
- Ihr bestehendes System stabil läuft und keine absehbaren Skalierungsprobleme zeigt
- Sie noch keine klare Vorstellung haben, welche Analytics- oder KI-Anwendungsfälle die neue Plattform bedienen soll
Wie läuft die Zusammenarbeit mit Datasolut ab?
Schritt 1: Klarheit über Ihre Ausgangslage und den passenden Migrationsansatz
Wir bewerten gemeinsam Ihr Ausgangssystem, das gewünschte Modernisierungsniveau und die passende Reihenfolge (ETL first oder BI first), und leiten daraus eine realistische Aufwandsschätzung ab.
Schritt 2: Ein belastbarer Nachweis statt Big-Bang-Migration
Bevor die gesamte Migration skaliert wird, validieren wir den gewählten Ansatz anhand einer repräsentativen Stichprobe. Dies geschieht als Proof of Concept, der die technische Machbarkeit zeigt. Dies kann bei uns in der Regel innerhalb einer Festpreisvereinbarung erfolgen. Anschließend kann ein Erstentwurf erfolgen, der bereits einen funktionsfähigen Ausschnitt der neuen Plattform liefert.
Schritt 3: Skalierung mit Ihrem eigenen Entwicklerteam
Nach erfolgreichem Nachweis skalieren wir die Migration auf die vollständige Systemlandschaft und schulen Ihr Team, sodass es die Plattform zunehmend selbstständig weiterentwickeln kann, mit unserem Framework als Werkzeug, ohne Sie dabei dauerhaft an uns zu binden.
Machen Sie Databricks zu Ihrem Wettbewerbsvorteil
Mit unserer Databricks-Beratung entwickeln Sie eine skalierbare Architektur, realisieren produktive Use Cases und befähigen Ihr Team nachhaltig.
Fazit: Warum Sie mit uns migrieren sollten
Wir kombinieren klassische Migrationsberatung mit einem eigenen KI-gestützten Migrationsansatz, der die Übersetzungsarbeit an Legacy-Code deutlich beschleunigt, ohne dass Business-Logik oder Historisierung verloren geht. Anders als reine Tool-Anbieter begleiten wir Projekte zusätzlich von der ersten Bestandsaufnahme bis zur produktiven Plattform und schulen Ihr Team, statt eine dauerhafte Abhängigkeit aufzubauen.
Die meisten Lakehouse-Migrationen scheitern nicht an der Zielarchitektur, sondern an der falschen Wahl von Ansatz und Reihenfolge für die eigene Ausgangslage. Wer zuerst klärt, welches Szenario zutrifft, welcher Migrationsansatz passt und in welcher Reihenfolge migriert werden soll, spart sich später teure Kurskorrekturen mitten im Projekt. Wenn Sie gerade evaluieren, welcher Weg für Ihr Unternehmen der richtige ist, ist ein kleiner Nachweis in Form eines Proof of Concept der beste erste Schritt, nicht ein monatelanges Konzeptpapier.
Ihr nächster Schritt mit uns!
Databricks ist eine der leistungsfähigsten Plattformen für Daten und KI – aber ihr volles Potenzial entfaltet sich erst, wenn Ihr Team sie wirklich beherrscht. Lassen Sie uns gemeinsam schauen, welche Schulungspakete zu Ihrer Ausgangssituation passen.
Im kostenlosen Erstgespräch klären wir:
- Welche Rollen und Teams von welchem Paket am meisten profitieren
- Ob und wie wir Inhalte auf Ihre Datenarchitektur und Use Cases anpassen
- Wie ein realistischer Zeitplan und die nächsten Schritte aussehen
Häufig gestellte Fragen zur Databricks Migration
Lift & Shift übernimmt bestehende Strukturen weitgehend unverändert auf der neuen Plattform und nutzt dabei automatisierte Konvertierungstools (z.B. Lakebridge). Das ist der schnellste Weg ein Altsystem abzulösen. Eine vollständige Neuentwicklung baut das Datenmodell dagegen von Grund auf neu und schafft damit Raum für neue Anwendungsfälle wie Machine-Learning-Szenarien, braucht dafür aber deutlich mehr Zeit und trägt ein höheres Projektrisiko. In der Praxis empfehlen wir meist einen Hybrid-Ansatz: Schnell migrieren, die Architektur aber von Anfang an so anlegen, dass neue Use Cases später ergänzt werden können, ohne erneut das gesamte Fundament anzufassen.
Das hängt vor allem davon ab, wie wichtig sichtbarer Fortschritt für Ihre Stakeholder ist. Ingestion/ETL first liefert ein saubereres technisches Fundament, allerdings sehen Fachbereiche lange keinen greifbaren Nutzen, was die Akzeptanz im Projekt bremsen kann. BI first macht den Nutzen für Fachbereiche schneller sichtbar, weil vertraute Reports früh auf der neuen Plattform laufen, erfordert aber striktes Management mehrerer parallel laufender Schichten. Wenn interne Überzeugungsarbeit eine große Rolle spielt, würden wir zu BI first raten, wenn technische Sauberkeit klar Priorität hat, zu Ingestion/ETL first.
Das hängt stark vom gewählten Ansatz und der Komplexität der bestehenden Systeme ab, klassisch reicht die Spanne von wenigen Wochen bei kleinen Lift-&-Shift-Projekten bis zu über einem Jahr bei umfassenden Neuentwicklungen mit vielen Altsystemen. Mit unserem KI-gestützten Migrationsansatz lässt sich vor allem die Übersetzungs- und Testphase für Legacy-Code in unseren Projekten um bis zu 70% verkürzen. Der verbleibende Zeitaufwand entfällt dann größtenteils auf Architekturentscheidungen, Review und Abstimmung mit Fachbereichen, nicht mehr auf die eigentliche Code-Übersetzung.
In der Praxis treffen viele Unternehmen genau diese Situation an: Ein Legacy-DWH, ein ETL-Tool und eine gewachsene BI-Landschaft gleichzeitig. Statt alles in einem Projekt zu vermischen, empfehlen wir, die Szenarien getrennt zu betrachten und nacheinander oder parallel mit jeweils eigenem Zeitplan anzugehen, da jedes Szenario andere technische Herausforderungen mit sich bringt. Die Wahl des Startpunkts richtet sich dabei meist danach, welches System am akutesten Schmerzen bereitet, sei es durch auslaufenden Support, Kosten oder Skalierungsgrenzen.
