Vom Data Warehouse zum Lakehouse: Wann sich die Migration lohnt und wie sie gelingt
Die Kernaussagen auf einen Blick.
- Eine Lakehouse-Migration verlagert Daten, Datenmodelle, Pipelines und Auswertungen aus einem klassischen Data Warehouse in eine offene Lakehouse-Architektur.
- Ob sich die Migration lohnt, hängt vom konkreten Anlass ab: steigende Lizenz- und Compute-Kosten, ML- und Streaming-Anforderungen oder Datenvielfalt jenseits des relationalen Modells.
- Vor dem Start sollten drei Punkte festgelegt werden: Workload-Inventar, Zielbild und Abschalt-Kriterien für den Parallelbetrieb.
- Empfehlenswert ist eine schrittweise Migration in klar abgegrenzten Wellen, beginnend mit einem abgegrenzten Pilot-Workload. Eine bestehende Strecke sollte erst abgeschaltet werden, wenn die Ergebnisse auf der neuen Plattform fachlich und technisch validiert wurden.
Inhaltsverzeichnis
Wenn ein auslaufender Vertrag die Plattformentscheidung auslöst
Die bestehende Warehouse-Appliance wird seit zwölf Jahren zuverlässig im eigenen Rechenzentrum betrieben. Der Wartungsvertrag endet in 18 Monaten, die Verlängerung wird spürbar teurer, und der Hersteller empfiehlt den Wechsel auf sein eigenes Cloud-Angebot. Auf dem System liegen rund 2.000 gewachsene SQL-Jobs, eine BI-Landschaft mit Hunderten Reports und zwei Machine-Learning-Teams, die ihre Trainingsdaten über nächtliche Exporte aus dem Warehouse beziehen, da das System für diese Workloads nur eingeschränkt geeignet ist.
Eine solche Situation tritt häufig in historisch gewachsenen Data-Warehouse-Landschaften auf. Auslöser sind häufig ein auslaufender Vertrag, das Ende eines Hardware-Lebenszyklus oder neue KI-Anforderungen. In diesem Zusammenhang wird dann oft eine Lakehouse-Architektur als mögliches Zielbild betrachtet, und mit ihr stellt sich eine Reihe von Fragen, die sich nicht allein durch Herstellerpräsentationen beantworten lassen:
Lohnt sich der Umzug, obwohl das DWH zuverlässig läuft? Wie werden bestehende SQL-Prozesse und die darauf aufbauenden Berichte migriert? Wie lange ist ein Parallelbetrieb erforderlich und welche zusätzlichen Kosten entstehen dadurch? Woran erkennen wir, dass wir das alte System abschalten können?
Ob eine Lakehouse-Migration sinnvoll ist, hängt vom bestehenden und geplanten Workload-Profil ab. Der Erfolg der Migration hängt wesentlich vom gewählten Vorgehensmodell ab.
Was ist eine Lakehouse-Migration?
Bei einer Lakehouse-Migration werden Daten, Prozesse und Auswertungen eines klassischen Data Warehouse in eine Lakehouse-Architektur überführt, auch Data Lakehouse genannt. Offene Tabellenformate wie Delta Lake oder Apache Iceberg ergänzen den günstigen Objektspeicher dabei um Transaktionssicherheit (ACID), Schemaverwaltung und SQL-Unterstützung für BI-Workloads. Relevant wird die Migration, wenn das bestehende Warehouse Anforderungen wie Machine Learning, Streaming oder unstrukturierte Daten nur mit zusätzlichen Systemen unterstützt. Datenqualität, Modellierung und Governance bleiben dabei eigene Aufgaben. Diese Aufgaben werden durch den Plattformwechsel nicht automatisch gelöst.
Das grundlegende Architekturprinzip lautet: Das Lakehouse verbindet die kostengünstige, offene Speicherung eines Data Lake mit den Transaktions- und Governance-Funktionen eines Data Warehouse. Dadurch können BI, Data Engineering und Machine Learning auf einen gemeinsamen Datenbestand zugreifen, und zusätzliche Export- und Kopierprozesse können reduziert werden.
Für die Migrations-Entscheidung folgt daraus eine wichtige Abgrenzung: Eine Lakehouse-Migration umfasst deutlich mehr als das reine Verschieben von Daten. Die eigentliche Datenübertragung ist häufig weniger aufwendig als die Migration der umgebenden Logik und Prozesse. Der größere Aufwand entsteht bei Pipelines, SQL-Logik, Reporting, Betrieb und organisatorischen Zuständigkeiten. Wie sich Data Warehouse, Data Lake und Lakehouse als Architekturen zueinander verhalten, zeigen wir im Überblick zum Lakehouse.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Warum Unternehmen ihr Data Warehouse in Frage stellen
Für eine nachvollziehbare Migrationsentscheidung gibt es mehrere typische Auslöser. Vier davon sind besonders häufig relevant.
Die Kostenentwicklung wird zunehmend unwirtschaftlich. Bei proprietären Warehouse-Plattformen sind Lizenz-, Rechen- und Speicherkosten häufig eng miteinander verbunden. Mit wachsendem Datenvolumen steigen die Kosten, auch wenn der fachliche Nutzen nicht im gleichen Maß zunimmt. Die Bindung an proprietäre Formate verschärft das: Liegt der Bestand in einem Format, das nur der Hersteller-Stack lesen kann, sinkt bei Vertragsverlängerungen die technische und wirtschaftliche Flexibilität. Ein bevorstehendes Vertrags- oder Hardware-Ende macht beides sichtbar und schafft häufig den notwendigen Entscheidungszeitpunkt und Budgetrahmen.
Machine-Learning- und KI-Projekte beziehen ihre Daten über zusätzliche Exportprozesse. Ein Warehouse ist für strukturierte Abfragen gebaut, für das Training von Modellen brauchen Teams aber große, rohe Datenmengen in offenen Formaten. Dadurch entstehen zusätzliche Datenpipelines außerhalb der zentralen Plattform. Diese Datenbestände werden häufig mehrfach kopiert, separat gepflegt und unterliegen nicht vollständig der zentralen Governance. Mit jedem weiteren KI-Anwendungsfall wächst diese parallele Datenlandschaft.
Echtzeitanforderungen lassen sich mit reinen Batch-Prozessen nur eingeschränkt abdecken. Nächtliche Ladeläufe reichen, solange Berichte am Morgen genügen. Wenn operative Bereiche wie Logistik und Produktion oder digitale Produkte kontinuierlich aktuelle Daten benötigen, reicht ein ausschließlich nächtliches Lademodell häufig nicht mehr aus, und Streaming-Workloads brauchen eine Architektur, die kontinuierliche Verarbeitung vorsieht.
Die wachsende Datenvielfalt lässt sich nur mit hohem Aufwand in ein rein relationales Modell überführen. Sensordaten, Logs, Dokumente, Bilder und Events lassen sich in ein Warehouse nur mit erheblichem Umformungsaufwand laden. Stattdessen werden sie häufig in einer separaten Rohdatenablage gespeichert. Dadurch entsteht eine zweite Datenlandschaft mit zusätzlichem Betriebsaufwand und uneinheitlicher Governance.
Wenn keiner dieser Auslöser vorliegt, fehlt häufig ein belastbarer Business Case für die Migration. Ein Warehouse, das stabile BI-Workloads zu vertretbaren Kosten bedient, ist eine funktionierende Plattform und sollte nicht allein aus technologischen Gründen ersetzt werden. Welche Stärken das klassische Modell behält und wo seine Architektur heute steht, ordnen wir im Überblick zum Data Warehouse ein.
Was eine Lakehouse-Migration wirklich umfasst
Der Umfang einer Data-Warehouse-Migration wird häufig unterschätzt, da zunächst meist nur die Datenübertragung betrachtet wird. Eine gewachsene Warehouse-Landschaft umfasst mindestens fünf zu migrierende Bereiche. Für jeden Bereich muss entschieden werden, ob er unverändert übernommen, angepasst oder stillgelegt wird.
Das Datenmodell. Star-Schema (Sternschema), Snowflake-Modelle, Historisierungslogik und Hilfstabellen sind über Jahre gewachsen. Bestehende Modelle können übernommen werden, sollten jedoch hinsichtlich ihrer fachlichen und technischen Eignung für die Zielarchitektur geprüft werden: Einige Tabellen und Hilfsstrukturen wurden möglicherweise nur aufgrund technischer Einschränkungen der bisherigen Plattform eingeführt.
Die ETL- und ELT-Strecken. Ladeprozesse und ihr Scheduling steuern die Abhängigkeiten und Abläufe der gesamten Datenverarbeitung. Hier entscheidet sich je Strecke, ob sie unverändert nachgebaut, neu geschrieben oder stillgelegt wird, denn in historisch gewachsenen Landschaften werden häufig Prozesse betrieben, die keine aktiven Nutzer oder Folgesysteme mehr haben.
Die SQL-Workloads. Abfragen, Views und Stored Procedures (im Warehouse hinterlegte Verarbeitungslogik) enthalten häufig anbieterspezifische SQL-Syntax und Plattformlogik. Automatisierte Konverter übersetzen einen großen Teil dieses Bestands: Databricks-Ingenieure beschreiben in einem dokumentierten dbt-Migrationsprojekt, dass rund zwei Drittel des Bestands-Codes direkt übersetzbar waren und sich der Rest auf Anpassungen und manuelle Nacharbeit verteilte. Manuelle Anpassungen sind vor allem bei proprietären Funktionen und abweichenden Plattformkonzepten erforderlich, etwa sitzungsübergreifenden Transaktionen oder erzwungenen Eindeutigkeits-Regeln. Die fachliche und technische Validierung verursacht häufig mehr Aufwand als die reine Codeübersetzung.
Die BI- und Reporting-Schicht. Kennzahlendefinitionen, Semantik und Berechtigungen hängen an der alten Plattform. Reports, die auf den neuen Bestand zeigen, müssen fachlich dieselben Ergebnisse liefern wie zuvor, damit die Akzeptanz der Fachbereiche für das gesamte Programm erhalten bleibt.
Der Betrieb. Monitoring, Alarmierung, SLAs, Kostensteuerung und Zuständigkeiten müssen für die neue Plattform neu aufgesetzt werden. Dabei muss auch bewertet werden, ob die bestehenden Teams bereits über die notwendigen Betriebs- und Cloud-Kompetenzen verfügen.
Auch Herstellerdokumentationen betrachten neben den Daten weitere Migrationsbestandteile: Databricks nennt in seiner Dokumentation zum Umstieg vom Enterprise Data Warehouse neben der Datenmigration auch ETL-Jobs, Abfragen und Dashboards als Teile des Umstiegs, die nach der Daten- und Governance-Migration mit begrenzten Anpassungen übernommen werden können.
Auf der Zielseite entsteht der Bestand üblicherweise in Schichten. Wie Rohdaten über Bronze-, Silver- und Gold-Ebenen zu verbindlichen, abnahmefähigen Datenprodukten werden, führen wir im Überblick zur Medallion-Architektur aus. Welches offene Tabellenformat den Bestand trägt und welche Betriebsfolgen daran hängen, klären wir in den Überblicken zu Delta Lake und Apache Iceberg.
Bleiben, modernisieren oder migrieren?
Für die Weiterentwicklung der Plattform bestehen drei realistische Optionen. Eine Lakehouse-Migration ist dabei nicht automatisch die richtige Wahl. Sowohl der Weiterbetrieb der bestehenden Plattform als auch die Modernisierung zu einem Cloud Data Warehouse desselben Architektur-Typs können sinnvoll sein, wenn das Workload-Profil dazu passt.
| Situation | Naheliegender Pfad | Begründung |
|---|---|---|
| Stabile BI-Workloads, Kosten im Rahmen, keine ML- oder Streaming-Anforderungen absehbar | Bleiben | Eine stabile und wirtschaftliche Plattform sollte nur bei einem klaren fachlichen oder technischen Anlass ersetzt werden |
| On-Prem-Ende steht an, Workload-Profil bleibt klassisch relational | Cloud Data Warehouse (Modernisierung) | Gleiche Architektur auf neuer Infrastruktur, geringster Umbau-Aufwand |
| ML- und AI-Vorhaben wachsen neben dem bestehenden BI, Export-Strecken häufen sich | Lakehouse-Migration in Wellen | Eine gemeinsame Datenbasis kann zusätzliche Exporte und parallele Datenbestände reduzieren |
| Kostenkurve, Vertragsende und neue Workload-Typen treffen zusammen | Migration mit klarem Zielbild | Der Architekturwechsel löst mehrere Anlässe mit einem Programm |
| BI soll im Warehouse bleiben, ML braucht trotzdem offene Daten | Bewusster Zwei-Plattform-Betrieb | Doppelarchitektur als akzeptierte Übergangs- oder Dauerlösung mit klar verteilten Rollen |
Als Faustregel: Die Migration ist sinnvoll, wenn mindestens einer der vier Anlässe belegt ist und das Zielbild mehr leisten soll als das alte System auf neuer Infrastruktur. Der Verbleib passt besser, wenn die Plattform ihre heutigen Aufgaben wirtschaftlich erfüllt und kein neuer Workload-Typ ansteht.
Ein dauerhafter Betrieb von Warehouse und Lakehouse sollte dabei bewusst geplant und begründet werden. Mit klarer Rollenverteilung kann eine solche Architektur langfristig funktionieren. Als ungeplanter Dauerzustand einer steckengebliebenen Migration verursacht er jedoch doppelte Betriebs-, Lizenz- und Governance-Aufwände: zwei Plattformen, zwei Betriebsmodelle, möglicherweise unterschiedliche Definitionen und Datenstände derselben Kennzahl.
Auch die Anbieter-Seite beschreibt das Ziel inzwischen als Vereinheitlichung verschiedener Workloads: Microsoft Learn versteht den Umstieg für Azure Databricks nicht als Abschaffung des Data Warehousing, sondern als Vereinheitlichung des Datenökosystems, in dem die Warehouse-Aufgaben auf der neuen Architektur weiterlaufen. Wie sich Warehouse, Data Lake und Lakehouse grundsätzlich unterscheiden und welches Modell zu welchem Workload-Profil passt, klären wir im Vergleich Lakehouse vs. Data Warehouse vs. Data Lake.
Big Bang oder Wellen?
Nach der grundsätzlichen Entscheidung muss das geeignete Migrationsvorgehen festgelegt werden. Eine mögliche Strategie ist die Big-Bang-Migration, die vollständige Umstellung zu einem festen Stichtag: alles vorbereiten, umschalten, das Altsystem abschalten. Alternativ kann die neue Plattform nach dem Strangler-Muster schrittweise einzelne Workloads übernehmen, bis das alte System leer ist. Auch der deutsche Markt strukturiert die Frage entlang dieser Achsen: datasolut unterscheidet drei Migrationsstrategien von Lift and Shift über Modernisierung bis zum hybriden Vorgehen.
Big Bang wählen, wenn
- Die Umgebung ist klein und gut dokumentiert
- Die Anzahl der Strecken und Reports ist überschaubar
- Ein fester Umschalt-Stichtag ist organisatorisch gewollt und abgesichert
- Nachträgliche Anpassungen nach dem Stichtag sind vertretbar
Wellen-Modell wählen, wenn
- Die Landschaft umfasst Tausende Strecken oder Reports
- Risiko soll auf mehrere validierbare Etappen verteilt werden, statt sich am Umschaltzeitpunkt zu konzentrieren
- Jede Etappe soll vor dem nächsten Schritt gegen das Altsystem abgeglichen werden
- Team und Prozess sollen sich schrittweise bewähren, bevor der BI-Kern folgt
Inventar und Assessment
Ergebnis: Workload-Inventar mit Tabellen, Strecken, Reports, Nutzern und Abhängigkeiten. Gate: Priorisierung steht, ungenutzte Strecken sind aussortiert.
Zielbild
Ergebnis: Zielarchitektur mit Schichtenmodell, Format- und Governance-Entscheidung. Gate: Das Zielbild benennt, was das Lakehouse leisten soll, das das DWH heute verfehlt.
Pilot-Welle
Ergebnis: Ein abgegrenzter Workload läuft produktiv auf der neuen Plattform. Gate: Zahlen-Abgleich gegen das Altsystem über einen vollen Berichtszyklus.
Migrations-Wellen
Ergebnis: Workload-Gruppen ziehen nach Priorität um. Gate: Je Welle Abgleich, Abnahme durch die Nutzer, Abschalt-Termin der Alt-Strecke.
Parallelbetrieb und Abgleich
Ergebnis: Alt und Neu liefern für umgezogene Workloads nachweislich dieselben Zahlen. Gate: Dokumentierte Abweichungen sind erklärt oder behoben.
Abschaltung
Ergebnis: Altsystem workload-weise stillgelegt, Verträge und Hardware beendet. Gate: Keine produktiven Konsumenten mehr auf dem Altsystem.
Innerhalb der Wellen gilt je Workload die zweite Vorgehens-Entscheidung: Stabile und gut verstandene Prozesse können möglichst unverändert übernommen werden (Lift and Shift), Prozesse mit bekannten Schwächen oder neuen Anforderungen sollten gezielt neu gestaltet werden. Beides pauschal anzuwenden wäre ein Fehler: Ein vollständiger Neuaufbau aller Prozesse erhöht Laufzeit, Kosten und Projektrisiko erheblich. Eine unveränderte Übernahme aller Prozesse überträgt dagegen bestehende technische und fachliche Altlasten auf die neue Plattform.
In der Praxis wird daher meist je Workload zwischen Übernahme und Neuentwicklung entschieden. Diese Mischung verlangt ein sauberes Inventar als Grundlage und ein Abwägen entlang von drei Achsen: Zeit bis zum ersten Nutzen, Risiko je Umstellung und der Anteil des Zielbilds, der tatsächlich umgesetzt wird. Ein schneller Lift and Shift lässt ML- und Streaming-Nutzen zunächst liegen; eine vollständige Modernisierung realisiert ihn, dehnt aber Laufzeit und Budget. Welche Kombination geeignet ist, hängt neben dem Workload-Profil an Team-Reife, Budgetfenster und Risikotoleranz der Organisation.
Übertragen auf das Eingangs-Szenario mit der Appliance: Als erste Welle eignen sich häufig neue ML- und Streaming-Workloads sowie bestehende Exportprozesse, also genau die Strecken, die heute über Export-Umwege laufen. Sie bieten häufig einen schnell sichtbaren Nutzen, ohne das bestehende Reporting unmittelbar zu gefährden. Der BI-Kern folgt in späteren Wellen, wenn Zielplattform, Team und Abgleich-Prozess sich bewährt haben.
Woran Migrationen hängen bleiben
Migrationsprogramme geraten häufig aus denselben Gründen ins Stocken. Vier davon lassen sich planbar entschärfen, wenn sie von Anfang an adressiert werden.
Für den Parallelbetrieb werden keine verbindlichen Abschalttermine festgelegt. Beide Systeme laufen, beide kosten, und weil niemand Abschalt-Kriterien definiert hat, bleibt das Altsystem länger als geplant produktiv. Die wirksamste Gegenmaßnahme ist eine verbindliche Abschaltplanung pro Migrationswelle: Jede Welle bekommt ihren Abschalt-Termin und ihre Abnahme-Kriterien, bevor sie startet.
Die alte und die neue Plattform liefern abweichende Ergebnisse. SQL-Dialekte runden anders, Zeitzonen- und Kalenderlogik weichen ab, alte Strecken enthalten undokumentierte Sonderfälle. Nicht erklärte Abweichungen im Reporting verringern die Akzeptanz der neuen Plattform. Ein systematischer Zahlen-Abgleich je Welle, über mindestens einen vollständigen fachlichen Berichtszeitraum, gehört deshalb fest in den Migrationsplan.
Die bestehende Warehouse-Architektur wird unverändert auf der neuen Plattform reproduziert. Ohne Zielbild übernimmt das Programm die bestehende Struktur eins zu eins und liefert am Ende eine technisch neue Plattform mit weitgehend unveränderten Einschränkungen. Die erhofften ML-, Streaming- und Kostenvorteile bleiben aus, weil nicht festgelegt wurde, welche Prozesse und Workloads durch die neue Architektur tatsächlich verbessert werden sollen.
Dem Team fehlen zunächst Teile der notwendigen Kenntnisse für den Betrieb der Zielplattform. Jahrelang SQL-zentriert arbeitende Teams treffen auf offene Formate, Pipelines als Code und Cloud-Kostensteuerung. Der Kompetenzaufbau ist möglich, muss jedoch als eigenes Arbeitspaket eingeplant werden: Schulung an den eigenen Workloads, gemeinsames Arbeiten in den ersten Wellen und ein realistischer Blick darauf, welche Rollen extern besetzt werden müssen, bis das interne Team den Betrieb eigenständig übernehmen kann.
Von der Konzept- zur Execution-Ebene
Die grundlegenden Entscheidungen zu Anlass, Zielbild und Vorgehen können zunächst unabhängig von einem Anbieter getroffen werden: Anlässe, Migrations-Gegenstand, Entscheidungsrahmen und Vorgehensmodell gelten für jede Plattform, die am Ende den Zuschlag bekommt. Erst wenn Zielbild und Wellen-Plan stehen, sollte die konkrete Zielplattform ausgewählt werden: Welche Plattform trägt das Zielbild, und wie sieht die Strecke aus dem eigenen Quellsystem dorthin aus?
Die technische Umsetzung hängt wesentlich vom bestehenden Quellsystem ab. Eine Teradata- oder Netezza-Appliance erfordert andere Ansätze für SQL-Übersetzung, Datenübertragung und Validierung als ein Hadoop-Cluster, ein Oracle- oder SQL-Server-Bestand, ein Synapse- oder Redshift-Setup oder ein bestehendes Snowflake-Konto. Auch das Tooling für Code-Übersetzung, Daten-Transfer und Validierung unterscheidet sich je Strecke deutlich. Auf der Zielseite konkurrieren Plattformen wie Databricks, Snowflake, Microsoft Fabric oder BigQuery um das Zielbild; die Produktauswahl sollte erst auf Grundlage des definierten Zielbilds erfolgen, und die Bewertungskriterien sollten sich direkt aus dessen fachlichen und technischen Anforderungen ableiten.
Was die Migration nicht löst
Eine gut geplante Migration kann eine gemeinsame und offenere Datenbasis für BI, Engineering und ML schaffen. Mehrere fachliche und organisatorische Probleme bleiben jedoch unabhängig vom Plattformwechsel bestehen.
Fachliche Datenqualität
Eine Migration verbessert die Datenqualität nicht automatisch. Fehler aus den Quellsystemen werden übernommen, wenn sie nicht gezielt behandelt werden. Qualitätsregeln, Prüfungen und Verantwortlichkeiten müssen eigenständig aufgebaut werden, idealerweise als Teil des Zielbilds.
Governance
Governance entsteht nicht allein durch die neue Plattform. Rollenbasiertes Zugriffsmodell, Ownership, Katalog, Lineage und Audit-Nachweise müssen neu entschieden werden. Die Migration bietet dafür aber einen geeigneten Zeitpunkt.
Modellierungsprobleme
Unklare Kennzahlendefinitionen, redundante Hilfstabellen und historisch gewachsene Sonderlogik werden ohne gezielte Bereinigung mit migriert, wenn niemand sie im Inventar markiert und im Zielbild bereinigt.
Gesamtkosten
Eine Lakehouse-Plattform führt nicht automatisch zu geringeren Gesamtkosten. Niedrige Speicherkosten können durch unkontrollierte Compute-Nutzung überkompensiert werden, wenn Dimensionierung, Auto-Abschaltung und Verbrauchstransparenz fehlen.
Organisatorische Adoption
Organisatorische Veränderungen brauchen häufig mehr Zeit als die technische Datenmigration. Ohne eigene Aufmerksamkeit für Vertrauen, neue Routinen und neue Abläufe wird die Plattform technisch bereitgestellt, aber nur eingeschränkt genutzt.
Diese Grenzen sprechen nicht gegen die Migration. Sie zeigen, welche Aufgaben parallel zur Migration bearbeitet werden müssen: Das Programm selbst leistet den Architektur-Teil der Modernisierung; Qualitäts-, Governance- und Organisationsarbeit laufen daneben und verdienen eigene Verantwortliche.
Je früher Governance, Qualität, Kostensteuerung und Adoption im Programm eingeplant werden, desto geringer die Gefahr, dass die Migration als reines Infrastruktur-Projekt geführt wird und ihre Anlässe am Ende unbeantwortet lässt.
Fazit
Eine Lakehouse-Migration lohnt sich, wenn Kosten, ML- und KI-Anforderungen, Echtzeitbedarf oder Datenvielfalt einen klaren Anlass belegen, nicht als reiner Technologiewechsel ohne Bedarf.
Eine Migration vom Data Warehouse zum Lakehouse ist sinnvoll, wenn sich aus den bestehenden oder geplanten Workloads ein klarer Bedarf ergibt: steigende Kosten im Zusammenhang mit einem auslaufenden Vertrag, Machine-Learning- und KI-Anwendungen, die heute auf separate Datenexporte angewiesen sind, Echtzeitanforderungen, die mit den bestehenden Batch-Prozessen nicht ausreichend bedient werden können, oder Datenformate und Quellen, die sich nur mit hohem Aufwand in das bestehende relationale Modell integrieren lassen.
Besonders sinnvoll ist die Migration in Situationen, in denen mehrere dieser Symptome zusammentreffen: eine Appliance vor dem Vertragsende, eine wachsende Zahl zusätzlicher Export- und Kopierprozesse, Fachbereiche mit Echtzeit-Erwartungen und ein hoher laufender Aufwand für den parallelen Betrieb mehrerer Datenplattformen.
Ohne einen konkreten Auslöser kann die Migration zurückgestellt werden. Ein stabil laufendes, wirtschaftliches Warehouse rechtfertigt den Programmaufwand erst, wenn ein echter Anlass dazukommt, und bis dahin kann ein klar geregelter Parallelbetrieb die wirtschaftlichere und risikoärmere Lösung sein.
Als erster Schritt sollte ein vollständiges Inventar der Workloads, Abhängigkeiten und Konsumenten erstellt werden. Das Zielbild sollte aus wenigen klaren und messbaren Anforderungen abgeleitet werden. Die erste Migrationswelle sollte einen abgegrenzten Workload mit überschaubarem Risiko und kurzfristig messbarem Nutzen umfassen, idealerweise so gewählt, dass sie innerhalb eines Quartals produktiv wird. Ein verbindlicher und erreichter Abschalttermin für die erste Altstrecke ist ein besserer Fortschrittsindikator als eine rein zeitbasierte Roadmap.
Lohnt sich die Migration zum Data Lakehouse?
- welche eurer Warehouse-Workloads echte Kandidaten für die ersten Migrations-Wellen sind
- welche Kosten-, Governance- und Betriebsrisiken vor dem Programmstart geprüft werden müssen
- welcher Migrationspfad zwischen Big Bang, Wellen-Modell und Zwei-Plattform-Betrieb für eure Situation trägt
FAQ
Eine Lakehouse-Migration ist der geplante Umzug von Daten, Datenmodellen, Pipelines, SQL-Workloads und Reporting aus einem klassischen Data Warehouse in eine Lakehouse-Architektur mit offenen Tabellenformaten auf Objektspeicher. Sie umfasst neben dem Datenbestand auch die Lade-Strecken, die BI-Semantik, die Berechtigungen und das Betriebsmodell der Plattform.
