What Nobody Tells You Before You Migrate to Microsoft Fabric

With FabCon and SQLCon 2026 this week — Microsoft formally unifying SQL Server and Fabric on a single data platform — there's no shortage of opinion about where this technology is heading.

What's harder to find is someone who's actually done it.

Last year I spent seven months on a complete end-to-end data pipeline migration to Microsoft Fabric: assessing the existing infrastructure, designing a new medallion-based architecture on Azure Data Platform, and migrating the entire data team's workflows across. The engagement finished in July 2025. The outcome was genuinely impressive — dramatically improved system performance, streamlined workflows, better accessibility for the business.

The path to get there was nothing like the documentation suggests it should be.

Here's what actually surprised me.

Medallion architecture isn't optional

When you start reading about Fabric, the medallion pattern (Bronze → Silver → Gold layers) comes across as a design preference. Something thoughtful teams choose to implement.

It isn't optional. It's the load-bearing structure everything else sits on.

We found this out early. Some of the existing ETL logic came across in a form that bypassed a clean layered approach — not maliciously, just because the old pipeline had been built incrementally over years without that framework. Without a committed medallion foundation, data quality issues propagate upward, pipeline dependencies become impossible to reason about, and debugging becomes archaeology.

Once we committed to rebuilding properly around the medallion layers, everything else became more tractable. But that rework cost time we hadn't budgeted for.

Lesson: Design the medallion architecture before you write a single line of pipeline code. It cannot be retrofitted cleanly.

Your existing ETL logic won't lift and shift

This is the one that stings the most if you're not expecting it.

ETL pipelines — whether they're SSIS packages, stored procedures, or something bespoke — carry years of implicit assumptions: data types, transformation sequencing, error handling behaviour, timing dependencies. Things that work because they've been tuned to a specific environment over a long time.

Fabric runs on a different execution model. Pipelines that performed reliably on SQL Server needed complete rewrites in Fabric — not because Fabric was inferior, but because the underlying assumptions didn't transfer.

Budget for full rewrites of your core ETL logic. If some of it carries over cleanly, treat that as a bonus. If you plan around lift-and-shift, you will run short.

Performance improves after the pain, not during it

Stakeholder expectation management turned out to be one of the hardest parts of this project.

Fabric delivers real performance improvements. The post-migration state was measurably better — faster, more accessible, properly governed. But improvements don't arrive linearly. The first phase of a migration is slower than what you had before. You're rebuilding pipelines, establishing medallion layers, surfacing data quality issues that were always there but invisible in the old system.

Stakeholders notice. They ask why the new system seems slower than January.

The answer — that you're building the right foundation instead of patching over a fragile one — is technically correct and difficult to communicate when someone is looking at a dashboard that takes longer to refresh than it did last quarter.

Set expectations clearly and early. The performance gains are real and they are downstream of the architecture work, not concurrent with it.

Stakeholders will request Fabric features before you're ready

This one caught me off-guard.

Fabric has genuinely exciting capabilities — OneLake, Direct Lake mode, Copilot integrations, real-time analytics. Once the migration was underway and word spread, people started requesting features before the core architecture was stable.

One request was for Direct Lake connected to Power BI before the Silver layer was complete. Another wanted Copilot analysis on data that was mid-migration.

The temptation is to say yes — the feature exists, the business case is real. Resist it. Premature feature work will fracture your timeline and introduce unstable dependencies.

Be specific about what each phase unlocks and when. A migration roadmap is also a stakeholder communication document.

The teams that struggle aren't the ones with bad data

In my experience, organisations that find Fabric migrations hardest aren't the ones with the messiest data estates. They're the ones that approached it as an infrastructure swap — get the data across, get the pipelines running, declare it done.

That approach misses the point. The value of Fabric is in what it enables when the architecture is right: unified analytics, real-time capabilities, AI-ready data layers, consolidated governance across the estate. None of that is accessible if you've carried old SQL Server thinking into a new platform.

The hard work is the redesign. The platform change is the easy part.

What I'd tell someone starting this today

Commit to medallion from the start. No shortcuts, no phased-in approach.
Assume full ETL rewrites. Budget for it. Anything that carries over is a bonus.
Set stakeholder expectations in the first week. The early months will feel like regression.
Freeze feature requests until the core migration stabilises. New capabilities come after the foundation.
Think of it as a workflow redesign, not an infrastructure swap. The platform is not the work.

If you're planning a Fabric migration — or trying to figure out whether it's the right move for your organisation — feel free to reach out. Happy to talk through what the assessment and planning process looks like before anyone commits to anything.

— Gareth Huggins
SQL Server DBA & Solutions Architect | sqloptimise.com

Gareth has led SQL Server and data platform projects across NHS, defence, supply chain, and private sector clients since 2012. Recent work includes a complete end-to-end data pipeline migration to Microsoft Fabric (Jan–Jul 2025).