Synapse to Fabric Migration: A Practical Playbook

Azure Synapse Analytics defined a generation of enterprise analytics on Azure. But Microsoft's roadmap is now unambiguous: Microsoft Fabric is the strategic platform, and Synapse should be treated as effectively end-of-life for planning purposes. New capability, new investment, and the entire 2026 AI story — Data Agents, Copilot Cowork, Eventhouse with remote MCP — land in Fabric, not Synapse.

This is a practitioner's playbook for moving from Synapse to Fabric without breaking what works. It is grounded in delivery: at CC Conceptualise we have re-platformed Synapse estates for European enterprises under live regulatory scope, and the lessons below are the ones that actually moved the needle.

TL;DR / Key takeaways

Synapse is in maintenance mode. Microsoft Fabric is the successor. Plan your migration now, on your terms, rather than against a forced deadline.
It is a re-platform, not a lift-and-shift. SQL and Spark code port with modest changes; pipelines, linked services, and serverless patterns generally need rework.
OneLake changes the architecture. A single Delta-Parquet lake with a medallion (bronze/silver/gold) layout replaces the integration glue between dedicated pools, serverless SQL, and ADLS.
Governance and residency are gating criteria. Pin EU capacity, confirm OneLake residency, and apply Purview labels before opening access — not after.
Adopt AI deliberately. Land and govern the platform first; enable Data Agents and Copilot on certified gold models afterwards.

Why move from Synapse to Fabric now

The honest reason to start the Synapse to Fabric migration in 2026 is that the platform you depend on has stopped growing. Synapse still runs, but the gap between it and Fabric widens every quarter. Fabric is where unified compute, OneLake, and the autonomous-data capabilities live — and where Microsoft's support and engineering attention are concentrated.

There are concrete pull factors too:

Unified platform. Fabric collapses dedicated SQL pools, Spark, Data Factory, real-time analytics, and Power BI into one SaaS surface billed against a single capacity.
OneLake as a single source of truth. One open Delta-Parquet lake per tenant, with shortcuts instead of copies, removes a large class of pipeline and duplication problems.
End-to-end MLOps. Cross-workspace MLflow logging lets you bring assets from Azure Databricks and Azure ML into Fabric and run the full lifecycle in one place.
A real AI surface. Fabric Data Agents drive autonomous data workflows, and Eventhouse with remote MCP lets agents query real-time data in natural language over KQL.

"Synapse is bad" is not the argument. Synapse was excellent. The argument is that the strategic centre of gravity has moved, and standing still now means a harder, more compressed migration later.

Synapse to Fabric: component mapping

Most of a Synapse migration is understanding what each piece becomes. This table covers the components you will meet in almost every estate.

Synapse component	Fabric equivalent	Migration notes
Dedicated SQL pool	Warehouse	T-SQL ports well; distribution/index concepts differ. Re-validate performance patterns.
Serverless SQL pool	SQL analytics endpoint over Lakehouse	Querying files becomes querying OneLake tables/shortcuts. Rework external tables.
Spark pools	Fabric Spark (Lakehouse notebooks)	Notebooks port with modest change. Session and library config differs.
ADLS Gen2 data lake	OneLake	Delta-Parquet is the default. Use shortcuts to avoid copying existing data.
Synapse Pipelines	Data Factory items (pipelines)	Re-author. Linked services become connections; some activities differ.
Linked services	Connections / OneLake shortcuts	Many integrations are replaced by native shortcuts rather than re-created.
Synapse Link	Mirroring / shortcuts	Reassess per source. Mirroring covers several operational databases natively.
Power BI (DirectQuery to pool)	Direct Lake over OneLake	Often the single biggest performance win of the migration.
Workspace RBAC	Fabric workspace roles + OneLake security	Re-model access; do not assume a 1:1 mapping.

The principle: SQL and Spark logic is largely portable; the orchestration and integration layer is where the real work sits.

The migration playbook

The five phases below run as a disciplined sequence, with a parallel-run reconciliation loop guarding every cutover.

Loading diagram...

1. Assess and inventory (weeks 1–2)

You cannot migrate what you cannot see. Catalogue every dedicated and serverless pool, Spark pool, pipeline, linked service, and — critically — every downstream consumer (reports, jobs, APIs, external integrations). The downstream bindings, not the data, are what usually break a cutover.

Inventory pools, pipelines, notebooks, and external tables.
Map every consumer to its source endpoint.
Classify data for sensitivity and residency.
Score each workload: lift-with-changes, re-author, or retire.

A meaningful share of Synapse objects in a long-lived estate are dead — unused tables, orphaned pipelines, reports nobody opens. Retire them. Do not pay to migrate waste.

2. Design the target on OneLake (weeks 2–4)

Design the destination before you move anything. Standardise on a medallion architecture: bronze for raw ingest, silver for cleansed and conformed data, gold for business-ready models. Decide your workspace and domain topology, your capacity sizing, and your security model up front.

Use OneLake shortcuts aggressively. Existing ADLS Gen2 data can often be referenced in place rather than copied, which shortens the migration and reduces duplication. Plan Direct Lake for Power BI from day one — it is frequently the change business users notice most.

