To migrate from Azure Synapse to Microsoft Fabric, you re-platform three things in a deliberate order: the dedicated SQL pool becomes a Fabric Data Warehouse, Synapse pipelines are rebuilt in Fabric Data Factory, and your data lake moves to OneLake — usually accessed first through shortcuts, then physically migrated. This is a re-platforming exercise, not a lift-and-shift: Microsoft's Fabric Migration Assistant copies schema and data and uses Copilot to fix incompatible T-SQL, but pipelines are not auto-converted and your team must validate behavior before cutover.

This guide is written for the data-platform owners, IT architects, and analytics leads who run Synapse today and have to decide whether, when, and how to move to Fabric without breaking production reporting. It covers the component mapping, the phased sequence that keeps risk low, the real limitations to plan around, how to size the Fabric capacity you land on, and the validation steps that let you cut over with confidence rather than hope.

Key takeaways

• Fabric is the successor platform to Synapse, and Microsoft is actively steering customers across. Microsoft publishes migration tooling and claims up to 75% faster query performance and up to 71% lower cost per query versus Synapse dedicated SQL pools at comparable capacity pricing.
• It is not a one-click migration. The Migration Assistant copies metadata and data and auto-converts schema, but Synapse pipelines must be rebuilt in Fabric Data Factory and some T-SQL needs manual remediation.
• Move data access before you move data. OneLake shortcuts give Fabric no-copy access to existing ADLS Gen2, so you can run Synapse and Fabric in parallel and validate results before a physical copy.
• Start with Spark, finish with the SQL pool. Spark notebooks are the lowest-risk first workload; dedicated SQL pools carry tables, procedures, and security and are the highest-risk, so they go last.
• Plan around real Fabric Data Warehouse limits. Fabric does not support every T-SQL statement, cross-region connections, or Synapse Mapping Data Flows, so an honest feature-parity check belongs in the assessment phase, not after cutover.
• Size the F-SKU from measured usage, not a like-for-like swap. Use the Fabric SKU Estimator and the Capacity Metrics app during a trial, because migration is the moment to right-size rather than copy your old capacity across.

The short answer: how do you migrate from Synapse to Fabric?

Treat it as a phased re-platforming you prove on one workload first, then repeat. The sequence below is the low-risk path Microsoft's own migration guidance and the Fabric Migration Assistant are built around.

1. Inventory every Synapse asset — dedicated and serverless SQL pools, Spark pools and notebooks, pipelines, linked services, and downstream Power BI connections — and map each to its Fabric equivalent.
2. Provision a Fabric capacity (or the 60-day free trial), size it with the SKU Estimator, and create your workspace.
3. Migrate Spark workloads first, remapping notebook utilities and validating libraries.
4. Create OneLake shortcuts to existing ADLS Gen2 so Fabric can read your data with no copy while you validate.
5. Migrate the dedicated SQL pool with the Migration Assistant, then fix flagged T-SQL with Copilot assistance.
6. Rebuild pipelines in Fabric Data Factory, then copy the data and reconcile row counts.
7. Run both environments in parallel, reroute connections, and decommission Synapse once validated.

What maps to what: the Synapse-to-Fabric component mapping

Most of the planning anxiety disappears once you see that each Synapse component has a defined Fabric counterpart. According to Microsoft's migration methods documentation, the mapping is consistent — what varies is how much manual rework each piece needs.

Synapse components and their Fabric equivalents

Dedicated SQL pool

• Fabric equivalent: Fabric Data Warehouse (T-SQL on OneLake).
• Effort: Highest — tables, stored procedures, and security objects migrate via the Migration Assistant, but incompatible T-SQL needs remediation.

Synapse pipelines

• Fabric equivalent: Fabric Data Factory pipelines.
• Effort: Medium-high — pipelines are not auto-converted and are generally rebuilt, reusing datasets and scripts where possible; Mapping Data Flows are unsupported.

Azure Data Lake Storage Gen2

• Fabric equivalent: OneLake (Lakehouse Files), or a shortcut to the existing account.
• Effort: Low to start — a OneLake shortcut gives no-copy access immediately; a physical move is a follow-on step.

