Migration von Synapse zu Microsoft Fabric: Playbook

Azure Synapse Analytics hat eine ganze Generation von Enterprise-Analytics auf Azure geprägt. Doch die Roadmap von Microsoft ist heute eindeutig: Microsoft Fabric ist die strategische Plattform, und Synapse sollte für die Planung faktisch als End-of-Life behandelt werden. Neue Funktionen, neue Investitionen und die gesamte KI-Story 2026 — Data Agents, Copilot Cowork, Eventhouse mit Remote-MCP — landen in Fabric, nicht in Synapse.

Dies ist ein Praxis-Playbook für den Wechsel von Synapse zu Fabric, ohne das Funktionierende zu zerschlagen. Es ist in der Umsetzung verwurzelt: Bei CC Conceptualise haben wir Synapse-Bestände für europäische Unternehmen unter laufendem regulatorischem Umfang re-plattformiert, und die folgenden Lehren sind die, die wirklich den Unterschied gemacht haben.

TL;DR / Die wichtigsten Erkenntnisse

Synapse ist im Wartungsmodus. Microsoft Fabric ist der Nachfolger. Planen Sie Ihre Migration jetzt zu Ihren Bedingungen, nicht gegen eine erzwungene Frist.
Es ist eine Re-Plattformierung, kein Lift-and-Shift. SQL- und Spark-Code lässt sich mit moderaten Anpassungen übernehmen; Pipelines, Linked Services und Serverless-Muster müssen in der Regel überarbeitet werden.
OneLake verändert die Architektur. Ein einziger Delta-Parquet-Lake mit Medallion-Schichtung (Bronze/Silber/Gold) ersetzt den Integrations-Klebstoff zwischen Dedicated Pools, Serverless SQL und ADLS.
Governance und Residenz sind Freigabekriterien. EU-Kapazität verankern, OneLake-Residenz bestätigen und Purview-Bezeichnungen anwenden, bevor Zugriffe geöffnet werden — nicht danach.
KI bewusst einführen. Zuerst die Plattform in Betrieb nehmen und governen; Data Agents und Copilot anschließend auf zertifizierten Gold-Modellen aktivieren.

Warum jetzt von Synapse zu Fabric wechseln

Der ehrliche Grund, die Migration von Synapse zu Fabric 2026 anzugehen, ist: Die Plattform, von der Sie abhängen, wächst nicht mehr. Synapse läuft weiter, aber der Abstand zu Fabric vergrößert sich Quartal für Quartal. In Fabric leben einheitliche Compute, OneLake und die Funktionen für autonome Daten — und dort konzentrieren sich Support und Engineering von Microsoft.

Es gibt auch konkrete Zugkräfte:

Einheitliche Plattform. Fabric fasst Dedicated SQL Pools, Spark, Data Factory, Echtzeit-Analytics und Power BI in einer SaaS-Oberfläche zusammen, abgerechnet über eine einzige Kapazität.
OneLake als Single Source of Truth. Ein offener Delta-Parquet-Lake pro Mandant, mit Shortcuts statt Kopien, beseitigt eine ganze Klasse von Pipeline- und Duplikationsproblemen.
Durchgängige MLOps. Workspace-übergreifendes MLflow-Logging erlaubt es, Assets aus Azure Databricks und Azure ML in Fabric zu bringen und den gesamten Lebenszyklus an einem Ort zu betreiben.
Eine echte KI-Oberfläche. Fabric Data Agents treiben autonome Daten-Workflows an, und Eventhouse mit Remote-MCP erlaubt Agenten, Echtzeitdaten in natürlicher Sprache über KQL abzufragen.

„Synapse ist schlecht" ist nicht das Argument. Synapse war exzellent. Das Argument lautet: Der strategische Schwerpunkt hat sich verlagert, und Stillstand bedeutet heute eine härtere, stärker komprimierte Migration später.

Synapse zu Fabric: Komponenten-Zuordnung

Ein Großteil einer Synapse-Migration besteht darin zu verstehen, was aus jedem Bestandteil wird. Diese Tabelle deckt die Komponenten ab, die Sie in nahezu jedem Bestand antreffen.

