If you've been running Power BI Premium on a capacity — the dedicated P-SKU model many larger organisations settled on — you've probably had the conversation by now: Premium's capacity SKUs are being folded into Fabric's F-SKU world, and you need a plan. The tempting plan is the obvious one: find the F SKU that matches your old P SKU, swap it in, and move on. I want to talk you out of that, because a like-for-like swap treats a genuine opportunity to rethink your BI economics as a box-ticking chore — and usually leaves money on the table in the process.

The move from Premium to Fabric isn't a rename. It's a change in what you're actually buying, and that change opens questions your old Premium setup never let you ask.

What actually changes underneath the swap

On the surface, P SKUs and F SKUs look like the same idea: buy a capacity, run your BI on it. And the mapping between them is real — there's a rough equivalence you can look up. But underneath, two things are genuinely different, and both matter for cost.

  • The capacity now does far more than BI. A Premium P SKU was, in practice, a Power BI machine. A Fabric F SKU is a whole data platform capacity — the same pool of Capacity Units feeds your data pipelines, your lakehouse, your warehouse, your notebooks, and your Power BI, all from one wallet. That means your BI is no longer sizing a dedicated resource; it's sharing a general one. Size it as if it's still a BI-only box and you'll either starve your other workloads or over-buy to avoid doing so.
  • The flexibility levers are different and better. F SKUs can be paused and resumed, and you can reserve your stable baseline while flexing peaks on pay-as-you-go. Premium capacities were far more of a fixed, always-on commitment. If you carry the "always-on, fixed size" mindset across unchanged, you're paying for a rigidity the new model no longer forces on you.

I've written separately about how the Capacity Unit model actually behaves — the smoothing, the bursting, the throttling — and that mechanics matters here, because the Premium-to-Fabric move is exactly the moment to apply it. You're not swapping a licence. You're moving onto a fundamentally more flexible, more shared economic model, and the savings live in that flexibility.

The questions the transition lets you finally ask

So rather than "which F SKU equals our old P SKU," the transition is your licence to ask better questions — ones Premium's rigidity discouraged:

  • Are we one capacity or several? Premium nudged you toward one big capacity for everything. Fabric makes it reasonable to run, say, a reserved production capacity and a separate, pausable development capacity that isn't billed nights and weekends. That split alone can meaningfully cut the bill.
  • What's actually always-on? Some of your BI genuinely needs to be live around the clock. A lot of it doesn't. Separating the truly always-on from the business-hours-only lets you reserve the former and flex the latter, instead of paying peak rates for a 24/7 posture most of your workloads never needed.
  • Are we sized for our average or our worst minute? Premium's fixed model quietly encouraged sizing for peak, because bursting wasn't as forgiving. Fabric's smoothing means you can often run a smaller baseline than your old P SKU and let bursting handle the spikes — but only if you look, rather than defaulting to the equivalent SKU out of caution.

Every one of those is a question the old model made pointless to ask and the new model rewards. A like-for-like swap answers none of them and pockets none of the benefit.

Migrating Premium to Fabric by matching SKUs is like moving house and rebuilding every room in the exact old dimensions. You've done all the work of moving and captured none of the reason you'd move.

How I'd actually approach it

If I were running this transition, I wouldn't start from SKUs at all. I'd start from workloads. Map what you actually run today — which reports, which refreshes, which other Fabric workloads will share the capacity — and separate it into "genuinely always-on production" and "everything else." Reserve a right-sized capacity for the former, informed by your real usage rather than your old P-SKU number. Put development and intermittent work on a pausable, flexible footing. And only then look at which F SKUs those decisions imply — letting the workload analysis pick the SKU, not the old SKU pick your future.

That's more work than matching a number in a table, and it's the whole point. The organisations that come out of this transition paying less are the ones that treated it as a chance to right-size and re-shape; the ones that come out paying more are the ones that swapped like-for-like and carried every Premium-era assumption across intact.

The bottom line

Power BI Premium moving into Fabric is not a threat and not merely a chore — it's the best excuse you'll get to rethink a BI cost model that most organisations set once and never revisited. The new model is more flexible, more shared, and more forgiving of spiky workloads, which means it's also more rewarding of attention and more punishing of autopilot. Do the workload analysis, split what should be split, reserve what's stable, pause what's idle, and let all of that choose your capacity. Skip it, match the SKU, and you'll have completed the migration and missed the opportunity — paying Fabric prices for a Premium-shaped design. The swap is easy. The rethink is where the money is.