Data Warehouse Migration zu Microsoft Fabric: Vom Lift & Shift zur tragfähigen Architektur

Früher gab es Analytics in Azure und es gab Power BI, heute gibt es Microsoft Fabric. Die Einführung von Fabric bezeichnete Satya Nadella als „perhaps the biggest launch of a data product since SQL Server“. Diese Einordnung ist kein Marketing, sie beschreibt eine strategische Verschiebung. In Azure Analytics passiert wenig Neues, während Fabric kontinuierlich ausgebaut wird. Die Richtung ist klar, auch ohne offizielles End-of-Life. Wer 2026 ein neues Analytics-Projekt im Microsoft-Stack startet, wird kaum noch zu Synapse oder Data Factory greifen.

Der naheliegende nächste Gedanke ist simpel: bestehende SSIS-Pakete übernehmen und in Fabric ausführen. Die offizielle Dokumentation unterstützt genau diesen Weg. Ein dtsx-File wird bereitgestellt, über eine Pipeline aufgerufen, Parameter werden übergeben, fertig. Auf dem Papier wirkt das wie ein sauberer Lift & Shift. Unmittelbar lauffähig ist eine solche Migration meist nicht: Verbindungen müssen neu konfiguriert werden, Credentials und Secrets sauber in Fabric integriert werden, Parameterübergaben funktionieren oft anders als im ursprünglichen SSIS-Kontext. Viele Pakete greifen implizit auf Umgebungen zu, die so in Fabric nicht existieren. Spätestens hier wird aus einem gedachten Lift & Shift ein faktisches Replatforming.

Selbst wenn die Ausführung stabil läuft, bleibt ein strukturelles Problem bestehen. Die Logik der Datenintegration bleibt in SSIS gekapselt, außerhalb der eigentlichen Fabric-Welt. Monitoring, Skalierung und Weiterentwicklung folgen anderen Mechaniken als die restliche Plattform. Der Compute-Verbrauch orientiert sich nicht an den nativen Verarbeitungspfaden, sondern an einer emulierten Laufzeitumgebung. Das funktioniert technisch und lässt sich betreiben. Es entsteht jedoch kein integrierter Datenstack, sondern eine isolierte Schicht, die langfristig schwer wartbar ist und die Vorteile von Fabric nur begrenzt nutzt.

Wer sich Fabric zum ersten Mal anschaut, landet schnell bei der Unterscheidung zwischen Lakehouse und Warehouse. Das wirkt wie eine klassische Toolentscheidung, ähnlich wie früher zwischen verschiedenen Datenbanktypen. In der Praxis ist diese Trennung weniger relevant als sie zunächst scheint. Beide Konzepte greifen auf denselben Storage in OneLake zu, nutzen dieselben Datenformate und folgen denselben technischen Prinzipien. Der Unterschied liegt vor allem in der Art, wie Anwender damit arbeiten. Das Warehouse bietet eine vertraute SQL-Sicht, das Lakehouse eine stärker engineering-orientierte Umgebung. Im Kern bleibt es jedoch dasselbe System.

Diese Perspektive hat direkte Auswirkungen auf die Gestaltung der Datenverarbeitung. Prozesse sollten sich an der zugrunde liegenden Technologie orientieren. In Fabric haben sich Lakehouses in Kombination mit Notebooks als Best Practice etabliert. Das Notebook wird dabei zum zentralen Ort für technische und fachliche Transformationen. Große Rohdatenmengen werden typischerweise über PySpark verarbeitet, fachliche Logik lässt sich direkt in Spark SQL formulieren. Beide Ansätze arbeiten auf denselben Dataframe-Strukturen und lassen sich flexibel kombinieren. So kann beispielsweise eine technische Transformation wie eine Entpivotisierung effizient in PySpark umgesetzt werden, während die anschließende fachliche Logik wieder in SQL beschrieben wird. Ebenso lassen sich Daten direkt im Verarbeitungsschritt anreichern, etwa durch den Einsatz von Python-Bibliotheken, um externe Informationen einzubinden oder zusätzliche Attribute zu berechnen.

Was früher in verschachtelten Stored Procedures oder dynamischem SQL umgesetzt wurde, lässt sich so oft deutlich klarer strukturieren. Steuerlogik, Iterationen oder parametrisierte Abläufe können direkt im Notebook formuliert werden, ohne komplexe SQL-Konstrukte aufzubauen. Genau an dieser Stelle zeigt sich der Unterschied zur klassischen Welt. Die fachliche Logik bleibt, ihre technische Umsetzung verändert sich grundlegend.