Synapse-Komponente	Fabric-Entsprechung	Migrationshinweise
Dedicated SQL Pool	Warehouse	T-SQL lässt sich gut übernehmen; Distribution/Index-Konzepte unterscheiden sich. Performance-Muster neu validieren.
Serverless SQL Pool	SQL-Analyseendpunkt über Lakehouse	Dateiabfragen werden zu Abfragen auf OneLake-Tabellen/-Shortcuts. Externe Tabellen überarbeiten.
Spark Pools	Fabric Spark (Lakehouse-Notebooks)	Notebooks mit moderaten Anpassungen übernehmbar. Session- und Library-Konfiguration unterscheidet sich.
ADLS Gen2 Data Lake	OneLake	Delta Parquet ist Standard. Shortcuts nutzen, um Bestandsdaten nicht zu kopieren.
Synapse Pipelines	Data-Factory-Items (Pipelines)	Neu erstellen. Linked Services werden zu Connections; einige Aktivitäten unterscheiden sich.
Linked Services	Connections / OneLake-Shortcuts	Viele Integrationen werden durch native Shortcuts ersetzt statt neu erstellt.
Synapse Link	Mirroring / Shortcuts	Pro Quelle neu bewerten. Mirroring deckt mehrere operative Datenbanken nativ ab.
Power BI (DirectQuery auf Pool)	Direct Lake über OneLake	Oft der größte Performance-Gewinn der Migration.
Workspace-RBAC	Fabric-Workspace-Rollen + OneLake-Security	Zugriffe neu modellieren; keine 1:1-Zuordnung annehmen.

Das Prinzip: SQL- und Spark-Logik ist weitgehend portierbar; die eigentliche Arbeit steckt in der Orchestrierungs- und Integrationsschicht.

Das Migrations-Playbook

Die folgenden fünf Phasen laufen als disziplinierte Abfolge, wobei eine Parallelbetrieb-Abgleichsschleife jeden Cutover absichert.

Loading diagram...

1. Assessment und Inventarisierung (Woche 1–2)

Sie können nicht migrieren, was Sie nicht sehen. Katalogisieren Sie jeden Dedicated und Serverless Pool, jeden Spark Pool, jede Pipeline, jeden Linked Service und — entscheidend — jeden nachgelagerten Konsumenten (Reports, Jobs, APIs, externe Integrationen). Es sind die nachgelagerten Bindungen, nicht die Daten, die einen Cutover meist zum Scheitern bringen.

Pools, Pipelines, Notebooks und externe Tabellen inventarisieren.
Jeden Konsumenten seinem Quell-Endpunkt zuordnen.
Daten nach Vertraulichkeit und Residenz klassifizieren.
Jede Workload bewerten: mit Anpassungen übernehmen, neu erstellen oder ausmustern.

In einem lang gewachsenen Synapse-Bestand ist ein erheblicher Teil der Objekte tot — ungenutzte Tabellen, verwaiste Pipelines, Reports, die niemand öffnet. Mustern Sie sie aus. Zahlen Sie nicht für die Migration von Ballast.

2. Zielarchitektur auf OneLake entwerfen (Woche 2–4)

Entwerfen Sie das Ziel, bevor Sie etwas verschieben. Standardisieren Sie auf eine Medallion-Architektur: Bronze für Rohdaten, Silber für bereinigte und konforme Daten, Gold für geschäftsfertige Modelle. Legen Sie Workspace- und Domänen-Topologie, Kapazitätsdimensionierung und Sicherheitsmodell im Voraus fest.

Nutzen Sie OneLake-Shortcuts konsequent. Bestehende ADLS-Gen2-Daten lassen sich oft direkt referenzieren statt kopieren, was die Migration verkürzt und Duplikation reduziert. Planen Sie Direct Lake für Power BI von Tag eins an — es ist häufig die Änderung, die Fachanwender am stärksten bemerken.

3. Eine Domäne pilotieren (Woche 4–7)

