Migrating from Azure Synapse to Microsoft Fabric: What to Expect

Microsoft Fabric is the unified analytics platform that Microsoft is positioning as the successor to Azure Synapse Analytics. If your organisation runs Synapse today, you will eventually face the migration question. This guide covers what changes, what stays the same, and how to approach the migration without derailing your production analytics workloads.

What Microsoft Fabric actually is

Fabric is not a rebrand of Synapse. It is a new SaaS platform that bundles multiple analytics services — data integration, data engineering, data warehousing, real-time analytics, data science, and Power BI — into a unified workspace with a shared metadata layer called OneLake.

The warehouse component (Synapse Data Warehouse in Fabric) uses the same T-SQL surface area as Synapse Dedicated SQL Pools but is serverless and fully managed. There is no infrastructure to provision. Billing shifts from provisioned DWU capacity to Fabric capacity units (CUs), which are shared across workloads.

The data engineering component (Lakehouse) replaces Synapse Spark. It uses Delta Lake as the open table format, same as Synapse Spark with Delta, but integrates more tightly with OneLake.

Synapse Pipelines is replaced by Data Factory within Fabric — same drag-and-drop pipeline builder, same connectors, same general architecture, but hosted natively within the Fabric workspace.

What changes in the migration

**Storage model**: Synapse uses Azure Data Lake Storage Gen2 (ADLS Gen2) as the storage layer, managed by your team. Fabric uses OneLake, a managed multi-cloud object store that abstracts the underlying storage. Your data lives in OneLake, not in a storage account you control directly. OneLake supports shortcuts — virtual mounts of external storage — so you can still reference ADLS Gen2 data without copying it, but the primary storage model is different.

**Compute model**: Synapse Dedicated SQL Pools require you to size and provision DWU capacity in advance. You pay for that capacity whether or not you use it. Fabric's warehouse is serverless — compute scales automatically and you pay per CU consumption. For variable workloads, this is economically favorable. For steady, high-utilisation workloads, dedicated capacity may cost more at equivalent throughput.

**Workspace and governance model**: Synapse uses workspaces scoped to specific Synapse instances. Fabric uses a workspace model that spans multiple artifact types (lakehouses, warehouses, notebooks, pipelines, Power BI datasets) under one governance boundary. Access control, endorsement, and lineage tracking work at the workspace level across all artifact types.

**Metadata and discoverability**: OneLake provides a unified semantic layer. Tables defined in a Fabric Lakehouse are automatically available to Power BI without a separate dataset publish step. This is a significant DX improvement but requires rethinking how you manage model-layer separation.

What stays the same

**T-SQL**: If you are migrating from Synapse Dedicated SQL Pools, your T-SQL queries will largely work in Fabric Warehouse without modification. Window functions, CTEs, stored procedures, views — all supported. Performance characteristics differ (no distribution keys in Fabric Warehouse), but the query surface is compatible.

**Delta Lake**: If you use Synapse Spark with Delta Lake tables, Fabric Lakehouse uses Delta natively. Delta tables created externally can be shortcutted into OneLake and read without copying data.

**Power BI integration**: Power BI was already deeply integrated with Synapse. In Fabric, it is even tighter — Power BI is a first-class workload within Fabric, not a separate service consuming Synapse data.

**Apache Spark**: Fabric Spark is compatible with Synapse Spark. PySpark notebooks, Spark SQL, Delta operations — same API surface. The runtime versions differ, so library dependency management may need attention.

Migration approach

**Phase 1: Inventory and assess**. Document everything in your Synapse environment: SQL pools (dedicated and serverless), Spark pools, pipeline definitions, linked services, datasets, triggers, external tables, and Power BI datasets that reference Synapse. The Synapse Metadata API and Azure Resource Graph can automate much of this inventory. Flag objects with distribution keys (HASH, ROUND_ROBIN, REPLICATE) — Fabric Warehouse does not use distribution strategies, so queries relying on co-location of distributed data may need query rewrites.

**Phase 2: Target architecture design**. Decide which Synapse components map to which Fabric components. Synapse Dedicated SQL Pool → Fabric Warehouse. Synapse Serverless SQL → Fabric Lakehouse SQL endpoint. Synapse Spark → Fabric Lakehouse + Notebooks. Synapse Pipelines → Fabric Data Factory. This is not always one-to-one — some workloads may be better served by a Lakehouse + DirectLake Power BI model than a Warehouse + Import model.

**Phase 3: Migrate in layers**. Start with pipelines and data movement — these have the lowest production risk. Replicate Synapse pipelines in Fabric Data Factory, validate that data lands correctly in OneLake. Next migrate the transformation layer — stored procedures, SQL scripts, dbt models if applicable. Last migrate the reporting layer — update Power BI datasets to reference Fabric endpoints rather than Synapse endpoints.

**Phase 4: Parallel run and cutover**. Run both environments in parallel during UAT. Validate row counts, aggregation results, and performance benchmarks against production baselines. Cutover in a planned maintenance window with rollback plan ready.

Performance considerations

Fabric Warehouse does not have distribution keys, so queries that in Synapse were optimised around HASH distribution on join keys will lose that optimisation. For large fact-to-dimension joins, this may require query rewrites or materialised CTEs to force hash join behavior. For most reporting workloads at typical enterprise data volumes (under a few hundred billion rows), Fabric Warehouse performance is adequate without distribution tuning.

Extract caching via DirectLake (for Power BI) eliminates import latency for dashboards — Power BI reads Delta tables directly from OneLake without an intermediate import. For dashboards that previously relied on Synapse as the query engine with Power BI import, DirectLake is a significant performance and freshness improvement.

Timing

Microsoft has announced end-of-mainstream-support milestones for Synapse Dedicated SQL Pools. The migration window is several years, but the longer you wait, the more migration work accumulates. If you are building new analytics infrastructure today, build on Fabric. If you are on Synapse, begin the inventory and architecture assessment now — the migration itself is not trivially fast for complex environments.

For hands-on migration support, our cloud engineering and data architecture practices have executed Synapse-to-Fabric migrations across several enterprise clients. Book a free architecture review to assess your current environment and draft a migration roadmap.

A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.