How to Plan a Microsoft Fabric Migration from Azure Synapse - The Phased Approach That Actually Works

Every Synapse-to-Fabric migration we've run has hit the same fork in the road around week three. The technical team wants to keep tinkering. The business sponsor wants to know when the old Synapse environment can be turned off. The finance person wants to know why both environments are still being paid for.

This post is about the phased approach we use to keep those three people happy at the same time. It's not the migration plan you'll find in a Microsoft slide deck. It's the one we've refined across multiple Australian engagements, including a NSW state government agency, a Brisbane logistics business, and a Melbourne financial services firm that had four years of Synapse Dedicated Pool investment to unwind.

If you're planning your own move, this is the structure that works.

Why a Phased Migration Beats a Big-Bang Cutover

We've never seen a successful big-bang Synapse-to-Fabric cutover. Not one. The teams that try it always discover something in week five that derails the timeline - a stored procedure that doesn't translate cleanly, a Power BI report tied to a Synapse linked server, or a downstream Excel workbook that nobody knew existed.

A phased approach assumes you'll find ugly stuff and gives you time to fix it without business impact. The cost of running both environments in parallel for two or three months is almost always less than the cost of a rushed cutover that breaks reporting for the finance team during month-end close.

There are four phases we run through on every engagement:

1. Assessment (2-3 weeks)
2. Pilot (3-4 weeks)
3. Parallel run (6-12 weeks)
4. Cutover and decommission (2-4 weeks)

Total elapsed time is usually three to six months, depending on the size of the Synapse estate and how many downstream consumers depend on it.

Phase 1 - Assessment

The assessment phase is where most migrations either succeed or fail. Get this wrong and every later phase is harder than it needs to be.

Here's what the assessment actually covers:

Inventory of Synapse workloads. Every Dedicated SQL Pool, every Serverless query, every Synapse Pipeline, every Spark notebook, every linked service. We typically find 20 to 40 per cent more artefacts than the client thinks they have. There's always a dataset somebody built two years ago that's still feeding a Power BI report nobody admits to owning.

Dependency mapping. What reads from Synapse? Power BI is the obvious one, but it's never the only one. We've found Excel workbooks pulling through ODBC, a legacy .NET application doing direct queries, third-party data products consuming the lakehouse via JDBC, and even a Microsoft Access database in one government engagement.

Workload classification. Each Synapse workload gets classified into one of four buckets:

• Lift and shift (straight migration with minor adjustments)
• Refactor (needs schema or code changes for Fabric equivalent)
• Re-architect (better served by a different Fabric pattern, like moving from a SQL pool to a Lakehouse)
• Retire (turns out nobody uses it - more common than you'd expect)

Cost baseline. What is Synapse costing today? Compute, storage, egress, support. This becomes the benchmark for the Fabric capacity sizing exercise. If you don't know what you're spending now, you can't tell whether Fabric is a win or a loss.

Skills audit. Does the team have the skills to operate Fabric? Most Synapse teams have strong T-SQL and pipeline skills. Fabric leans more heavily on the Lakehouse model, OneLake shortcuts, and Power BI integration. There's usually a training gap to address. Our Microsoft Fabric consultants page outlines the skills mix we typically bring in.

Budget for assessment: A proper assessment for a mid-market Australian organisation runs $25,000 to $50,000 AUD. Anything cheaper is a tick-box exercise that will cost you later. Anything more expensive is probably padded with discovery work that should be billable to phase two.

Phase 2 - Pilot

The pilot phase is where you prove the approach works on a workload that matters but won't break the business if it goes sideways.

How to choose the pilot workload. Pick something that has real business value (so the pilot gets attention) but isn't on the critical path for month-end or regulatory reporting (so a delay doesn't cause panic). The sweet spot is usually a departmental reporting workload - sales analytics, operational dashboards, or a specific business unit's data mart.

Avoid using customer-facing data products as a pilot. We did this once with a logistics client because the technical team wanted to "really test it". The result was three weeks of meetings about why the test environment couldn't replicate production exactly. Pick something simpler.

What gets built in the pilot. A working end-to-end slice of the Fabric architecture:

• Data ingestion (Data Factory pipelines or Dataflow Gen2)
• Storage (Lakehouse or Warehouse)
• Modelling (Direct Lake semantic model or imported Power BI model)
• Consumption (one or two reports running off the new environment)

Capacity sizing. The pilot is where you size your Fabric capacity for real. Microsoft's sizing guidance is generic. The only way to know what F-SKU you need is to run real workloads. We typically start with an F64 or F128 for mid-market clients and tune up or down based on the pilot results. Over-provisioning in the pilot is fine - just turn the capacity down once you have data.

Budget for pilot: $40,000 to $80,000 AUD depending on complexity. Add another $5,000 to $15,000 in Fabric capacity costs for the duration of the pilot phase.

Phase 3 - Parallel Run

The parallel run is where most of the actual migration work happens. The pilot proved the pattern works. Now you're applying that pattern to the rest of the Synapse estate while keeping the old environment running.

