In Short: How Do You Migrate Synapse to Fabric?
Workload by workload, running in parallel, never as a single cutover. Dedicated SQL pools map to Fabric Warehouse, Spark pools to Fabric notebooks, and Synapse pipelines to Data Factory in Fabric. Move one workload, validate it against the existing estate, then move the next - keeping Synapse serving production until the Fabric side has earned trust. The effort scales with the number of distinct workloads, not with data volume.
Before You Start: Is This the Right Move?
This runbook assumes the decision is made. If it is not, our Fabric versus Synapse comparison covers the case each way.
One check worth doing regardless: count your pipelines, pools and reports before estimating anything. Migration effort tracks the number of distinct things to move and validate. Teams that estimate from data volume are consistently surprised, in one direction.
What Maps to What
The conceptual mapping is cleaner than most platform migrations, which is the main thing working in your favour.
- Dedicated SQL pool to Fabric Warehouse. T-SQL surface, familiar model, though not every construct behaves identically.
- Serverless SQL pool to Fabric SQL endpoints over the lakehouse, which is often a closer fit than people expect.
- Spark pools to Fabric notebooks and Spark. Notebook code typically ports with modest changes; cluster configuration does not carry over.
- Synapse pipelines to Data Factory in Fabric. Activity concepts are largely familiar; linked services and integration runtimes need rethinking.
- ADLS Gen2 storage to OneLake - or, importantly, left where it is and referenced with a shortcut.
That last point deserves emphasis, because it changes the shape of the whole project.
The Sequence That Works
Phase 1 - Inventory and triage. List every pipeline, pool, notebook and downstream report. Then classify each as: migrate as-is, redesign during migration, or retire. Most estates carry a surprising amount of the third category, and every item retired is effort saved.
Phase 2 - Stand up Fabric alongside Synapse. Create the workspace, capacity and lakehouse structure. Use OneLake shortcuts to reference existing ADLS data rather than copying it. Fabric can now read your data while Synapse continues to serve production - nothing has been risked yet.
Phase 3 - Move one meaningful workload. Not the easiest and not the hardest: something real enough that success proves the pattern. Build it in Fabric, run both platforms against the same source, and reconcile the outputs row by row.
Phase 4 - Parallel run and validate. Both estates producing the same numbers for at least one full business cycle, month-end included. This is the phase teams compress under pressure, and it is the one that catches the errors.
Phase 5 - Repoint consumers. Move Power BI reports onto the Fabric semantic model. Direct Lake is usually a follow-on optimisation, not part of the migration itself - change one thing at a time.
Phase 6 - Decommission deliberately. Turn Synapse workloads off explicitly once their Fabric equivalents are trusted. An estate left running "just in case" becomes a permanent second bill and a permanent second source of truth.
Then repeat phases 3 to 6 for the next workload.
The Decisions That Bite Six Weeks In
T-SQL that behaved differently. Fabric Warehouse presents a T-SQL surface but is not a dedicated SQL pool. Assumptions about specific behaviours, hints and less common constructs can produce results that are subtly rather than obviously wrong. This is why row-level reconciliation matters more than a smoke test.
Hardcoded references. Pipelines carrying Synapse-specific resource names, linked service references or hardcoded paths fail in ways that look mysterious until you go looking. Cheap to fix, easy to miss.
Integration runtimes and networking. On-premises sources reached through a self-hosted integration runtime need their Fabric equivalent planned early. This has genuine lead time if firewall changes are involved, and it blocks everything downstream.
Capacity sizing under double load. During parallel running you are paying for both platforms, and the Fabric capacity is carrying migration work on top of steady state. Size for the parallel period, not the end state - see our capacity sizing guide.
Security model translation. Synapse permissions do not transfer. Access control needs rebuilding on Fabric's model with Entra groups and row-level security. Treat this as design work, not configuration.
Lift and Shift, or Redesign?
The honest answer is both, chosen deliberately per workload.
Lift and shift anything that currently works and nobody complains about. Migration is not the moment to improve things that are fine.
Redesign the things that already hurt - the model everyone works around, the pipeline that breaks monthly, the report logic nobody can explain. A migration is the cheapest opportunity you will get to fix them, because you are testing everything anyway.
What sinks projects is redesigning everything at once. That is not a migration, it is a rebuild with a migration deadline, and it will slip.
How Long It Takes
A single warehouse with a handful of pipelines and a few reports: weeks. A mature estate with dozens of pipelines, multiple pools, years of accumulated logic and a large reporting surface: a phased programme across months.
The variable is the count of distinct workloads and the reconciliation effort each demands - not terabytes. A team that has honestly inventoried its estate can estimate this well; one that has not, cannot.
Where Solv Systems Comes In
We migrate Synapse estates to Fabric, and we do it in the sequence above rather than as a cutover, because we have seen what happens otherwise.
What we bring is mostly discipline: an honest inventory including the things worth retiring, reconciliation that compares row counts and values rather than declaring victory when a pipeline runs green, and a parallel period that lasts a full business cycle. Migrations rarely fail on technical difficulty. They fail on validation shortcuts taken under schedule pressure.