3. Pilot one domain (weeks 4–7)

Pick one self-contained domain — a single data product with a clear owner and a manageable set of consumers — and migrate it end to end: ingest, transform, serve, and report. This proves your patterns, your CI/CD, and your governance before you commit the whole estate.

Adopt the new Power BI Copilot Tooling Format (GA May 2026), a Git-friendly text-based semantic-model metadata format, so your semantic models live in source control like the rest of your platform.

4. Migrate at scale (weeks 6–13)

With patterns proven, migrate domain by domain. Run Synapse and Fabric in parallel for each domain through a validation window. Reconcile row counts, aggregates, and report outputs against the Synapse baseline before redirecting consumers.

Migrate schema and data (shortcuts where possible).
Re-author pipelines as Data Factory items.
Port notebooks and warehouse logic.
Rebuild semantic models on Direct Lake.
Reconcile against the Synapse baseline.
Redirect consumers and monitor.

5. Cut over, govern, and decommission

Cut over per domain, never big-bang. Once a domain's consumers are validated on Fabric, freeze the Synapse equivalent, monitor for a defined soak period, then decommission to stop paying twice. Only after the platform is stable and governed do you enable autonomous AI capabilities on certified gold models.

Governance, residency, and the EU dimension

For European enterprises this is not a footnote. Pin Fabric capacity to the correct EU region, confirm OneLake data resides there, and apply Microsoft Purview sensitivity labels and information protection before access is opened. Map your lawful basis and processing records as datasets move, and validate that residency and access controls at least match the Synapse baseline.

Where DORA, NIS2, or sector rules apply, treat the migration as a change to a critical system: documented risk assessment, tested rollback, and an evidenced audit trail. We treat residency, labelling, and reconciliation as hard go-live gates — a domain does not cut over until it passes all three.

When not to rush

If a Synapse workload is genuinely stable, isolated, and cheap, you can sequence it late — but still sequence it. The one anti-pattern to avoid is enabling Data Agents and Copilot Cowork against half-migrated, ungoverned data. Autonomous workflows amplify whatever they are pointed at, including bad lineage and unlabelled sensitive data. Land the platform, harden governance, then turn on the AI.

Conclusion

The Synapse to Fabric migration is best understood as a disciplined re-platform onto OneLake, not a copy-paste. Get the medallion design and governance right, pilot one domain, then move at scale with parallel-run reconciliation — and the AI capabilities that make Fabric compelling become a controlled upgrade rather than a risk.

If you are scoping a Fabric migration and want a partner who has delivered this under European regulatory scope, see our AI & Data Platform Engineering services.

FAQ

Is Azure Synapse Analytics being deprecated?

Microsoft has positioned Microsoft Fabric as the strategic successor to Azure Synapse Analytics, and net-new investment now flows into Fabric rather than Synapse. Synapse is not switched off overnight, but it is effectively in maintenance mode and customers should treat it as end-of-life for planning purposes. Start migration planning now while your Synapse estate is still well understood, rather than waiting for a forced deadline.

Can I migrate from Synapse to Fabric without rewriting everything?

Partly. Dedicated SQL pool tables, T-SQL logic, and many Spark notebooks port with modest changes, and Microsoft provides migration assistants for schema and code. Pipelines, linked services, and serverless patterns usually need rework because Fabric uses Data Factory items and OneLake shortcuts rather than the Synapse workspace model. Plan for a structured re-platform, not a lift-and-shift.

What is OneLake and how does it change a Synapse migration?

OneLake is Fabric's single, tenant-wide data lake built on Delta Parquet, so every workload reads and writes the same open format without copying data between engines. In a Synapse migration this removes much of the integration glue you previously maintained between dedicated pools, serverless SQL, and the data lake. You design once around a medallion (bronze/silver/gold) layout and let SQL, Spark, and Power BI share it.

How long does a Synapse to Fabric migration take?

For a mid-size estate of a few dozen pipelines and a handful of SQL pools, expect roughly eight to sixteen weeks including assessment, a pilot domain, and cutover. Large estates with heavy data gravity, strict regulatory scope, or many downstream consumers can run six months or more. The biggest variable is rarely the data — it is the number of reports, jobs, and integrations bound to the old endpoints.

How do we keep GDPR and data residency intact during migration?

Pin your Fabric capacity to the correct EU region, confirm OneLake data resides in that region, and apply Microsoft Purview sensitivity labels and information protection before opening access. Document the lawful basis and processing records as you move datasets, and validate that residency and access controls match your Synapse baseline. We treat residency and labelling as gating criteria for go-live, not afterthoughts.

Should we adopt Fabric Data Agents and Copilot during the migration?

Adopt them deliberately, after your data is correctly layered and governed in OneLake, not as part of the cutover itself. Data Agents and Copilot Cowork are powerful once gold-layer models are trustworthy, but pointing autonomous workflows at half-migrated data multiplies risk. Land the platform first, harden governance, then enable AI capabilities on a controlled set of certified models.