Wählen Sie eine in sich geschlossene Domäne — ein einzelnes Datenprodukt mit klarem Verantwortlichen und überschaubarer Konsumentenzahl — und migrieren Sie sie durchgängig: Ingestion, Transformation, Bereitstellung und Reporting. Das beweist Ihre Muster, Ihr CI/CD und Ihre Governance, bevor Sie den gesamten Bestand verpflichten.

Setzen Sie das neue Power-BI-Copilot-Tooling-Format ein (GA Mai 2026), ein Git-freundliches, textbasiertes Metadatenformat für semantische Modelle, damit Ihre semantischen Modelle wie der Rest der Plattform unter Versionskontrolle stehen.

4. In der Breite migrieren (Woche 6–13)

Mit bewährten Mustern migrieren Sie Domäne für Domäne. Betreiben Sie Synapse und Fabric je Domäne über ein Validierungsfenster parallel. Gleichen Sie Zeilenzahlen, Aggregate und Report-Ergebnisse gegen den Synapse-Ausgangszustand ab, bevor Sie Konsumenten umleiten.

Schema und Daten migrieren (wo möglich Shortcuts).
Pipelines als Data-Factory-Items neu erstellen.
Notebooks und Warehouse-Logik portieren.
Semantische Modelle auf Direct Lake neu aufbauen.
Gegen den Synapse-Ausgangszustand abgleichen.
Konsumenten umleiten und überwachen.

5. Cutover, Governance und Außerbetriebnahme

Schalten Sie pro Domäne um, niemals als Big Bang. Sobald die Konsumenten einer Domäne auf Fabric validiert sind, frieren Sie das Synapse-Äquivalent ein, überwachen es über eine definierte Stabilisierungsphase und nehmen es dann außer Betrieb, um nicht doppelt zu zahlen. Erst wenn die Plattform stabil und governt ist, aktivieren Sie autonome KI-Funktionen auf zertifizierten Gold-Modellen.

Governance, Residenz und die EU-Dimension

Für europäische Unternehmen ist das keine Fußnote. Verankern Sie die Fabric-Kapazität in der korrekten EU-Region, bestätigen Sie die Residenz der OneLake-Daten dort und wenden Sie Microsoft-Purview-Vertraulichkeitsbezeichnungen und Information Protection an, bevor Zugriffe geöffnet werden. Bilden Sie Rechtsgrundlage und Verarbeitungsverzeichnisse beim Verschieben der Datensätze ab und prüfen Sie, dass Residenz und Zugriffskontrollen mindestens dem Synapse-Ausgangszustand entsprechen.

Wo DORA, NIS2 oder branchenspezifische Vorgaben greifen, behandeln Sie die Migration als Änderung an einem kritischen System: dokumentierte Risikobewertung, getesteter Rollback und ein belegbarer Audit-Trail als Nachweispflicht. Wir behandeln Residenz, Klassifizierung und Abgleich als harte Go-live-Kriterien — eine Domäne geht erst live, wenn sie alle drei besteht.

Wann man nicht überstürzen sollte

Ist eine Synapse-Workload wirklich stabil, isoliert und günstig, können Sie sie spät einplanen — aber einplanen sollten Sie sie. Das eine Anti-Muster, das Sie vermeiden müssen: Data Agents und Copilot Cowork auf halb migrierte, ungovernte Daten zu richten. Autonome Workflows verstärken alles, worauf sie gerichtet sind — auch fehlerhafte Lineage und unklassifizierte sensible Daten. Bringen Sie zuerst die Plattform in Betrieb, härten Sie die Governance, dann schalten Sie die KI ein.

Fazit

Die Migration von Synapse zu Fabric versteht man am besten als disziplinierte Re-Plattformierung auf OneLake, nicht als Copy-and-paste. Bringen Sie Medallion-Design und Governance in Ordnung, pilotieren Sie eine Domäne und migrieren Sie dann in der Breite mit Parallelbetrieb und Abgleich — dann werden die KI-Funktionen, die Fabric überzeugend machen, zu einem kontrollierten Upgrade statt zu einem Risiko.