Synapse Spark notebooks and jobs

• Fabric equivalent: Fabric notebooks and Spark job definitions.
• Effort: Low-medium — a guided assistant helps, but references to mssparkutils are remapped to notebookutils and libraries revalidated.

How does the Fabric Migration Assistant work?

The Fabric Migration Assistant is a guided experience built into Fabric that copies metadata and data from the source database and automatically converts the source schema to a Fabric Data Warehouse. You either upload a DACPAC exported from your Synapse dedicated SQL pool or connect directly to the source system, and it captures tables, views, functions, stored procedures, and security objects such as roles, permissions, and dynamic data masking.

The step that saves the most time is the fix-up stage. Scripts that fail to convert are grouped into primary objects and the dependent objects that reference them, and the assistant guides you to fix primary objects first. For each failed script, Copilot suggests a corrected version — which you verify before running, because an AI suggestion is a starting point, not a guarantee. Data is then copied through a Fabric Data Factory copy job, after which you test, compare the old and new warehouses, and reroute connections.

The tooling automates the mechanical 80% of a migration; the remaining 20% — pipeline logic, T-SQL edge cases, and validation — is where the engagement is won or lost.

If your team has mapped its Synapse estate and wants a defensible migration plan before touching production, BabyBots runs fixed-fee Fabric migration assessments that inventory your workloads, flag the feature-parity gaps that stall cutovers, and sequence the move around your reporting calendar. You can see how we approach the surrounding platform decisions in our guide on sizing Fabric capacity and what it costs to run.

What order should you migrate workloads in?

Sequence by risk, not by org chart. The goal of the first migration is to prove the pattern on something recoverable, then template it for everything that follows.

• Spark first. Notebooks and Spark jobs have guided tooling and no downstream reporting dependency, so a failed attempt is cheap to retry.
• Data access next, via shortcuts. Point OneLake shortcuts at ADLS Gen2 so Fabric queries current data with no movement, enabling a true parallel run.
• Pipelines after that. Rebuild in Fabric Data Factory, reusing linked services and scripts, and expect Mapping Data Flows to be re-authored.
• Dedicated SQL pool last. It carries the schema, procedures, and security that your Power BI reports depend on, so it migrates once the surrounding pieces are proven.

Microsoft suggests a first workload in the 1-to-10-terabyte range — large enough to demonstrate the platform's benefits, small enough to deliver quickly and build a repeatable template.

What are the limitations you have to plan around?

Fabric is production-capable, but a credible plan budgets for its gaps up front. The Fabric Data Warehouse limitations that most often surface in a Synapse migration are concrete and worth checking against your workload before you commit a cutover date.

• T-SQL surface area is narrower. Fabric Data Warehouse does not support every Transact-SQL statement available in SQL Server, so complex Synapse procedures may need rewriting.
• Cross-region connections are not supported. Source and target items must sit in the same region, which shapes where you provision the new capacity.
• Mapping Data Flows do not carry over. Synapse Mapping Data Flows have no Fabric equivalent and are re-implemented in Dataflows Gen2 or pipelines.
• Capacity is a shared pool. Every workload draws from the same Capacity Units, so a heavy Spark job can throttle production Power BI unless you isolate development onto its own capacity.

How do you size the Fabric capacity you land on?

Do not copy your Synapse sizing across. Fabric bills on a single pool of Capacity Units through F-SKUs, and migration is the right moment to size from measured demand. Run real workloads on the 60-day trial or a pay-as-you-go capacity, read the Fabric Capacity Metrics app, and use the SKU Estimator to pick the tier that absorbs your busiest hour without throttling.

One threshold drives the economics: on an F64 capacity or larger, report viewers consume Power BI content for free, while below F64 every viewer still needs a paid license. If you are also retiring Power BI Premium, coordinate the two moves — the Power BI Premium to Fabric migration is a capacity-SKU reassignment that pairs naturally with a Synapse re-platforming on the same F-SKU. For the broader platform decision, our Fabric versus Snowflake comparison lays out where each wins.

