Constantin, Pexon Consulting | 10 Min. Lesezeit | 29.07.2026
TL;DR
Die Synapse Fabric Datenmigration hat drei technische Baustellen: Daten von ADLS Gen2 nach OneLake, Dedicated SQL Pools ins Fabric Data Warehouse und Pipelines samt Spark-Workloads in Fabric Data Factory. Jede hat ihre Tücken, besonders die T-SQL-Unterschiede. Pexon setzt die Migration mit 30 Azure-Spezialisten technisch sauber um.
Die drei technischen Baustellen
Eine Synapse Fabric Datenmigration klingt nach einem Vorgang, sind aber drei verschiedene Aufgaben mit je eigener Logik. Wer sie in einen Topf wirft, unterschätzt den Aufwand. Die Datenschicht wandert von ADLS Gen2 nach OneLake, die relationale Schicht von den Dedicated SQL Pools ins Fabric Data Warehouse, und die Verarbeitung von Synapse Pipelines und Spark Pools in die Fabric-Werkzeuge. Warum der Umzug überhaupt ansteht und wie man ihn plant, behandeln wir separat (siehe Verwandte Themen).
Datenmigration: ADLS Gen2 zu OneLake
Der eleganteste Teil ist die Datenschicht, weil OneLake einen Trick beherrscht: Shortcuts. Statt Daten physisch aus ADLS Gen2 zu kopieren, verweist ein OneLake-Shortcut auf den bestehenden Speicher. Die Daten bleiben, wo sie sind, sind aber in Fabric verfügbar. Das spart Kopiervorgänge, Speicher und Zeit.
-- OneLake-Shortcut auf bestehenden ADLS-Gen2-Container (kein Kopieren)
-- angelegt im Lakehouse, Daten bleiben physisch in ADLS Gen2
CREATE SHORTCUT '/Files/rohdaten'
LOCATION 'https://<konto>.dfs.core.windows.net/<container>'
SUBPATH '/verkauf/2026';
-- danach direkt in Fabric abfragbar, ohne ETL-Umweg
Nicht alles läuft über Shortcuts. Wo Daten transformiert oder dauerhaft in OneLake liegen sollen, kommt ein echter Ladevorgang zum Einsatz. Die Datentypzuordnung ist hier der Punkt, an dem man genau hinschauen muss, weil Synapse und Fabric nicht bei jedem Typ identisch sind.
SQL-Pools ins Fabric Data Warehouse
Die härteste Nuss sind die Dedicated SQL Pools. Sie ziehen ins Fabric Data Warehouse um, das zwar T-SQL spricht, aber nicht denselben Funktionsumfang hat. Einige aus Synapse gewohnte Konstrukte fehlen oder verhalten sich anders, etwa bei bestimmten Indizes, Stored Procedures oder Verteilungsstrategien. Unsere klare Position: Diese T-SQL-Unterschiede sind der Grund, warum ein reines Skript-Kopieren nicht funktioniert. Jede Prozedur gehört geprüft.
Der pragmatische Weg ist, Strukturen und Logik mit Microsofts Migrationswerkzeugen zu übertragen und die Abweichungen gezielt nachzuarbeiten, statt auf einen fehlerfreien Automatismus zu hoffen. Ein produktionsnaher Testlauf deckt die Unterschiede auf, bevor sie im Betrieb auffallen.
Pipelines und Spark-Workloads
Synapse Pipelines wandern nach Fabric Data Factory, das konzeptionell verwandt ist, aber eigene Aktivitäten und Trigger hat. Viele Pipelines lassen sich weitgehend übernehmen, die spark-bezogenen Aktivitäten brauchen mehr Aufmerksamkeit. Spark Pools werden zu Fabric-Spark im Lakehouse-Kontext, was oft eine gute Gelegenheit ist, gewachsene Notebooks aufzuräumen.
Genau diese technische Umsetzung, von den ETL-Prozessen bis zu den Spark-Workloads, übernehmen wir im Rahmen unserer Data-Analytics- und Cloud-Consulting-Leistung. Wie das Ganze in eine AI-ready Datenplattform mündet, steht in den Verwandten Themen.
Häufig gestellte Fragen
Wie migriert man Daten von ADLS Gen2 nach OneLake?
Am elegantesten über OneLake-Shortcuts: Sie verweisen auf den bestehenden ADLS-Gen2-Speicher, ohne die Daten physisch zu kopieren. Die Daten sind damit in Fabric verfügbar, bleiben aber am ursprünglichen Ort. Nur wo transformiert oder dauerhaft in OneLake gespeichert werden soll, kommt ein echter Ladevorgang zum Einsatz.
Was ist bei den SQL-Pools die größte Hürde?
Die T-SQL-Unterschiede. Das Fabric Data Warehouse spricht T-SQL, hat aber nicht denselben Funktionsumfang wie die Synapse Dedicated SQL Pools. Bestimmte Indizes, Stored Procedures oder Verteilungsstrategien verhalten sich anders. Ein reines Skript-Kopieren funktioniert nicht, jede Prozedur gehört geprüft.
Lassen sich Synapse-Pipelines automatisch nach Fabric übernehmen?
Teilweise. Fabric Data Factory ist konzeptionell verwandt, viele Pipelines lassen sich weitgehend übernehmen. Die spark-bezogenen Aktivitäten und einige Trigger brauchen aber Nacharbeit. Ein Werkzeug nimmt Arbeit ab, ersetzt aber die Prüfung jeder Pipeline nicht.
Was kostet die technische Datenmigration nach Fabric?
Das hängt vom Volumen der Daten und der Zahl der SQL-Objekte und Pipelines ab. Shortcuts sparen bei der Datenschicht viel Aufwand, die SQL-Pool-Migration mit T-SQL-Prüfung ist der aufwändigere Teil. Ein Assessment macht den konkreten Aufwand vorab greifbar.
Bleiben die Daten während der Migration konsistent?
Ja, wenn man in Wellen und mit Testlauf arbeitet. OneLake-Shortcuts lassen die Quelldaten unangetastet, und ein produktionsnaher Pilot validiert die Ergebnisse, bevor produktiv umgeschaltet wird. So bleibt die Datenkonsistenz gewahrt, statt sie einem Big-Bang zu überlassen.
Nächster Schritt
Sie wollen Ihre Synapse-Daten, SQL-Pools und Pipelines technisch sauber nach Fabric bringen, ohne dass Datentyp- oder T-SQL-Unterschiede im Betrieb auffliegen? Wir übernehmen die Migration Schritt für Schritt, mit Testlauf und Prüfung.
Verwandte Themen
→Synapse Fabric Migrationsstrategie: Lift-and-Shift oder modernisieren
→Azure Synapse zu Fabric migrieren: Wann es sich lohnt