Wenn Sie eine Fabric-Migration konzipieren und einen Partner suchen, der dies unter europäischem regulatorischem Umfang geliefert hat, sehen Sie sich unsere Services für KI- und Daten-Plattform-Engineering an.

FAQ

Wird Azure Synapse Analytics abgekündigt?

Microsoft hat Microsoft Fabric als strategischen Nachfolger von Azure Synapse Analytics positioniert, und neue Investitionen fließen heute in Fabric statt in Synapse. Synapse wird nicht über Nacht abgeschaltet, befindet sich aber faktisch im Wartungsmodus und sollte für die Planung als End-of-Life behandelt werden. Beginnen Sie die Migrationsplanung jetzt, solange Ihr Synapse-Bestand gut verstanden ist, statt auf eine erzwungene Frist zu warten.

Kann ich von Synapse zu Fabric migrieren, ohne alles neu zu schreiben?

Teilweise. Tabellen aus Dedicated SQL Pools, T-SQL-Logik und viele Spark-Notebooks lassen sich mit moderaten Anpassungen übernehmen, und Microsoft stellt Migrationsassistenten für Schema und Code bereit. Pipelines, Linked Services und Serverless-Muster müssen meist überarbeitet werden, da Fabric mit Data-Factory-Items und OneLake-Shortcuts statt dem Synapse-Workspace-Modell arbeitet. Planen Sie eine strukturierte Re-Plattformierung, keinen reinen Lift-and-Shift.

Was ist OneLake und wie verändert es eine Synapse-Migration?

OneLake ist der einzige, mandantenweite Data Lake von Fabric auf Basis von Delta Parquet — jede Workload liest und schreibt dasselbe offene Format, ohne Daten zwischen Engines zu kopieren. Bei einer Synapse-Migration entfällt damit ein Großteil des Integrations-Klebstoffs, den Sie bisher zwischen Dedicated Pools, Serverless SQL und dem Data Lake gepflegt haben. Sie entwerfen einmal eine Medallion-Architektur (Bronze/Silber/Gold), die SQL, Spark und Power BI gemeinsam nutzen.

Wie lange dauert eine Migration von Synapse zu Fabric?

Für einen mittelgroßen Bestand mit einigen Dutzend Pipelines und wenigen SQL Pools sind rund acht bis sechzehn Wochen realistisch, inklusive Assessment, Pilot-Domäne und Cutover. Große Bestände mit hoher Datengravitation, strengem regulatorischem Umfang oder vielen nachgelagerten Konsumenten können sechs Monate oder länger benötigen. Die größte Variable sind selten die Daten, sondern die Zahl der Reports, Jobs und Integrationen, die an den alten Endpunkten hängen.

Wie wahren wir DSGVO und Datenresidenz während der Migration?

Verankern Sie die Fabric-Kapazität in der korrekten EU-Region, bestätigen Sie die Residenz der OneLake-Daten und wenden Sie Microsoft-Purview-Vertraulichkeitsbezeichnungen und Information Protection an, bevor Sie Zugriffe öffnen. Dokumentieren Sie Rechtsgrundlage und Verarbeitungsverzeichnisse beim Verschieben der Datensätze und prüfen Sie, dass Residenz und Zugriffskontrollen mindestens dem Synapse-Ausgangszustand entsprechen. Wir behandeln Residenz und Klassifizierung als Freigabekriterien für den Go-live, nicht als Nachgedanken.

Sollten wir Fabric Data Agents und Copilot während der Migration einführen?

Führen Sie sie bewusst ein, nachdem Ihre Daten in OneLake korrekt geschichtet und governt sind, nicht als Teil des Cutovers. Data Agents und Copilot Cowork sind wirkungsvoll, sobald die Gold-Modelle vertrauenswürdig sind, doch autonome Workflows auf halb migrierte Daten zu richten vervielfacht das Risiko. Bringen Sie zuerst die Plattform in Betrieb, härten Sie die Governance und aktivieren Sie KI-Funktionen dann auf einer kontrollierten Menge zertifizierter Modelle.