I've spent a lot of the last year and a half being enthusiastic about Fabric — it's our default for new work, I've made the case for it repeatedly, and I'd make it again. So it might surprise you to hear that we have deliberately not migrated everything onto it, and have no immediate plans to. That's not indecision or foot-dragging. It's a considered position, and I think the discipline behind it is more valuable than any migration checklist, because the instinct it resists — "the new platform is good, so move everything onto it" — is one of the most reliably expensive instincts in this whole field.

Let me make the case for the not yet, because holding that line well is harder and more useful than the enthusiasm was.

"Good platform" and "migrate everything" are different claims

The logic that says "Fabric is our default, therefore we should move all our existing systems onto it" contains a hidden leap that's worth exposing. "Fabric is the right place to build new things" is a claim about greenfield work. "We should relocate our existing, working systems onto Fabric" is a completely different claim about brownfield work — and the first does not imply the second.

I believe the first wholeheartedly. The second I treat with real suspicion, because it asks me to spend money and take risk to move something that already works, in exchange for benefits that are often assumed rather than demonstrated. A working system has a value that's easy to underweight precisely because it's quietly doing its job. Migrating it has a cost that's easy to underweight because it hides in the future. Put those two underweightings together and you get the classic pattern: enthusiastic migrations that consume a quarter and deliver a system that does exactly what the old one did, now on trendier infrastructure.

What we're deliberately keeping where it is

Concretely, here's the kind of thing we've chosen not to move, and the reasoning, because the reasoning is the transferable part:

  • Systems that work and gain little from moving. We have things that run reliably, are well understood, and would gain nothing from relocation except the ability to say they're on Fabric. Moving them is pure cost and pure risk for a logo. They stay until there's a reason — a genuine capability we need, a real cost saving, an end-of-life forcing the question. "It's not on the new platform" is not a reason.
  • Specialist workloads better served elsewhere. As I've argued before, Fabric-first doesn't mean Fabric-only. Where we have heavy data-engineering or data-science work that lives happily in Databricks, forcing it into Fabric to satisfy a tidiness urge would trade a good fit for a worse one. A coherent estate isn't one where everything's on one platform; it's one where everything's in the right place, and sometimes the right place is the specialist tool it already runs on.
  • Anything mid-flight or high-risk to disturb. Some systems are load-bearing enough that the risk of migrating them outweighs any plausible benefit right now. Stability has value. Not everything needs to be on the newest thing to be doing its job well.

Notice the through-line: in each case the question isn't "is Fabric better?" It's "does this specific system have a real reason to move that outweighs the cost and risk of moving it?" Most don't, most of the time.

I keep coming back to a pattern I've written about in one form or another all year, because it's the deepest version of the mistake: relocating something to a new platform is not the same as improving it, and doing so just to be on the platform is cost without benefit. I made this argument years ago about lift-and-shift to the cloud, and it applies exactly to Fabric now. If you migrate a working system to Fabric and it does precisely what it did before, you have paid the full price of a migration — the disruption, the risk, the effort — for the privilege of a different logo on the same capability. That's not a strategy. It's a fashion.

The version of this I'm most wary of is the "consolidation for its own sake" argument — the aesthetic desire to have everything in one place. It's seductive because it sounds like good architecture. But an estate where everything's on one platform because someone valued neatness is not better-architected than one where things are in the right places for real reasons. It's just tidier, and tidiness is not a business outcome.

The right question is never "why isn't this on Fabric yet?" It's "what would this specific system actually gain by moving, and is that gain worth the cost and risk of moving it?" For most working systems, on most days, the honest answer is no.

What "yet" actually means

I put "yet" in the title deliberately, because this isn't a refusal — it's a discipline about timing and reason. Things will move to Fabric over time, and that's fine. But each will move when it has a genuine trigger: a capability we actually need that only Fabric provides, a cost saving we can demonstrate rather than assume, a system reaching a natural end-of-life where rebuilding on Fabric is the sensible next step anyway. Migration driven by a reason is good engineering. Migration driven by "it's the new default and everything should be on it" is how you spend a year relocating value from one place to an equivalent place and call it progress.

So we're Fabric-first for what we build, and patient about what we already run. New things start on Fabric because that's the right place to start them. Existing things move when they've earned a reason to, and not a day before. That's not a lack of commitment to the platform — it's what commitment to good decisions looks like when a genuinely good platform is tempting you to stop making them case by case. The enthusiasm was the easy part. Knowing what not to move, and holding that line against the pull of the shiny default, is the part that actually protects the value you already have.