# Azure Synapse vs Microsoft Fabric: Differences and Migration Guide Author: Nikhil Bhansali S Author URL: https://maxwize.in/blog/author/nikhil-bhansali-s Published: 2026-08-25 Category: Microsoft Fabric & Power BI Category URL: https://maxwize.in/blog/category/microsoft-fabric-and-power-bi Meta Title: Azure Synapse vs Microsoft Fabric: Migration Guide Meta Description: Synapse vs Fabric explained: what changed, what it costs, and a step-by-step Synapse to Fabric migration plan for dedicated SQL pools and Spark. Tags: Migration, Comparison Tag URLs: Migration (https://maxwize.in/blog/tag/migration), Comparison (https://maxwize.in/blog/tag/comparison) URL: https://maxwize.in/blog/azure-synapse-vs-microsoft-fabric-migration # 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 AnalyticsMicrosoft FabricDelivery modelPaaS. You provision pools, networks, storage accountsSaaS. You buy a capacity, create a workspace, start workingCompute billingPer service: DWUs for dedicated SQL, per TB scanned for serverless SQL, vCore-hours for Spark, activity runs for pipelinesOne capacity (F SKU) shared by warehouse, Spark, pipelines, Power BI, real-timeStorageADLS Gen2 you manage, plus dedicated SQL pool storage at $23/TB/monthOneLake, $0.026/GB/month hot (East US)Warehouse engineDedicated SQL pool (MPP, indexes, distributions you tune)Fabric Warehouse (Delta Parquet tables, no indexes or distributions to tune)Ad hoc SQL over filesServerless SQL pool, $5 per TB scannedLakehouse SQL analytics endpoint (included in capacity)SparkSpark 2.4 to 3.4, fixed pools, 3-node minimum, 5-minute minimum autopauseSpark 3.5 and Spark 4, pre-warmed starter pools, 1-node minimum, high-concurrency sessions, fixed 2-minute autopauseOrchestrationSynapse pipelinesFabric Data Factory pipelines, Dataflow Gen2, Airflow jobsPower BISeparate service, separate licensingBuilt in. F64 and above covers report viewers without Pro licensesMetadataInternal or external Hive MetastoreInternal only (lakehouse). No external HMSGPU Spark, .NET for SparkAvailableNot availableCI/CDAzure DevOps integration, no built-in deployment pipelinesGit integration, deployment pipelines, Fabric CLIMigration pathMicrosoft publishes a Fabric target and guide for each workloadWhere 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](https://azure.microsoft.com/en-us/pricing/details/microsoft-fabric/), and our own [Microsoft Fabric pricing guide](https://maxwize.in/blog/microsoft-fabric-pricing) 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](https://learn.microsoft.com/en-us/fabric/data-warehouse/migration-assistant) 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](https://learn.microsoft.com/en-us/fabric/data-engineering/comparison-between-fabric-and-azure-synapse-spark) 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](https://maxwize.in/blog/microsoft-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: 1. New capabilities (Direct Lake, Copilot, mirroring, Real-Time Intelligence, OneLake security) only ship in Fabric. 2. 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. 3. 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 componentFabric targetToolingDedicated SQL poolFabric WarehouseMigration Assistant (DACPAC upload, or direct source connection in preview), Copy job for dataServerless SQL poolLakehouse SQL analytics endpointShortcuts to existing ADLS Gen2, recreate viewsSpark pools, notebooks, job definitionsFabric Spark, notebooks, Spark job definitions, environmentsSpark Migration Assistant, notebook importInternal Hive MetastoreLakehouse tablesHMS metadata migration scriptsSynapse pipelinesFabric Data Factory pipelinesPipeline export and import; ADF item mount for Azure Data FactorySynapse Data ExplorerEventhouseAlready retired; migrate if not doneLinked services, Key Vault via mssparkutilsFabric connections, notebookutils.credentialsManualADLS Gen2 dataOneLake (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 itemSynapseFabricWarehouse computeDW500c at $7.55/hr, 12 hrs/day, 22 days: about $1,990/monthF32 at $5.76/hr, same hours, paused nights and weekends: about $1,520/monthSpark3-node Medium pool, 40 hrs/month: about $130/monthIncluded in capacityPipelinesPer activity run and data movement hour: tens to low hundreds per monthIncluded in capacityWarehouse storage$23/TB/monthOneLake $0.026/GB/month (about $27/TB)Power BI for 50 viewers50 Pro licensesF32 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](https://maxwize.in/services/data-analytics/microsoft-fabric) or [get in touch](https://maxwize.in/contact) with your Synapse inventory and we will tell you how long the move should take. ## FAQs Q: Is Azure Synapse being retired? A: 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. Q: Can I run Synapse and Fabric at the same time? A: 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. Q: Does my Synapse T-SQL code work in Fabric Warehouse? A: 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. Q: How long does a Synapse to Fabric migration take? A: 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. Q: Is Fabric cheaper than Synapse? A: 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. --- This blog is powered by Superblog. Visit https://superblog.ai to know more. ---