Migrate Azure Synapse to Microsoft Fabric.

Why moving Azure Synapse to Microsoft Fabric is four migrations, not one

An Azure Synapse workspace looks like a single product, but it’s a collaboration boundary around four separate engines: Synapse pipelines, Spark notebooks, dedicated SQL pools and serverless SQL. Each has its own runtime, its own dialect and its own migration considerations, and the most expensive mistake is treating them as one. The logic that runs your business rarely lives inside any single workload. It lives in the seams between them. A Spark notebook lands Delta; serverless SQL exposes views over that Delta; a dedicated SQL pool holds the modeled warehouse; and a pipeline orchestrates all three. The end-to-end behavior only exists across those handoffs. Microsoft positions Fabric as the go-forward platform for exactly this estate, and provides first-party assistants for the warehouse, Spark and pipeline workloads, but a faithful rebuild still has to follow data across the Spark-to-serverless-to-dedicated boundaries, not document each pool in isolation. That’s the job of the Documenter before anything is built. Autonomous in the loop, accountable at the gates.

What breaks in a naive lift-and-shift

The seductive idea is to copy each workload straight across. It fails on contact with the targets, and the failures are specific. Dedicated SQL pool physical design (HASH, ROUND_ROBIN and REPLICATE distributions across 60 distributions, single-column partitioning tuned to the MPP architecture) has no equivalent on the Fabric Warehouse, which stores everything as Delta tables in OneLake. None of that distribution tuning maps directly; it must be re-derived, not pasted. Dedicated-pool stored procedures are already a reduced T-SQL dialect (an 8-level nesting cap, no @@NESTLEVEL, no INSERT...EXECUTE), and the Warehouse imposes its own surface-area limits: no triggers, no materialized views, no synonyms, no recursive queries, and primary/unique/foreign keys only as NOT ENFORCED metadata. Serverless SQL adds its own trap: it reads Delta at reader version 1 only, so a view that worked over older files may point at a Delta feature the engine cannot read once data is upgraded. Spark notebooks mostly carry over, but %run (shared variable context) and mssparkutils.notebook.run (isolated) behave differently and have to be told apart before logic is reassembled. A lift-and-shift that ignores these breaks loudly at best and silently at worst.

How the fleet maps each workload onto Fabric

The dedicated SQL pool becomes the Fabric Warehouse: T-SQL tables, views, stored procedures and functions, with full multi-table ACID transactions and MERGE generally available, which is why hand-rolled SCD Type 2 loops often collapse into a single MERGE statement, or, on the dbt flavor, into a dbt snapshot that maintains dbt_valid_from, dbt_valid_to and dbt_scd_id for you. Serverless SQL maps to the SQL analytics endpoint that every Lakehouse provisions automatically (a read-only T-SQL surface over /Tables Delta data on the same engine as the Warehouse) with OPENROWSET(BULK ...) in the Warehouse covering the query-in-place cases. Spark notebooks become Fabric notebooks running PySpark on the default Live Pool against Delta tables. Synapse pipelines become Fabric Data pipelines: the dependsOn activity graph, the If Condition / Switch / For Each / Until control flow and the success and failure paths all carry across, with linked services and datasets becoming Connections and a tumbling-window trigger becoming an interval-based schedule.

The build-test-run loop, and the gates

Both delivery flavors run through the same loop. On the dbt flavor the Builder produces models, sources, snapshots and tests against the Warehouse via the dbt-fabric adapter, with merge as the default incremental strategy and the DAG built from ref() and source(). On your framework, the Builder produces native Fabric artifacts (pipelines, notebooks, Warehouse procedures) in your own orchestration. The Test agent runs the rebuilt logic and the fleet iterates until green: a distribution clause rejected, a nesting limit hit, a serverless view pointing at a Delta v2 feature, each caught and corrected until row counts, current-version counts and checksums match the Synapse baseline. Three human gates bound the autonomy (assessment, design and promotion) so nothing reaches production without a person signing off. If your destination is the other platform instead, see Migrate Azure Synapse to Databricks; the workload mapping changes, the discipline does not.