Diese Veränderung betrifft jedoch nicht jede Ebene gleichermaßen. Ein Prinzip bleibt stabil: die Verarbeitung der Daten im Schichtenmodell. Sowohl klassische Data Warehouses als auch moderne Lakehouse-Architekturen folgen einer ähnlichen Logik. Rohdaten werden aufgenommen, bereinigt und angereichert, anschließend in eine fachliche Sicht überführt. In Fabric lässt sich dieses Muster weiterhin sauber abbilden, unabhängig davon, ob einzelne Teile eher SQL-lastig oder stärker engineering-getrieben umgesetzt sind.

Für die Einordnung von Migrationsstrategien hilft ein Blick auf die bekannten 6R der Cloud Migration. Retain und Retire spielen in diesem Kontext kaum eine Rolle, da bestehende DWHs in der Regel weiter benötigt werden. Rehost, also klassisches Lift & Shift, ist technisch möglich, wie etwa über die Ausführung von SSIS-Paketen, wurde aber bereits als wenig tragfähig eingeordnet. Relevant bleiben damit zwei Strategien: Replatforming und Refactoring. Replatforming bedeutet, bestehende Logik mit möglichst wenigen Anpassungen in die neue Umgebung zu überführen. Refactoring geht einen Schritt weiter und passt die Logik aktiv an die neue technologische Grundlage an.

Ausgehend vom Schichtenmodell lässt sich für jede Schicht gezielt eine eigene Strategie definieren. Fachlich geprägte Transformationen, insbesondere in SQL, eignen sich häufig für Replatforming. Technische Integrationslogik in Raw und Cleaned erfordert dagegen meist ein Refactoring, da sich die zugrunde liegenden Verarbeitungskonzepte in Fabric grundlegend unterscheiden. Migration wird damit zu einer bewussten Kombination beider Ansätze entlang der Datenpipeline.

Ein typisches Beispiel für Replatforming ist die Übernahme bestehender SQL-Logik aus SSIS. Der eigentliche Kern vieler Dataflows liegt im Custom SQL innerhalb der Data Flow Tasks. Diese Logik lässt sich oft mit überschaubaren Anpassungen in Spark SQL überführen und in einem Notebook weiterverwenden. Änderungen beschränken sich auf Details wie unterschiedliche Funktionen oder Datentypkonvertierungen. Die umgebende Steuerungslogik, etwa für Ladezeitpunkte, Inkrementbestimmung oder Metadatenzugriffe, wird aus SSIS herausgelöst und als Funktionen im Notebook implementiert. Auch Logging oder Surrogate-Key-Lookups wandern in diesen Kontext. Die fachliche Transformation bleibt weitgehend erhalten, die technische Einbettung verändert sich.

Refactoring zeigt sich vor allem in der Integrationsschicht. Klassische Stored Procedures, etwa für Merge-Operationen mit SCD2-Historisierung, lassen sich nicht sinnvoll übertragen. Stattdessen werden solche Prozesse in PySpark neu aufgebaut. Eine generische Funktion übernimmt die Logik und wird über verschiedene Tabellen hinweg angewendet, gesteuert über Parameter oder Metadaten. Das reduziert die Anzahl der Wartungspunkte und führt zu klarerem Code, erfordert jedoch eine vollständige Neuentwicklung.

Die Migration eines bestehenden Data Warehouses nach Fabric ist kein einfacher Toolwechsel. Technisch ist vieles möglich, wie die Ausführung bestehender SSIS-Pakete zeigt. Nachhaltig tragfähig sind diese Ansätze selten. Die eigentliche Herausforderung liegt darin, bestehende Logik an eine veränderte technologische Grundlage anzupassen.

Das Schichtenmodell schafft dafür einen praktikablen Rahmen. Es ermöglicht, Migration differenziert zu denken und pro Schicht die passende Strategie zu wählen. Fachliche Transformationen lassen sich häufig mit überschaubarem Aufwand in die neue Umgebung überführen. In der Integrationsschicht führt an einem Refactoring meist kein Weg vorbei, weil sich die Art der Datenverarbeitung grundlegend verändert hat.

Ein sinnvoller Einstieg orientiert sich daher am Business Value. Die fachliche Schicht wird früh nutzbar gemacht, während die technische Basis schrittweise nachgezogen wird. So entsteht kein Big Bang, sondern ein kontrollierter Übergang, der Mehrwert liefert und gleichzeitig die Grundlage für eine tragfähige Architektur schafft.