An Azure Synapse workspace can contain dedicated and serverless SQL, pipelines, Spark pools and notebooks, Data Explorer or KQL assets, linked services, integration runtimes, triggers, managed identities, private networking, libraries, code repositories, monitoring, and dependent Power BI or applications. There is no single button that converts this operating system into Microsoft Fabric with equivalent behavior.
Datrick treats migration as workload modernization with controlled evidence. AI can accelerate discovery, code classification, dependency extraction, compatibility analysis, conversion candidates, test generation, and reconciliation review. It cannot approve business logic, hide unsupported behavior, or declare parity without deterministic source-to-target tests and accountable owners.
Considering Fabric but unsure which Synapse workloads are portable or worth moving? Start with an estate assessment and one representative pilot.
Build a usage-backed Synapse estate inventory
Collect workspaces, SQL pools and objects, pipelines, activities, triggers, linked services, datasets, integration runtimes, notebooks, Spark configurations and libraries, KQL assets, storage, Synapse Link, identities, secrets, network controls, Git and release paths, schedules, dependencies, monitoring, incidents, costs, performance, data volumes, SLAs, owners, users, and downstream consumers.
Usage matters. A deployed object is not automatically a migration requirement. Classify active, seasonal, regulatory, duplicated, obsolete, experimental, and unknown assets. Confirm business purpose and owner before estimating conversion. Retiring unused pipelines and reports can remove more risk and cost than translating them.
Map each workload to a target pattern
| Synapse workload | Potential Fabric target | Assessment focus |
|---|---|---|
| Dedicated SQL pool | Fabric Data Warehouse, Lakehouse, or retained/coexisting Synapse based on requirements. | DDL and DML compatibility, distribution-specific design, procedures, security, data load, query patterns, concurrency, performance, and cost. |
| Serverless SQL | Lakehouse SQL analytics endpoint, Fabric Warehouse, shortcuts, or redesigned serving pattern. | External table and file behavior, formats, functions, permissions, performance, consumers, and query semantics. |
| Synapse pipelines | Fabric Data Factory pipelines, dataflows, notebooks, copy jobs, or retained hybrid orchestration. | Activities, connectors, parameters, triggers, credentials, integration runtime, networking, retries, dependencies, and operational behavior. |
| Spark pools and notebooks | Fabric Spark notebooks, environments, Lakehouse, jobs, or coexistence. | Runtime and library compatibility, session configuration, mounts, secrets, data paths, scale, scheduling, performance, and tests. |
| Data Explorer and KQL | Fabric Eventhouse/KQL Database, Real-Time Intelligence, or retained Azure Data Explorer. | Ingestion, retention, functions, update policies, dashboards, query behavior, streaming, security, performance, and recovery. |
| Synapse Link and replication | Fabric Mirroring, shortcuts, pipelines, or source-specific integration. | Supported sources, latency, history, schema change, deletion, consistency, security, region, and operating ownership. |
| Power BI dependencies | Fabric semantic models, Direct Lake, Import, DirectQuery, reports, and apps. | Connection endpoints, measures, RLS, refresh, performance, deployment, lineage, and business-result parity. |
Assign each item a disposition: migrate with supported tooling, convert with bounded changes, refactor for a Fabric-native pattern, re-architect, retain in Synapse, coexist temporarily, replace, or retire. Record the reason, owner, prerequisite, effort range, validation, rollback, and decommission dependency.
Validate current migration-tool coverage against the estate
Microsoft provides Fabric Migration Assistant capabilities for supported data warehouse scenarios and migration guidance for Azure Data Factory and Synapse pipelines. Tooling can accelerate schema, code, pipeline, or data movement, but coverage changes and does not remove environment work. Connections, credentials, triggers, global parameters, unsupported activities and connectors, integration runtimes, Spark, KQL, networking, identity, monitoring, and consumers can need separate action.
Run migration assistants in an isolated non-production environment and retain the generated findings. Do not treat a successful import as acceptance. Reconcile every skipped object, warning, converted expression, renamed item, disabled trigger, connection, parameter, dependency, and generated AI suggestion against the source and approved target design.
Choose a pilot that tests the hard parts
Select a business-relevant workload with bounded scope, known owners, accessible data and code, representative SQL or Spark transformation, orchestration, security, a semantic or application consumer, measurable baseline, and deterministic outputs. Include at least one known compatibility risk. A pilot containing only a simple copy and dashboard will not estimate the real migration.
| Pilot gate | Evidence | Decision |
|---|---|---|
| Functional parity | Converted objects, pipeline runs, Spark or SQL results, schedules, parameters, exceptions, and source-to-target reconciliation. | Can the target produce the approved result for representative data and edge cases? |
| Security and connectivity | Identity, network, gateway, secrets, permissions, RLS, private access, external sources, and negative tests. | Can the workload operate without weakening approved controls? |
| Performance and scale | Data load, transformation, query, concurrency, refresh, capacity CU, throttling, storage, and growth tests. | Does the target meet service levels at a defensible capacity and cost? |
| Delivery and operations | Git, environments, deployment, configuration, monitoring, alerting, incident recovery, backup, DR, and support runbooks. | Can the team release, operate, recover, and improve the workload? |
| Business acceptance | Reports, APIs, extracts, users, cutoffs, usability, owner sign-off, and measured process impact. | Does the migrated solution preserve or improve the business service? |
| Migration economics | Measured migration effort, exception rate, Fabric consumption, licensing, coexistence, support, and decommission savings. | Should the next wave scale, change pattern, retain workloads, or stop? |
Build deterministic validation and a reversible cutover
Validate schema, complete and incremental data, counts, checksums, balances, transformations, referential rules, null and duplicate behavior, late data, CDC state, pipeline branches, schedules, retries, SQL and Spark results, security personas, semantic models, reports, APIs, exports, freshness, performance, capacity, cost, monitoring, and recovery. Preserve source query, target query, data cutoff, expected tolerance, result, exception, owner, and decision.
Run source and target in parallel for an approved period where criticality warrants it. Freeze or coordinate changes, establish final synchronization, pause triggers in the correct order, communicate consumer changes, switch endpoints, monitor the target, and retain a tested rollback path. Do not delete Synapse artifacts immediately after first successful production use.
Plan migration waves and decommissioning
- Group items by business domain, shared data, dependency, target pattern, criticality, compatibility, and owner rather than by file type alone.
- Move low-risk prerequisites and shared platform controls before dependent business workloads.
- Use pilot evidence to revise conversion rates, capacity, testing, staffing, coexistence, and wave duration.
- Define entry and exit gates for inventory completeness, target readiness, security, validation, user acceptance, rollback, and support.
- Track exceptions and retained Synapse dependencies so partial migrations do not create an indefinite dual-platform estate.
- Decommission only after usage, schedules, consumers, data retention, audit, cost, ownership, support, and rollback windows are cleared.
Run a four-to-six-week assessment and pilot
- Define business drivers, target dates, constraints, critical services, architecture principles, budget, owners, and decision gates.
- Discover the Synapse estate and enrich the inventory with usage, dependencies, cost, performance, incidents, security, and business ownership.
- Map workloads to Fabric targets, compatibility, disposition, effort, risk, coexistence, validation, and decommission requirements.
- Design target tenancy, domains, workspaces, capacity, OneLake, networking, identity, governance, CI/CD, monitoring, support, and BCDR.
- Execute migration assistants and manual analysis against representative assets, recording gaps and conversion quality.
- Build one production-shaped pilot and run functional, data, security, performance, capacity, cost, operational, and business tests.
- Deliver the estate register, target architecture, fit-gap matrix, pilot evidence, wave roadmap, budget range, risk register, validation factory, cutover runbook, and decommission plan.
Frequently asked questions
Can Azure Synapse Analytics be migrated to Microsoft Fabric?
Yes, but Synapse is a collection of workload types rather than one portable object. Dedicated SQL pools, pipelines, Spark notebooks, serverless SQL usage, KQL or Data Explorer workloads, links, security, CI/CD, and dependent applications require different target patterns and tools. Some assets can use Microsoft migration assistants; others need conversion, redesign, coexistence, or retention.
What is included in a Synapse to Fabric migration assessment?
The assessment inventories active Synapse assets, dependencies, usage, data, code, security, performance, cost, SLAs, and operations; maps each workload to a Fabric target or retain decision; identifies compatibility gaps; defines architecture, capacity, governance, CI/CD, validation, cutover, rollback, and decommissioning; and proves representative risk through a bounded pilot.
Does the Fabric Migration Assistant migrate every Synapse workload automatically?
No. Microsoft provides migration experiences for supported dedicated SQL pool and pipeline scenarios, but feature and item coverage varies. Connections, credentials, triggers, global parameters, unsupported activities or connectors, Spark and KQL behavior, networking, identities, security, schedules, and dependent applications can require manual work or redesign. Validate current tool coverage against the actual estate.
How do you validate an Azure Synapse to Fabric migration?
Validate schema and code conversion, complete and incremental data, transformations, row counts, checksums, balances, referential rules, pipelines, schedules, security personas, query and Spark results, semantic models, reports, APIs, performance, capacity, cost, monitoring, recovery, and business workflows. Run source and target in parallel for approved periods and reconcile every material exception before cutover.
How long does a Synapse to Fabric migration assessment take?
A focused assessment and representative pilot can often be completed in four to six weeks when inventory access, source code, architecture, usage, costs, owners, and validation data are available. A full migration takes longer and should be planned in waves based on workload count, compatibility, data volume, security, business criticality, testing, coexistence, and decommissioning dependencies.
Official implementation references
- Microsoft Fabric Migration Assistant for Data Warehouse
- Microsoft Synapse dedicated SQL pool migration methods
- Microsoft Data Factory and Synapse pipeline migration guidance
- Microsoft pipeline migration behavior and limitations
- Microsoft Fabric and Azure Data Factory comparison
Start with the Synapse workloads that carry meaningful cost or business risk and one pilot that exercises their hardest dependencies. Datrick can assess the estate, prove the target pattern, and build a controlled migration factory.