For most teams, this creates real friction. A Synapse + ADF + Power BI stack means jumping between tools, refactoring T-SQL that doesn't play nicely across services, and watching Power BI reports slow to a crawl as datasets grow. Fabric's answer, OneLake and Direct Lake, addresses much of this directly.
This guide walks through why organizations are migrating, how Fabric differs from Synapse and Data Factory, a step-by-step migration process, the pitfalls that catch teams off guard, and where a partner like Hexaview fits into de-risking the move.
Key Takeaways
- Migration is additive: Synapse stays live until you're ready to cut over
- Microsoft's migration assistants handle roughly 70-80% of pipelines, Spark jobs, and SQL objects automatically
- OneLake and Direct Lake remove duplicate data copies, often improving Power BI performance
- A phased, workload-by-workload rollout beats a big-bang cutover for risk reduction
- Regulated industries (fintech, wealth management, healthcare) benefit from expert assessment before migrating
Why Migrate from Azure Synapse to Microsoft Fabric
Where Microsoft Is Investing
Fabric brings Data Engineering, Data Factory, Data Warehouse, and Power BI into one SaaS workspace built on OneLake. Microsoft's Fabric overview documentation describes it as a unified analytics platform with shared compute — a clear step beyond Synapse's separately managed SQL, Spark, and pipeline services.
That unification isn't cosmetic. OneLake's single-copy architecture means data doesn't need to be duplicated across a lake, a warehouse, and a BI semantic model. Fewer copies means fewer ETL jobs moving data around, which translates directly into lower storage and pipeline costs.
Synapse's Structural Limits
Synapse wasn't built for this world. A few constraints worth knowing:
- 128 concurrent query cap on dedicated SQL pools — extra queries queue once you hit the limit
- Manual scaling only — DWU changes still mean moving a slider in the Azure portal, not auto-elasticity
- Restricted T-SQL support — gaps around scalar UDFs and multi-statement table-valued functions
- Fragmented governance — controls sit across separate services instead of one workspace model
And the retirement clock has already started ticking on at least one component. Synapse Data Explorer was officially retired on October 7, 2025, with Microsoft directing all users to migrate to Fabric Eventhouse. It's the clearest signal yet of where the platform is heading.
None of this means Synapse stops working tomorrow. Dedicated SQL pools, Spark, and pipelines remain supported. New feature investment, though, is landing in Fabric — and that gap will keep growing.
Azure Synapse vs. Microsoft Fabric vs. Data Factory
A question we hear constantly: is Azure Data Factory the same thing as Synapse? Not quite.
| Service | Role |
|---|---|
| Azure Data Factory | Standalone orchestration service — pipelines and data movement only |
| Azure Synapse | Broader analytics workspace bundling SQL pools, Spark, and pipeline capability |
| Microsoft Fabric | Unified successor that natively includes Data Factory-equivalent capabilities, plus SQL, Spark, and BI |
Fabric essentially absorbs both. According to Microsoft's Fabric Data Factory comparison page, Fabric Data Factory is positioned as the next generation of ADF, with Dataflows Gen2 replacing Mapping Data Flows.
Architecture and storage differ too:
- Synapse dedicated SQL pools use provisioned DWUs; Fabric uses serverless capacity units (F-SKUs)
- Synapse stores data in a proprietary format; Fabric stores everything as open Delta Parquet in OneLake
- Synapse governance runs per-service (separate RBAC for SQL, Spark, pipelines); Fabric governance is workspace-based
Terminology teams need to relearn:
- Dedicated SQL Pool → Fabric Data Warehouse
- Synapse Studio → Fabric workspace
- MSSparkUtils → NotebookUtils
None of this is difficult conceptually, but it does mean training time. Budget for it.
How to Migrate from Azure Synapse to Microsoft Fabric: Step-by-Step
Step 1: Assessment and Compatibility Analysis
Start inside Synapse Studio under Integrate > Migrate to Fabric (Preview). This built-in assessment flags pipelines, Spark pools, SQL objects, and linked services as Ready, Needs Review, or Not Compatible.
Before touching your SQL pools, export a DACPAC to surface T-SQL incompatibilities early — things like:
- Distribution statements
- OPENROWSET references
- PolyBase-dependent objects
Resolve these before warehouse migration so they do not block schema conversion later.
Step 2: Migrating Apache Spark Workloads
Spark should move first, since pipelines frequently depend on notebooks downstream. Use the Fabric Spark Migration Assistant, which maps Spark pools to Fabric equivalents and creates OneLake shortcuts for Delta tables.
Refactor mssparkutils calls to notebookutils. The old namespace still works for now, but it is being phased out.
Step 3: Migrating Dedicated SQL Pools to Fabric Data Warehouse
The Fabric Data Warehouse Migration Assistant accepts a DACPAC upload or a direct connection, converts your schema, then copies data via a Fabric Data Factory copy job.
Expect to remediate:
- Scalar UDFs
- External tables
- Multi-statement TVFs
- Identity and SQL-authentication differences
Full T-SQL compatibility is not guaranteed, so test schema, security, and application connections thoroughly before moving forward.
Step 4: Migrating Pipelines and Orchestration
With Spark and warehouse objects in place, pipelines are usually where timelines slip. Map Synapse Linked Services to Fabric Connections, then rebuild Mapping Data Flows as Dataflows Gen2. There is no bulk-import for orchestration logic — branching, parameterization, and trigger configuration need manual rebuilding.
Triggers are disabled by default after migration. Reconfigure them only after validating credentials and connections.
Step 5: Validation, Parallel Running, and Cutover
- Run Synapse and Fabric in parallel for 2-4 weeks
- Compare row counts and business logic outputs between environments
- Test Power BI connections against Fabric endpoints before switching
- Reconnect production datasets once validation passes
- Decommission Synapse workload by workload, not all at once
Common Migration Challenges and Best Practices
There's no one-click button here. Each workload type — Spark, SQL, pipelines — needs its own tooling and its own manual refactoring pass for Synapse-specific syntax.
The most common planning mistake: underestimating pipeline migration timelines by 3-5x. Complex branching logic and parameterized activities can't be automated away; they need to be rebuilt by hand, and that takes longer than most teams expect.
A few best practices worth adopting from day one:
- Phase it: PoC → core workloads → edge cases → decommission, rather than a big-bang cutover
- Git early: Set up Git integration so schema and pipeline changes are version-controlled from the start
- Capacity Metrics first: Install the Fabric Capacity Metrics app before load testing to catch throttling and overload before users do
- Governance upfront: Plan security and compliance redesign early if you're in a regulated industry
That last point matters more than it might seem. Hexaview has spent more than 10 years working inside regulated data environments, building HIPAA-compliant platforms that integrate patient and claims data, and running fintech data lake implementations for firms like LPL Financial and Addepar.
That compliance-first experience tends to surface risks during assessment that generic migration checklists miss entirely.
Migration Tools and Cost Considerations
Native Microsoft Migration Tools
Microsoft's native tooling covers most of the heavy lifting:
- Fabric Spark Migration Assistant — guided Spark pool and notebook migration
- Fabric Data Warehouse Migration Assistant — DACPAC-based SQL pool conversion
- Pipeline upgrade wizard — maps linked services and migrates supported pipelines
- Fabric Assessment Tool (from Microsoft Fabric Toolbox on GitHub) — a command-line inventory tool covering linked services, Spark resources, SQL pools, and pipelines
Cost Model Differences
Fabric is priced in F-SKU capacity units rather than per-service billing. That changes how you plan capacity:
| Model | How it's priced |
|---|---|
| Synapse | Separate billing for dedicated SQL, serverless SQL, Spark, pipelines, and storage |
| Fabric | Shared capacity units (F-SKUs), pay-as-you-go or reserved |
Consolidating into one capacity pool and eliminating duplicate data copies via OneLake often lowers total spend. Savings still hinge on your utilization and concurrency patterns, so baseline cost and performance before and after the move.
Frequently Asked Questions
How do I migrate data from Synapse to Fabric?
Most teams use OneLake Shortcuts for no-copy access to existing ADLS Gen2 data. For SQL pool data, the Fabric Data Warehouse Migration Assistant with a DACPAC export handles schema conversion. Choose based on whether you need a live connection or a full cutover.
What are the best tools for a Synapse to Fabric migration?
Microsoft's native Migration Assistants (Spark, Warehouse, Pipeline) handle most workload conversions directly inside Fabric. The Fabric Assessment Tool from Microsoft Fabric Toolbox on GitHub adds a repeatable inventory step before you begin.
What is Azure Synapse vs ADF?
Azure Data Factory is an orchestration-only service for pipelines and data movement. Synapse is a broader analytics workspace bundling SQL pools, Spark, and pipelines together. Fabric now consolidates both under one platform.
Is Azure Synapse being retired?
Synapse Data Explorer was officially retired on October 7, 2025, with Fabric Eventhouse as the recommended replacement. Dedicated SQL Pools, Spark, and Pipelines remain supported, but they're no longer receiving new feature investment.
How long does a Synapse to Fabric migration typically take?
Timelines depend more on pipeline complexity and workload volume than on data size alone. Front-loading assessment and phased testing shortens delivery; skipping those steps usually surfaces incompatibilities mid-project and extends the schedule.
Does my Power BI setup break during migration?
No. Power BI reports stay connected to Synapse until you manually update connection strings after validation. This keeps existing dashboards live and minimizes disruption while you test the new Fabric endpoints.
