Azure Synapse vs Microsoft Fabric: Differences and Migration Guide
Azure Synapse is a set of separately provisioned Azure services (dedicated SQL pools, serverless SQL, Spark pools, pipelines) that you wire together and pay for individually. Microsoft Fabric is a single SaaS platform that runs the same jobs, plus Power BI, on one capacity and one storage layer (OneLake). Synapse still runs and Microsoft has not announced a retirement date, but new capability ships in Fabric and Microsoft now publishes a Fabric migration guide for every Synapse workload. If you are starting fresh, choose Fabric. If you run Synapse today, plan a phased move rather than an emergency one.
Synapse vs Fabric at a glance
| Azure Synapse Analytics | Microsoft Fabric | |
|---|---|---|
| Delivery model | PaaS. You provision pools, networks, storage accounts | SaaS. You buy a capacity, create a workspace, start working |
| Compute billing | Per service: DWUs for dedicated SQL, per TB scanned for serverless SQL, vCore-hours for Spark, activity runs for pipelines | One capacity (F SKU) shared by warehouse, Spark, pipelines, Power BI, real-time |
| Storage | ADLS Gen2 you manage, plus dedicated SQL pool storage at $23/TB/month | OneLake, $0.026/GB/month hot (East US) |
| Warehouse engine | Dedicated SQL pool (MPP, indexes, distributions you tune) | Fabric Warehouse (Delta Parquet tables, no indexes or distributions to tune) |
| Ad hoc SQL over files | Serverless SQL pool, $5 per TB scanned | Lakehouse SQL analytics endpoint (included in capacity) |
| Spark | Spark 2.4 to 3.4, fixed pools, 3-node minimum, 5-minute minimum autopause | Spark 3.5 and Spark 4, pre-warmed starter pools, 1-node minimum, high-concurrency sessions, fixed 2-minute autopause |
| Orchestration | Synapse pipelines | Fabric Data Factory pipelines, Dataflow Gen2, Airflow jobs |
| Power BI | Separate service, separate licensing | Built in. F64 and above covers report viewers without Pro licenses |
| Metadata | Internal or external Hive Metastore | Internal only (lakehouse). No external HMS |
| GPU Spark, .NET for Spark | Available | Not available |
| CI/CD | Azure DevOps integration, no built-in deployment pipelines | Git integration, deployment pipelines, Fabric CLI |
| Migration path | Microsoft publishes a Fabric target and guide for each workload | Where new features ship |
Prices are East US pay-as-you-go, checked August 2026 on the Azure retail price list.
The differences that change how you work
One capacity instead of five bills
In Synapse, a dedicated SQL pool at DW100c costs $1.51 per hour whether or not anyone queries it. Spark pools bill $0.138 per vCore-hour while running. Pipelines bill per activity run. Power BI Premium is another line. Each has its own scaling, pause, and cost controls.
Fabric sells capacity units (CUs). Every workload draws from the same pool. East US pay-as-you-go is $0.18 per CU-hour, so F2 (the smallest) is $0.36 per hour, about $263 per month if left on, and F64 is $11.52 per hour, about $8,410 per month. A one-year reservation brings the CU price to about $0.107 per hour, a 40 percent saving, and pay-as-you-go capacities can be paused. Current rates are on the Microsoft Fabric pricing page, and our own Microsoft Fabric pricing guide works through the licensing rules.
The practical effect: in Synapse you tune five budgets, in Fabric you tune one, and a runaway Spark job can slow your Power BI reports because they share the capacity. Fabric's smoothing and bursting absorb short spikes, but sustained overload throttles the whole capacity. Capacity sizing matters more than it did in Synapse.
Storage you do not manage
Synapse reads and writes ADLS Gen2 accounts you create, secure, and pay for. Fabric stores everything in OneLake as Delta Parquet. Warehouse tables, lakehouse tables, and Power BI Direct Lake models read the same files, so there is no copy between the warehouse and the semantic model.
You do not have to move data out of ADLS Gen2 to use Fabric. A OneLake shortcut points at an existing container and the data shows up in a lakehouse as if it lived there. That is the fact that shapes migration planning, because it lets Fabric and Synapse read the same files during the parallel-run phase.
A simpler warehouse, with fewer knobs
Dedicated SQL pools expect you to pick distributions (hash, round robin, replicated), maintain clustered columnstore indexes, and update statistics. Fabric Warehouse removes all of that. Tables are Delta files and the engine handles layout and statistics. Microsoft's Migration Assistant documentation lists indexes and transparent data encryption under features that are "no longer needed in Fabric Data Warehouse", so neither is migrated.
The trade is T-SQL surface area. Fabric Warehouse does not support, as of August 2026:
- Indexes and transparent data encryption (not needed, not migrated)
- External tables (use OneLake shortcuts instead)
- SQL authentication (Microsoft Entra ID only)
- Column-level encryption (use dynamic data masking or application-layer encryption)
- Multi-statement table-valued functions
- Scalar UDFs unless they can be inlined (inlining is in preview)
- The datetimeoffset type (store the offset in a separate column)
- Triggers, materialized views, synonyms, and recursive queries
IDENTITY columns exist but behave differently from SQL Server, so check any code that relies on generated key sequences. Data types are mapped on the way in: nvarchar becomes varchar, nchar becomes char, money becomes decimal(19,4), smallmoney becomes decimal(10,4), datetime becomes datetime2, tinyint becomes smallint, binary becomes varbinary. Any code that depends on the old types, for example string length checks on nvarchar columns, needs a review.
Spark with faster starts and tighter limits
Fabric's starter pools are pre-warmed, so a notebook session starts in seconds rather than the minutes a Synapse pool takes to spin up. You can run single-node jobs, share one session across several users in high-concurrency mode, and use V-Order and the Native Execution Engine, which Synapse lacks.
The limits run the other way for large or unusual jobs. Maximum nodes depend on your capacity SKU rather than Synapse's flat 200-node ceiling: 2 Spark vCores equal 1 capacity unit, so F64 gives 128 vCores, or 32 Small nodes. There are no GPU pools, no .NET for Spark, no external Hive Metastore, and no workspace-level packages. Spark 2.4, 3.1, and 3.2 are not supported, so code on those runtimes must be upgraded first. Microsoft's Fabric and Synapse Spark comparison lists the differences setting by setting. mssparkutils still works but notebookutils is the path forward, and linked services have to be replaced with connector libraries or Fabric connections.
Power BI is inside, not beside
In Synapse, Power BI is a separate product with separate licensing decisions. In Fabric, the capacity you buy for data engineering also hosts Power BI. At F64 and above, report viewers do not need Pro licenses. Below F64 they still do. Direct Lake lets Power BI read OneLake Delta tables without import or DirectQuery, which removes the refresh step most Synapse plus Power BI setups depend on. The sibling post on Fabric vs Power BI covers what changes for report builders.
Do you have to migrate?
Not today. Microsoft has not announced a retirement date for Azure Synapse Analytics as of August 2026, and existing workloads keep running. Individual pieces have already gone: Synapse Data Explorer was retired on 7 October 2025 in favor of Fabric Eventhouse.
Three reasons to start planning now:
- New capabilities (Direct Lake, Copilot, mirroring, Real-Time Intelligence, OneLake security) only ship in Fabric.
- Microsoft's migration tooling is in place: the Fabric Migration Assistant for Data Warehouse, the Spark Migration Assistant, the Azure Data Factory mount item, and a per-workload guide for everything else.
- Cost control is simpler on one capacity you can pause and resize than across DWU scaling, Spark pool autopause, and per-activity pipeline billing.
Reasons to wait: you depend on GPU Spark, an external Hive Metastore, .NET for Spark, SQL-authenticated service accounts you cannot change, or a dedicated SQL pool so heavily tuned that Fabric's engine would need re-validation you cannot staff yet.
How Synapse workloads map to Fabric
| Synapse component | Fabric target | Tooling |
|---|---|---|
| Dedicated SQL pool | Fabric Warehouse | Migration Assistant (DACPAC upload, or direct source connection in preview), Copy job for data |
| Serverless SQL pool | Lakehouse SQL analytics endpoint | Shortcuts to existing ADLS Gen2, recreate views |
| Spark pools, notebooks, job definitions | Fabric Spark, notebooks, Spark job definitions, environments | Spark Migration Assistant, notebook import |
| Internal Hive Metastore | Lakehouse tables | HMS metadata migration scripts |
| Synapse pipelines | Fabric Data Factory pipelines | Pipeline export and import; ADF item mount for Azure Data Factory |
| Synapse Data Explorer | Eventhouse | Already retired; migrate if not done |
| Linked services, Key Vault via mssparkutils | Fabric connections, notebookutils.credentials | Manual |
| ADLS Gen2 data | OneLake (shortcut or copy) | Shortcuts first, copy later if at all |
Synapse to Fabric migration: step by step
Microsoft's runbook has five phases: assess, plan, migrate, monitor, optimize. This is how that plays out on a real project.
1. Inventory everything
List every dedicated SQL pool, serverless database, Spark pool, notebook, job definition, pipeline, linked service, and downstream consumer (Power BI semantic models, applications, external tools). Record who owns each, how often it runs, and what it costs. Most inventories turn up objects nobody uses. Drop them rather than migrate them.
2. Run the compatibility assessment
For the warehouse, export a DACPAC from the dedicated SQL pool and load it into the Migration Assistant. It converts the schema, reports every table, view, function, stored procedure, and security object it could not translate, and sorts the failures by how many other objects depend on them so you fix the most-referenced ones first. Copilot can propose fixes. Check them before running.
For Spark, run the Spark Migration Assistant against the workspace and list notebooks on unsupported runtimes, code that calls linked services, .NET notebooks, and external HMS dependencies. Each is manual work.
Quantify the refactoring hours before you commit to a date.
3. Size and provision the Fabric capacity
Start with a pay-as-you-go capacity one size larger than your estimate, run the parallel phase, then buy a reservation once the Capacity Metrics app shows steady usage. Create the workspace, enable Git integration, and set up Entra ID groups to replace SQL logins. Apply workspace roles (Admin, Member, Contributor, Viewer) and OneLake security before any data lands.
4. Shortcut the data, then migrate the schema
Create OneLake shortcuts to your ADLS Gen2 containers. This gives Fabric read access to current data with no copy and no downtime. Then apply the converted warehouse schema, fix the flagged objects, and use a Fabric Copy job to load historical warehouse data. Scale the dedicated SQL pool up temporarily during bulk extraction if it is the bottleneck.
5. Rebuild pipelines and notebooks
Import pipelines into Fabric Data Factory and repoint sources and sinks. Import notebooks, switch to notebookutils, replace linked service calls, and attach an environment with the libraries and Spark properties your Synapse pool had. Upgrade code to Spark 3.5 if it is older. V-Order and Optimized Write are on by default in Fabric, so re-test write performance.
6. Run both in parallel
Run incremental loads into both platforms for at least two full business cycles (month-end twice, for most companies). Compare row counts, checksums, and report totals. Benchmark the slowest queries. Fabric Warehouse often needs different patterns (fewer wide updates, more set-based merges) to match a tuned dedicated pool. This is also when you repoint a small group of Power BI reports to Direct Lake and check refresh-free reporting works.
7. Cut over and decommission
Switch application connection strings and Power BI sources to Fabric. Pause, then delete, the dedicated SQL pool. Delete Spark pools. Keep the ADLS Gen2 data in place if shortcuts reference it, or copy it into OneLake and retire the storage account. Cancel Synapse reservations at renewal. Set Fabric capacity alerts so the first month's bill is not a surprise.
Lift and shift or redesign?
Lift and shift works when you have one or two pools, a clean star schema, and time pressure. You accept Fabric's type mappings, fix what breaks, and change nothing else.
Redesign is worth it when the warehouse has grown over years, when stored procedures hold logic that belongs in Spark or Dataflow Gen2, or when you want Direct Lake reporting from day one. Most redesigns land on a medallion layout: raw files in a bronze lakehouse, cleaned Delta tables in silver, and either a gold lakehouse or a Fabric Warehouse for reporting. Our guide to lakehouse vs warehouse in Fabric covers which to pick for the gold layer.
A middle path is common: lift the warehouse as-is to get off Synapse, then move transformation logic out of stored procedures one subject area at a time.
Cost comparison for a typical mid-sized setup
Prices are East US pay-as-you-go, August 2026, rounded. Your workload will differ. The point is the shape of the bill.
| Line item | Synapse | Fabric |
|---|---|---|
| Warehouse compute | DW500c at $7.55/hr, 12 hrs/day, 22 days: about $1,990/month | F32 at $5.76/hr, same hours, paused nights and weekends: about $1,520/month |
| Spark | 3-node Medium pool, 40 hrs/month: about $130/month | Included in capacity |
| Pipelines | Per activity run and data movement hour: tens to low hundreds per month | Included in capacity |
| Warehouse storage | $23/TB/month | OneLake $0.026/GB/month (about $27/TB) |
| Power BI for 50 viewers | 50 Pro licenses | F32 is below the F64 threshold, so 50 Pro licenses still apply |
Two things to notice. Fabric's bundled pricing wins most clearly when you already pay for several Synapse services and Power BI Premium. It wins less clearly for a single always-on warehouse and nothing else, where a reserved DWU commitment is competitive. Model your own pattern before assuming savings.
FAQ
Is Azure Synapse being retired?
Microsoft has not published a retirement date for Azure Synapse Analytics as of August 2026, and existing workloads keep running. Microsoft does publish a Fabric migration guide for every Synapse workload, and new capability ships in Fabric.
Can I run Synapse and Fabric at the same time?
Yes. Fabric can read your existing ADLS Gen2 storage through OneLake shortcuts without copying data, so most teams run both in parallel during migration and cut over one workload at a time.
Does my Synapse T-SQL code work in Fabric Warehouse?
Most of it does, but not all. Fabric Warehouse has no indexes, external tables, SQL authentication, datetimeoffset, or multi-statement table-valued functions, and data types such as nvarchar and money are mapped to varchar and decimal. The Migration Assistant flags what breaks.
How long does a Synapse to Fabric migration take?
A single well-designed dedicated SQL pool with a handful of pipelines takes a few weeks. An estate with many pools, Spark notebooks, and hundreds of stored procedures takes months because code has to be refactored and run in parallel before cutover.
Is Fabric cheaper than Synapse?
Often for small and mid-sized teams, because one Fabric capacity replaces separate bills for dedicated SQL, Spark, pipelines, and Power BI Premium. For large, always-on warehouses the answer depends on how much compute you need, so price it with your actual workload before deciding.
Where Maxwize fits
Maxwize runs Synapse to Fabric migrations for small and mid-sized companies: inventory and compatibility assessment, capacity sizing, Migration Assistant and Spark refactoring, parallel-run validation, and Power BI cutover to Direct Lake. Data analytics projects range from $1,000 to $20,000 depending on the number of pools, notebooks, and reports. See the Microsoft Fabric services page or get in touch with your Synapse inventory and we will tell you how long the move should take.