Fabric Migration Assistant turns SQL modernisation into a platform decision
The Challenge
Most database migration projects do not fail because the tooling is missing. They fail because the target operating model is unclear.
That is why Microsoft’s Migration Assistant for SQL database in Fabric matters more than the product demo suggests. On paper, this is a preview feature that helps organisations move schema and data from SQL Server into SQL Database in Microsoft Fabric. In practice, it is part of a bigger shift: Microsoft is trying to make Fabric the destination platform for operational data workloads, not just the place where analytics lands after the fact.
That distinction matters.
For years, many organisations have treated their data estate as a chain of disconnected steps. SQL Server runs the application. Pipelines move data elsewhere. Analytics happens on another platform. AI gets bolted on later. Each move between systems creates more handoffs, more governance complexity, and more room for drift between what the business thinks its data means and what the platform can actually use.
When Microsoft introduces a migration assistant directly in the Fabric portal, it is not just making one migration task easier. It is trying to reduce the friction of moving an existing SQL workload into the same environment where data engineering, analytics, governance, and emerging AI patterns already live.
That is the more interesting story.
If you care about AI adoption in the real world, this matters because foundations still decide outcomes. Organisations do not get meaningful value from copilots and agents if the underlying data estate is fragmented, hard to move, and expensive to operate. Any feature that lowers the practical cost of consolidating that estate is more important than it sounds.
What’s Changed
The new Migration Assistant for SQL database in Fabric is now in preview through the Fabric portal. The workflow shown by Microsoft is fairly straightforward.
You start with a source SQL Server database and generate a DACPAC containing the schema. That DACPAC is uploaded into the Fabric migration experience, which creates the target SQL database in Fabric and translates schema objects such as tables, views, and stored procedures. Once the schema lands, data movement is handled through CopyJob in Fabric, typically using a data gateway to reach the source database. After the copy completes, constraints and indexes can be re-enabled and the migration finalised.
There are a few practical details worth noting.
First, this is currently a logical migration workflow, not a magic live cutover engine. In preview, the process still relies on generating and uploading a DACPAC separately. Microsoft was clear that live connectivity for pulling schema directly from the source is not part of the current preview, although it is being explored for future iterations.
Second, the preview has limits. Microsoft cited a current DACPAC size limit of 20 MB and support for roughly 100,000 objects. That means this is not yet a universal answer for every estate. Teams still need to qualify whether a workload is a good candidate.
Third, this is more than schema conversion. The migration flow includes object analysis, visibility into what converted cleanly, what needs fixing, and how post-migration preparation should happen before and after data copy. That matters because enterprise migration work is rarely blocked by the easy 98 per cent. It is blocked by the last awkward incompatibilities, manual fixes, and uncertainty over what happens next.
The reason I think this preview matters is that it turns migration into a Fabric-native experience. Instead of asking teams to stitch together external tooling and then work out how the destination fits into their wider Microsoft data strategy, the portal itself begins to act like an onboarding path into the platform.
That is clever. It lowers not just technical effort, but decision friction.
Getting Started
If you are evaluating this, do not frame it as a straight tool comparison. Frame it as an operating model test.
A lot of organisations will instinctively ask whether Migration Assistant is the fastest or most feature-complete route from SQL Server into a modern platform. That is fair, but it is not the only question that matters. The better question is whether moving a workload into Fabric simplifies the surrounding estate enough to justify the move.
A sensible starting point would be a contained workload with a clear business boundary and manageable complexity. Good candidates are databases that already feed reporting, operational insight, or downstream analytics, especially where the organisation is already standardising on Microsoft’s data stack.
I would approach the evaluation in five passes.
First, test source fit. Check whether the schema size, object count, dependency pattern, and operational expectations are suitable for the preview constraints.
Second, test migration quality. Do not just count whether objects move. Look closely at what needs manual remediation, how much rework is required, and whether the translated schema behaves the way the application expects.
Third, test data movement reality. CopyJob performance will depend on network conditions, gateway placement, source behaviour, and target compute. It is worth validating this with representative volumes, not tiny samples.
Fourth, test post-migration operations. Ask how backup expectations, deployment patterns, governance, security controls, and developer workflows change once the workload sits in Fabric.
Fifth, test strategic fit. Does landing the database in Fabric genuinely reduce the distance between operational data, analytics, and AI use cases for your organisation, or are you just relocating complexity?
That final point is the one many teams skip.
The temptation with migration tooling is to celebrate the wizard and ignore the platform consequences. But the real value is not that a database moved. It is that the moved database is now closer to the capabilities your business actually wants to use next.
What This Means
My view is that this preview is less about migration convenience and more about Microsoft tightening the gravitational pull of Fabric.
If Fabric is going to be credible as the platform for the next generation of applications, it cannot rely on greenfield stories alone. Enterprise buyers do not start from nothing. They start from SQL Server estates, operational databases, integration pipelines, and years of accumulated design choices. If Microsoft wants those workloads to move, the path has to feel guided, familiar, and increasingly native.
That is exactly what Migration Assistant is trying to do.
There is also a broader AI angle here. Everyone is talking about agentic applications, semantic context, and unified data estates. That conversation is useful, but it often floats above the practical work that makes those ambitions possible. Migration is that practical work. If the estate underneath remains fragmented, AI becomes another layer of architecture theatre.
This is why I think Leon’s perspective should be blunt here: migration tooling is not exciting, but it is often the difference between a credible AI strategy and a PowerPoint one.
Fabric Migration Assistant will not remove every migration challenge. Preview limits are real. Compatibility issues are real. Operational trade-offs are real. Some SQL workloads will not belong in Fabric yet, and some should probably stay where they are.
But the direction is the right one. Microsoft is not just shipping more AI narrative. It is trying to remove one of the boring, expensive blockers that keeps organisations from building a more unified data foundation.
That is the part worth paying attention to.
Because most enterprises do not need another announcement about what AI could do one day. They need fewer excuses for why the underlying platform still cannot move fast enough.
Leon Godwin, Principal Cloud Evangelist at Cloud Direct