Migration
Azure Synapse Analytics to Microsoft Fabric migration: a practical guide
How to move Azure Synapse dedicated SQL pools, pipelines, Spark pools and serverless SQL to Microsoft Fabric: Warehouse and Lakehouse targets, T-SQL differences, data movement and cutover.
Hemant Walchale
· 2 min read
Azure Synapse Analytics brought SQL pools, Spark and pipelines together in one workspace. Microsoft Fabric is its successor, rebuilt as a SaaS platform around OneLake and Power BI. For Synapse customers the move is a natural next step, but each Synapse component lands somewhere slightly different.
This is the approach we recommend.
1. Inventory each Synapse component
List dedicated SQL pool databases (tables, views, stored procedures), serverless SQL pool views over the data lake, Synapse pipelines and data flows, Spark pools with their notebooks and libraries, linked services, triggers and the Power BI datasets that read from Synapse. Query and pipeline run history shows what is still used.
2. Map components to Fabric
| Azure Synapse | Microsoft Fabric |
|---|---|
| Dedicated SQL pool | Fabric Warehouse (T-SQL) |
| Serverless SQL pool over ADLS | Lakehouse SQL analytics endpoint, with OneLake shortcuts to existing storage |
| Synapse pipelines | Data Factory pipelines in Fabric |
| Mapping data flows | Dataflow Gen2, or notebooks or SQL for complex logic |
| Spark pools and notebooks | Fabric Spark notebooks and Spark job definitions |
| Data Explorer pools | Real-Time Intelligence (Eventhouse) |
| Linked services | Connections |
| Triggers | Pipeline schedules and event triggers |
| Power BI on Synapse | Power BI on OneLake, often with Direct Lake |
3. Convert the SQL
Use Microsoft’s migration tooling for dedicated SQL pools to Fabric Warehouse where it applies. Then check remaining code against the Warehouse’s T-SQL limitations. Remove distribution and index options (DISTRIBUTION =, clustered columnstore settings), and review patterns such as CTAS with distribution hints, identity columns and any unsupported features.
4. Move data with shortcuts where possible
Data already in ADLS Gen2 can often be exposed through OneLake shortcuts instead of being copied. Dedicated pool tables are exported (for example as Parquet) and loaded into the Warehouse, then kept in sync for the parallel run.
5. Reconcile, repoint Power BI and decommission
Compare every table by domain, repoint Power BI semantic models to Fabric once owners sign off, then pause and delete dedicated SQL pools and Spark pools as domains move.
The short version
Inventory each Synapse component, map it to its Fabric equivalent, convert SQL with Microsoft’s tooling and fix the rest against Warehouse limitations, drop distribution settings, use shortcuts for lake data, reconcile, repoint Power BI and pause pools domain by domain.
Considering Databricks instead? Compare them in Databricks vs Microsoft Fabric. See also SQL Server and SSIS to Fabric and all migration guides.
Not sure where your own platform stands? Take the free 3-minute data platform scorecard. Unfamiliar terms are explained in the data engineering glossary.