1. Compare components, not just SaaS vs PaaS

Fabric simplifies parts of platform operations, but does not remove capacity planning, connection ownership or recovery design. Synapse’s modular controls are useful only where your workload actually needs them. Neither ‘all new projects must migrate’ nor ‘nothing can migrate until perfect parity’ is a useful policy.

2. Dedicated SQL pool to Warehouse: automation now exists

The earlier claim that there is no automated Warehouse migration tool is outdated. Microsoft’s Fabric Migration Assistant for Data Warehouse supports Azure Synapse dedicated SQL pool sources. It can ingest source definitions through supported files or connections, convert schema, flag incompatibilities and copy data through a Fabric copy job.

Its workflow explicitly includes fixing unsupported definitions, testing/comparing the old and new warehouses and rerouting applications only after validation. Some security objects can migrate, but failed/unsupported mappings need review before data access is exposed. SQL authentication, unsupported types and differing identity behavior are examples of migration work—not reasons to trust generated scripts blindly.

• Inventory procedures, views, distributions, materialized views, constraints, permissions and client dependencies.
• Check Warehouse’s current T-SQL support. MERGE is GA; ALTER COLUMN is currently Preview. Full SQL Server/Synapse compatibility is not promised.
• Reassess physical tuning rather than translating dedicated-pool distribution/index choices mechanically.
• Validate multi-step transactions, conflicts, retries, decimals, collations, timestamps and business results.

A converted schema is the start of migration acceptance, not the finish.

3. Spark migration: code portability is only one part

Use Microsoft’s Fabric-versus-Synapse Spark capability matrix and capture the runtime each existing job actually uses. Fabric Runtime 2.0 introduces major Spark/Delta/language changes; copied notebook code is not an end-to-end compatibility test.

• Validate custom JARs, Python/R libraries, filesystem paths, table registration and Delta protocol features.
• Replace workspace-specific IDs, mounts/secrets assumptions and connections through supported Fabric mechanisms.
• Check unsupported APIs/languages, including existing .NET-for-Spark dependencies, against the current capability table before promising a direct import.
• Test the scheduled execution identity and source/destination authorization, not only the notebook author.
• Measure session startup, execution, concurrency and retry behavior separately; shared sessions do not guarantee identical cost or isolation.

Do not describe Git as universally enabled or every Fabric item as supported. Deployment support is item-specific, and connection/secret bindings still need environment-aware handling.

4. Pipelines and operational replication need their own assessment

A Synapse pipeline combines orchestration, source connections, compute activities and dependencies. Dataflow Gen2 is a transformation tool, not a wholesale replacement for pipeline orchestration.

Use the supported upgrade/assessment path for the actual source and component. Current ADF-to-Fabric upgrade guidance is useful, but a capability documented for ADF is not proof that every Synapse artifact, trigger or integration runtime migrates identically. Check the live source-support matrix before selecting an automated path.

For each pipeline, validate connectors, private networking, authentication, expression evaluation, parameter/variable resolution, retry/cancellation semantics and failure notifications. Keep triggers/schedules disabled in the target until owner-approved test loads reconcile and cannot duplicate production writes.

Likewise, Fabric Mirroring is source-specific. Do not assume one generic mirror replaces all Synapse Link configurations. Confirm supported source/version, object selection, update/delete behavior, types, recovery and pricing before redirecting consumers.

5. Pricing: compare equivalent production commitments

Synapse components have different meters: dedicated SQL compute, serverless SQL scanned data, Spark, pipeline operations and storage. Fabric consolidates many workloads onto capacity, but storage, licenses, networking and optional separate billing remain.

Use observed utilization and concurrency, not a fixed ‘one F-SKU covers everything for free’ assumption. A workload that fits alone can contend with BI or another engineering job on shared capacity. A paused capacity is unavailable; storage/reservations do not vanish. An existing Synapse reservation is a commitment to account for, not a reason by itself to keep every workload forever.

Include migration engineering, dual running, data movement, support and rollback costs. Mirroring storage allowances have supported-scenario and capacity conditions; they are not a free-storage entitlement for every Fabric table. F64+ viewer eligibility also has Power BI license/workspace conditions; authors still need appropriate licenses.

6. When to stay, move or run both

Stay for now when the existing service meets the SLA, a required dependency is unsupported, or measured migration value does not justify cost/risk. Do not invent a Synapse retirement date or claim that support ended simply because Fabric is the strategic direction.

Pilot Fabric when integrated consumption, current supported features or operational simplification solves a demonstrated problem. Start with one product and a clear acceptance contract.

Run both temporarily or deliberately when ownership and serving boundaries are explicit. Dual running without reconciliation, cost ownership and exit criteria becomes permanent complexity rather than a migration strategy.

1. Inventory dependencies and classify each workload’s target.
2. Agree freshness, correctness, security, performance, recovery and full-cost acceptance criteria.
3. Use supported migration tooling in a nonproduction target; review generated definitions and security.
4. Run representative incremental loads, failures/retries and restricted-user tests.
5. Reconcile both systems, rehearse cutover and rollback, then obtain consumer/owner sign-off.
6. Redirect schedules/connections in a controlled window. Retain recovery evidence before decommissioning anything.

Common questions

Official references and review scope

Checked against the following Microsoft documentation on 2026-10-30. This is an independent comparison, not a vendor endorsement or a benchmark report. Recommendations are conditional on workload requirements. No customer deployment, savings result or performance benchmark is claimed; validate the design and current feature availability in your environment.

• Warehouse Migration Assistant and supported source systems
• Plan Synapse dedicated SQL pool migration
• Compare Synapse and Fabric Spark capabilities
• Fabric Warehouse T-SQL support
• Fabric Warehouse data types
• ADF-to-Fabric upgrade best practices: verify source applicability
• Fabric licensing and capacity conditions

Take the next practical step

Practice Fabric interview scenarios