How do you validate and cut over without an outage?

The cutover is a validation problem, not a copy problem. After the initial data copy, reconcile row and column counts between Synapse and Fabric and confirm business KPIs through live reports before switching anything. Microsoft's own customer references stress running the old and new environments in parallel and validating KPIs through reports precisely because, for a data platform, trust is the product.

1. Copy data, then reconcile row counts and key metrics table by table.
2. Validate security — replace SQL authentication with Microsoft Entra ID and confirm workspace-level permissions match intent.
3. Run Synapse and Fabric in parallel so every ETL process and downstream consumer is confirmed working.
4. Reroute Power BI reports, pipelines, and applications to the Fabric endpoints.
5. Decommission Synapse resources only after a clean parallel period.

Frequently asked questions

Is migrating from Synapse to Fabric automatic?

No. The Fabric Migration Assistant automates schema conversion and data copy for the dedicated SQL pool and offers Copilot fixes for incompatible T-SQL, but it does not move Synapse pipelines, which must be rebuilt in Fabric Data Factory. Data is not moved until you run a copy job, and every workload needs validation before cutover.

How long does a Synapse-to-Fabric migration take?

It depends on estate complexity, but the reliable pattern is a small initial workload — Microsoft suggests 1 to 10 terabytes — proven end to end first, then repeated. That first pass establishes the template, the tooling comfort, and the validation routine that make subsequent workloads faster and lower risk.

Will my Power BI reports break during the migration?

Not if you sequence it correctly. Keep Synapse serving reports while you build and validate in Fabric, reconcile KPIs through live reports during a parallel run, and only reroute report connections once the Fabric endpoints are confirmed. The dedicated SQL pool migrates last precisely because reports depend on it.

Do I have to move my data out of ADLS Gen2 immediately?

No, and you usually should not. Create OneLake shortcuts that point at your existing ADLS Gen2 locations so Fabric workloads get immediate, no-copy access. That lets you run Synapse and Fabric side by side and validate results before committing to a physical copy as a follow-on step.

Is Microsoft Fabric cheaper than Azure Synapse?

Microsoft claims up to 71% lower cost per query and up to 75% faster query performance versus Synapse dedicated SQL pools at comparable capacity pricing, and up to 3.5x lower costs for data engineering versus Spark in Synapse. Real savings depend on right-sizing the F-SKU and consolidating workloads onto one capacity rather than running over-provisioned, siloed services.

What is the biggest risk in a Synapse-to-Fabric migration?

Underestimating the non-automated work — rebuilt pipelines, re-authored Mapping Data Flows, and T-SQL that falls outside Fabric's supported surface. Teams that treat it as a lift-and-shift hit these gaps mid-migration; teams that inventory and feature-check during assessment plan around them.

Where this is heading

Microsoft is investing in Fabric as the destination for the entire analytics estate, and the migration tooling, the Copilot-assisted fix-ups, and the performance and cost claims all point the same direction: Synapse customers will move, and the window to do it deliberately is better than doing it reactively at an agreement deadline. The organizations that come out ahead are the ones that treat the move as a chance to right-size capacity, consolidate governance in OneLake, and retire technical debt — not as a rushed like-for-like swap.

Plan your Synapse-to-Fabric migration with BabyBots

If you are weighing a move off Synapse, book a BabyBots Fabric migration assessment — in a single working session we inventory your Synapse estate, map every workload to its Fabric equivalent, flag the feature-parity gaps that stall cutovers, and hand you a sequenced, right-sized migration plan you can execute against. Start at babybots.ai and we will map your path from Synapse to a governed Fabric platform.

Sources

• Microsoft Learn — Migration Assistant for Fabric Data Warehouse
• Microsoft Learn — Migration methods for Azure Synapse dedicated SQL pools to Fabric
• Microsoft Learn — Limitations of Fabric Data Warehouse
• Microsoft — Azure to Fabric Migration (performance and cost claims)
• Microsoft Learn — Power BI Premium P SKU to Fabric F SKU migration decision guide