Run both environments in parallel. This is the bit clients always want to skip. Don't skip it. The point of parallel run is to compare outputs - the same dataset processed through Synapse and through Fabric should produce the same numbers. When they don't (and there will always be some that don't), you investigate and fix before cutover.

Migrate in waves. Group workloads into migration waves based on dependencies. Wave one is the workloads with no downstream dependencies. Wave two depends only on wave one. And so on. We usually end up with three to five waves for a typical mid-market migration.

Validate every wave. For each wave, run reconciliation queries between Synapse and Fabric. Are the row counts the same? Are the financial totals the same? Are the slowest queries within an acceptable performance band? Document the variance and the reason for it.

The most common source of variance we see is timestamp handling. Synapse and Fabric handle UTC conversion slightly differently in some edge cases, which can produce ghost discrepancies in reports that aggregate by day. Catch these in parallel run, not after cutover.

Decommission readiness checks. Each wave produces a checklist of what needs to be true before the corresponding Synapse workload can be turned off:

• Fabric workload running stably for at least four weeks
• All downstream consumers migrated
• Reconciliation completed and signed off
• Operational runbook updated

Budget for parallel run: This is the biggest phase. $100,000 to $250,000 AUD for a typical mid-market migration, plus the cost of running both environments. The parallel costs are uncomfortable, but they're the insurance you're paying for the migration to succeed.

Phase 4 - Cutover and Decommission

The final phase is the one that finally lets you turn off Synapse and stop paying for it.

Cutover by wave, not all at once. Each wave from phase three gets its own cutover event. The downstream consumers get pointed at Fabric, the Synapse workload gets paused (not deleted), and you watch for problems for a week or two.

Don't delete Synapse on day one. Pause the Dedicated SQL Pool but don't drop it. We had a client who confidently deleted their pool the day after cutover, then discovered an external auditor needed access to a specific historical query. The recovery from a deleted pool is painful and expensive. Keep it paused for at least 30 days post-cutover.

Decommission cleanly. Once you're confident the migration is stable, decommission in this order: pause compute, archive any data not already in Fabric, delete pipelines and linked services, finally delete the Synapse workspace.

Budget for cutover: $30,000 to $60,000 AUD. The work is mostly coordination, communication, and dealing with the inevitable post-cutover issues.

Decision Framework - Which Migration Pattern Fits Each Workload

Not every Synapse workload moves to Fabric the same way. Here's the framework we use to decide.

Synapse Component	Best Fabric Target	Migration Pattern
Dedicated SQL Pool (small, < 1TB)	Fabric Warehouse	Lift and shift, refactor stored procedures
Dedicated SQL Pool (large, > 5TB)	Fabric Warehouse + Lakehouse	Re-architect, move cold data to Lakehouse
Serverless SQL Pool	Lakehouse SQL endpoint	Lift and shift, validate external tables
Synapse Pipelines	Data Factory in Fabric	Refactor, most activities map directly
Spark Notebooks	Fabric Notebooks	Lift and shift, mostly compatible
Linked Services	OneLake shortcuts or new connections	Re-architect, shortcuts often simpler
Power BI datasets	Direct Lake semantic models	Refactor for performance gains

Common Pitfalls We See on Every Migration

A few patterns show up on almost every Synapse-to-Fabric engagement. Plan for them.

Underestimating the Power BI work. Teams budget for the data platform migration but forget that every Power BI report that connects to Synapse will need its connection updated, and many will benefit from being rebuilt to use Direct Lake. We typically budget 30 per cent of the total migration effort on the Power BI side.

Ignoring security and access control. Synapse permissions don't translate one-to-one to Fabric. The Fabric workspace model, item-level permissions, and OneLake security work differently. Map this out in the assessment, not at cutover.

Treating Fabric like Synapse. Fabric is not Synapse with a new badge. The Lakehouse pattern, Direct Lake, OneLake shortcuts - these are different ways of working. Teams that try to recreate Synapse in Fabric usually end up with the worst of both worlds. Get help if your team is new to the Lakehouse pattern. Our Microsoft data factory consultants page has more on the pipeline side.

No plan for the people. The technical migration is half the job. The other half is training the analyst and BI teams who use the environment every day. Budget for at least two weeks of structured training across the relevant teams. The Copilot training we run for clients covers a lot of the Fabric tooling.

Realistic Timeline and Total Investment

For an Australian mid-market organisation with a moderate Synapse estate (one Dedicated Pool, a dozen pipelines, twenty or so Power BI reports), here's what a real migration looks like:

• Assessment: 3 weeks, $35,000 AUD
• Pilot: 4 weeks, $60,000 AUD plus $8,000 in Fabric capacity
• Parallel run: 10 weeks, $180,000 AUD plus $30,000 in dual-environment costs
• Cutover and decommission: 3 weeks, $45,000 AUD

Total: 20 weeks, around $360,000 AUD in services plus $40,000 in temporary infrastructure overlap. Larger organisations or those with significant custom code can push this past $700,000 AUD. Smaller departmental migrations can come in under $200,000 AUD.

These numbers feel uncomfortable until you compare them to the cost of getting it wrong - or the cost of staying on Synapse for another two years while Microsoft puts all its development effort into Fabric.

When You Should Wait Instead of Migrate

Not every Synapse workload should migrate today. There are situations where waiting six to twelve months is the right call.

If you have a very large Dedicated Pool (over 20TB) with complex T-SQL workloads, the Fabric Warehouse story is still maturing for that scale. Pilot it, but don't commit to a full migration yet.

If your Synapse estate is small and stable and your EA renewal is more than 18 months away, there's no rush. Migrate when the business case justifies it.

If you're in the middle of another major data initiative (a CRM rollout, a finance system replacement), don't add a platform migration to the workload. Sequence the work properly.

How Team 400 Helps with Synapse-to-Fabric Migrations

We've run these migrations end-to-end for Australian organisations across financial services, government, logistics, and healthcare. Our typical engagement model is:

• Discovery workshop (one week, fixed price) to scope the migration and define the assessment
• Full assessment (2-3 weeks) with a written migration plan and cost model
• Implementation (3-6 months) delivered in phases with clear go/no-go checkpoints

If you're planning a Synapse-to-Fabric migration and want a second opinion on your approach, get in touch via our contact page. We're happy to do a one-hour scoping conversation at no cost to help you figure out whether you need outside help or whether your team can manage the work internally.

For more on how we work with clients on the broader Microsoft data platform, see our Microsoft Fabric consultants and Power BI consultants pages.