Preparing for a Synapse to Microsoft Fabric Migration

A Synapse to Microsoft Fabric migration should begin with a workload and dependency assessment, not a copying exercise. The organisation needs to know what runs today, which business outcomes depend on it, what Fabric supports, how access will change and how the result will be reconciled before production traffic moves.

Microsoft provides migration paths for several Synapse workloads. The implementation decision is how those paths fit the current estate, governance model and operating capability.

Start with the business outcome

Before inventorying technical assets, identify:

• Which reports, data products or operational processes depend on Synapse.
• Who owns each outcome and can approve the migrated result.
• Which service levels, refresh windows and access rules apply.
• Whether the objective is like-for-like migration, platform consolidation or a redesigned data product.
• Which workloads can be retired rather than moved.

A migration without accountable business outcomes can reproduce the old estate in a new platform without improving trust or maintainability.

Build a workload and dependency inventory

The inventory should cover more than workspace item counts.

| Area | Evidence to collect | | ------------------- | ------------------------------------------------------------------------ | | Dedicated SQL pools | Schemas, tables, views, procedures, security and workload patterns | | Serverless SQL | External tables, views, file formats and downstream consumers | | Spark | Notebooks, libraries, runtimes, pools, configurations and schedules | | Pipelines | Activities, triggers, connections, parameters and failure handling | | Data | Sources, destinations, volumes, retention, ownership and sensitivity | | Power BI | Semantic models, refreshes, gateways, reports and workspace dependencies | | Operations | Monitoring, alerts, support procedures, deployment and recovery | | Consumers | Applications, exports, APIs, analysts and business processes |

Microsoft’s Fabric migration overview links the supported planning and migration guidance for Synapse data warehousing, Spark, pipelines and related workloads.

Decide what should move, change or stop

Classify every material asset:

1. Retire: no longer used or no longer supports a valid business outcome.
2. Retain temporarily: must remain in Synapse while dependencies or Fabric capabilities are resolved.
3. Migrate with limited change: has a supported path and no strong reason to redesign.
4. Refactor: the workload can move, but implementation, security or operating practices need to change.
5. Redesign: the target business outcome is better served by a new Fabric architecture.

This classification prevents the migration programme from treating every historical asset as equally valuable.

Assess compatibility and migration paths

Compatibility must be checked by workload.

For data warehousing, Microsoft’s Fabric Migration Assistant guidance describes a direct-connection path for copying dedicated SQL pools and SQL Server databases into Fabric Data Warehouse. It requires a Fabric workspace with active capacity or trial capacity and still requires incompatible scripts to be reviewed and corrected.

For Synapse Spark, pipelines and metadata, use the relevant guidance linked from Microsoft’s migration overview. Record:

• Supported automated steps.
• Manual conversion work.
• Behaviour that changes in Fabric.
• Libraries or integrations that need alternatives.
• Testing required before the workload is accepted.

An available migration tool reduces copying effort. It does not replace architecture, reconciliation or business acceptance.

Design governance before creating the target

The target environment should have a deliberate operating model from the beginning.

Define:

• Fabric tenant and capacity administration.
• Domains, workspaces and ownership.
• Entra ID groups and least-privilege access.
• Development, test and production separation.
• Deployment and change approval.
• Data classification, sensitivity and retention.
• Naming, documentation and lineage expectations.
• Monitoring, support and incident ownership.
• Access rules for people, applications and AI agents.

The point is not to add controls after data arrives. It is to make the migrated foundation usable without losing ownership or visibility.

Size capacity from the migration workload

Capacity assumptions need evidence from the source estate and the proposed target.

Consider:

• Current query and job patterns.
• Pipeline and notebook schedules.
• Semantic-model refresh windows.
• Interactive reporting peaks.
• Expected overlap between workloads.
• Data growth and new use cases.
• Performance and service-level requirements.

Do not select a Fabric SKU only by mapping the old Synapse spend or counting users. The services use different commercial and workload models.

See Microsoft Fabric pricing in Australia for the commercial inputs that should accompany the technical sizing.

Plan reconciliation and acceptance

Every migrated data product needs acceptance criteria before cutover.

Include:

1. Row and aggregate reconciliation: confirm expected record counts and business totals.
2. Business-definition checks: verify measures and transformations, not only technical loads.
3. Performance tests: test required refresh, query and report behaviour.
4. Security tests: confirm intended access and denied access.
5. Operational tests: exercise monitoring, failure handling, deployment and recovery.
6. Consumer validation: obtain approval from the owners of dependent reports and processes.

Run old and new outputs in parallel where the business risk warrants it. Define how discrepancies will be investigated and who can approve cutover.

Control the cutover

A migration wave should state:

• Assets and consumers included.
• Freeze and deployment windows.
• Data synchronisation method.
• Validation owners.
• Go or no-go criteria.
• Rollback conditions.
• Communication to report and application users.
• Date for retiring or restricting the old workload.

Avoid leaving Synapse and Fabric running indefinitely without an explicit coexistence decision. Duplicate platforms create unclear ownership, duplicated cost and uncertainty about which result is authoritative.

Common migration risks

Moving technical assets without business ownership

The team can prove that a table moved but cannot prove that the outcome still works.

Treating generated conversion as finished work

Converted scripts and copied data still require review, testing and operational design.

Recreating every historical pattern

The migration preserves avoidable complexity instead of using Fabric’s shared platform model deliberately.

Deferring governance

Workspaces, identities and access grow before ownership and release controls are clear.

Sizing capacity too early

The commercial decision is made before workload timing, concurrency and target design are understood.

Ignoring adoption and operation

The build goes live without documentation, support ownership or the internal capability to maintain it.

When to begin with a readiness roadmap

Move directly into implementation when:

• The first workload and outcome are defined.
• Source access and owners are available.
• The target architecture is sufficiently clear.
• Compatibility has been assessed.
• Acceptance and cutover owners are named.
• A commercial scope can be bounded responsibly.

Begin with a Data Discovery & AI Readiness Roadmap when the migration contains unresolved platform, ownership, priority or governance decisions. The roadmap should produce a prioritised migration sequence, target architecture, governance requirements, capacity assumptions and a costed next step.

When implementation-ready, Microsoft Fabric consulting and implementation can deliver the first controlled migration outcome inside the organisation’s Microsoft environment.

Book a 30-minute fit call to decide whether the next step is readiness work or a defined migration sprint.