Most Microsoft Fabric content will tell you to migrate: lift the existing architecture and shift it across. We are going to tell you not to, or at least not if you can help it. Here is what building on Fabric in production across real Australian organisations has taught us, and why the rebuild versus migrate question is the most important call a team will face.

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. Fabric is also Microsoft's next-generation analytics platform, the clear successor to Synapse, even if Microsoft has not officially called time on it yet.

If you have the choice, rebuild rather than migrate

Most Microsoft Fabric content will tell you to migrate. We are going to tell you not to, or at least not if you can help it. Fabric is not just Synapse with a new interface. It is a fundamentally different architecture, built around OneLake as a single storage layer that everything reads from natively. Lift and shift a Synapse architecture into Fabric, and a team is running Synapse-era thinking on a platform designed to work differently, missing most of what makes it worth moving to in the first place.

There are three ways to approach a move to Fabric:

• Lift and shift: take what exists in Synapse and move it across as-is. Fast, lower upfront cost, and Microsoft supports it. A legitimate call with 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 cannot justify a full rebuild, whether that is budget, timeline, or organisational appetite, this is often the most pragmatic path. Not carrying everything across blindly, but not starting from zero either.

• Rebuild: start from scratch and model the data properly on Fabric from day one. It costs more upfront, paying for design workshops, re-modelling, and the time it takes to do things properly. But there is no paying to migrate technical debt that will need fixing anyway.

Our preference is rebuild, but for most teams, hybrid is the more practical call. Done properly, the benefits are real: lower total cost of ownership, faster Power BI reporting through Direct Lake mode, and a platform that is genuinely easier to maintain because everything sits in one place.

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

A few things worth flagging before committing:

• 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 have seen workloads that looked fine in dev chew through capacity in production in ways nobody anticipated. Model this carefully before go-live.

• The security model needs rethinking, not just lifting. It does not map cleanly from Synapse. On a recent build this took longer than expected and required dedicated workshop sessions to get right. Do not assume it is a quick port.

• Monitoring, alerting, and CI/CD are functional but still maturing. Not blockers, but a team with strong operational requirements around observability and deployment pipelines should go in with realistic expectations and plan for some custom work.

• Access provisioning takes longer than expected. Getting service accounts set up across source systems means depending on other teams, and that dependency adds weeks if it is not planned for. On one recent build it was the biggest schedule risk on an otherwise smooth implementation.

When to migrate

Starting something new should start on Fabric. There is no good reason to begin on Synapse today. Stable on Synapse means no emergency, but a migration roadmap is worth having. The longer a team waits, the more it builds on a platform that is not moving forward, and the bigger the eventual migration becomes.

Mid-build on Synapse is worth pausing to evaluate. A pivot is uncomfortable in the short term, but potentially cheaper than finishing a build that needs redoing in two years.

Getting the chance to rebuild is worth taking. Fabric is a serious platform with real production credentials, particularly for financial services, government and enterprise teams that need the governance story to hold up. Go in with clear capacity planning, a rethought security model, and realistic expectations on the operational tooling, and the implementation will be in good shape.

Frequently asked questions

Should we wait for Microsoft to formally retire Synapse before migrating?
We would not. Microsoft has not 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 is no longer evolving, and a more painful migration when the move finally happens. Better to plan the transition on your own 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 is 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 allows workloads to migrate in a controlled sequence, validates outputs, and avoids a hard cutover. The watch-out is duplication: if the same dataset is maintained in both platforms for too long, costs and confusion both rise.

Will our team need retraining for Fabric?
Some, yes, but less than expected if they are 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 is 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 the workloads behave. The CU-based capacity model rewards consistent, predictable usage and punishes spiky workloads that were not sized for it. For many teams, total cost of ownership comes down once fragmented Synapse services are replaced with a single Fabric capacity, but that is not automatic. Model actual workload patterns before committing to a tier.

Not sure whether to rebuild or migrate?

The Omnia Collective works with financial services, government and enterprise teams across Australia as a certified Microsoft Solutions Partner, helping teams work through the rebuild versus migrate decision before committing to either. See our Microsoft Fabric implementation services or get in touch.