Most Microsoft Fabric content will tell you to migrate — lift your existing architecture and shift it across. We’re going to tell you not to, or at least not if you can help it. Here’s what we’ve learned building on Fabric in production across real Aussie organisations, and why the rebuild vs. migrate question is the most important call you’ll face.

Why Fabric is worth taking seriously

Vendor enthusiasm and market hype aside, Fabric has actual substance behind it. OneLake is genuinely compelling — data engineering, warehousing, real-time analytics, and Power BI all reading from the same place without copying or syncing solves a real problem. For teams already running Azure and Power BI, the integration story is strong and the analytics experience is mature. Fabric is also Microsoft’s next-generation analytics platform — the clear successor to Synapse, even if Microsoft hasn’t officially called time on it yet. The R&D has moved, specific Synapse components are already being retired, and the direction of travel is pretty obvious. Synapse will keep running. It just won’t keep evolving.

If you have the choice, rebuild — don’t migrate

So if you’re sold on Fabric — or at least curious enough to move — here’s the most important thing we’ve learned from building on it in production. There are a few ways to approach a move to Fabric:

• Lift and shift — take what you have in Synapse and move it across as-is. Fast, lower upfront cost, and Microsoft supports it. Legitimate call if you have a large existing codebase, a tight timeline, or limited budget for re-architecture.
• Hybrid — migrate the stable, well-structured parts and rebuild the rest. For teams that can’t justify a full rebuild — whether that’s budget, timeline, or organisational appetite — this is often the most pragmatic path. You’re not carrying everything across blindly, but you’re not starting from zero either.
• Rebuild — start from scratch and model your data properly on Fabric from day one. Yes, it costs more upfront. You’re paying for design workshops, re-modelling, and the time it takes to do things properly. But you’re also not paying to migrate technical debt you’ll have to fix anyway.

Our preference is rebuild — but realistically, for most teams, hybrid is the more practical call. Fabric isn’t just Synapse with a new interface — it’s a fundamentally different architecture, built around OneLake as a single storage layer that everything reads from natively. If you lift and shift a Synapse architecture into Fabric, you’re running Synapse-era thinking on a platform designed to work differently, and you’ll miss most of what makes it worth moving to in the first place. Done properly, the benefits are real: lower total cost of ownership compared to managing separate Synapse services, significantly faster Power BI reporting through DirectLake mode, and a platform that’s genuinely easier to maintain because everything sits in one place rather than across fragmented services. On a recent client build, we made the deliberate call to model their data from scratch rather than migrate what existed. It added time and cost upfront — but for a small team, having everything in a single unified platform made day-to-day operations far more manageable. The platform they ended up with was cleaner, faster, and far easier to operate than before.

What else to plan for

As someone who’s led a few Fabric migration projects, here’s what else we’d flag before you commit.

• The capacity model will surprise you. Fabric runs on a CU-based billing model that behaves differently from what most teams are used to. We’ve seen workloads that looked fine in dev chew through capacity in production in ways nobody anticipated. Model this carefully before go-live — it will save you an awkward conversation with finance.
• Your security model needs rethinking, not just lifting. It doesn’t map cleanly from Synapse. On a recent build this took longer than expected and required dedicated workshop sessions to get right — don’t assume it’s a quick port.
• Monitoring, alerting, and CI/CD are functional but still maturing. Not blockers, but if your team has strong operational requirements around observability and deployment pipelines, go in with realistic expectations and plan for some custom work.
• Access provisioning takes longer than you think. Getting service accounts set up across source systems means depending on other teams — and that dependency adds weeks if it isn’t planned for. On one recent build it was the biggest schedule risk on an otherwise smooth implementation.

When to migrate

If you’re starting something new, start it on Fabric — there’s no good reason to begin on Synapse today. If you’re on Synapse and stable, there’s no emergency, but a migration roadmap is worth having. The longer you wait, the more you’ll build on a platform that isn’t moving forward — and the bigger the eventual migration becomes. If you’re mid-build on Synapse, it’s worth pausing to evaluate whether a pivot makes sense. Uncomfortable in the short term, but potentially cheaper than finishing a build you’ll need to redo in two years.

The bottom line

Fabric is a serious platform with real production credentials. Go in with clear capacity planning, a rethought security model, and realistic expectations on the operational tooling — and you’ll be in good shape. And if you get the chance to rebuild rather than migrate, take it.

Let’s talk Fabric

If you’re evaluating a move to Microsoft Fabric or working through what a migration from Synapse looks like, we’ve done this across multiple industries and are happy to share what we’ve learned. Get in touch.

Frequently asked questions

Should we wait for Microsoft to formally retire Synapse before migrating?

We wouldn’t. Microsoft hasn’t officially called time on Synapse, but the R&D direction is clear — Fabric is where the platform is going. Waiting for an end-of-life announcement means accumulating more on a platform that’s no longer evolving, and a more painful migration when you finally move. Better to plan the transition on your timeline than be forced into one on Microsoft’s.

How long does a Microsoft Fabric implementation typically take?

It depends on which path you take. A lift-and-shift can be measured in weeks for a focused workload, a rebuild for a mid-sized environment usually runs three to six months, and a hybrid approach sits somewhere in between. The biggest variable is rarely the technical work — it’s access provisioning, governance decisions, and stakeholder alignment.

Can we run Fabric and Synapse in parallel during a migration?

Yes, and most clients do. Running both during transition lets you migrate workloads in a controlled sequence, validate outputs, and avoid a hard cutover. The watch-out is duplication — if the same dataset is being maintained in both platforms for too long, costs and confusion both rise.

Will our team need retraining for Fabric?

Some, yes — but less than you’d think if they’re already working in the Microsoft ecosystem. The interface and core concepts feel familiar to anyone with Synapse, ADF, or Power BI experience. The bigger shift is in how OneLake changes architectural thinking — and that’s a design conversation more than a training course.

How does Fabric pricing compare to what we’re paying for Synapse today?

It depends on how your workloads behave. The CU-based capacity model rewards consistent, predictable usage and punishes spiky workloads that weren’t sized for. For many teams, total cost of ownership comes down once fragmented Synapse services are replaced with a single Fabric capacity — but that’s not automatic. Model your actual workload patterns before committing to a tier.