Power BI Premium to Fabric Migration

A Power BI Premium to Fabric migration is a licensing and infrastructure move, not a platform rebuild. Microsoft has stopped selling per-capacity P SKUs and each subscription now ends with its agreement term, so every business running P1, P2 or P3 capacity has a dated deadline to reassign its workspaces onto a Fabric F SKU. The reports, semantic models, apps, deployment pipelines and refresh schedules your users depend on carry across unchanged. What changes is who bills you, how you size the capacity, which viewers still get in for free, and which governance settings you have to reapply on the other side.

This page is about the transition itself: reading your current capacity baseline, choosing the F SKU that matches it, reassigning workspaces without stranding content, and proving the new capacity holds before you cancel the old subscription. If what you want instead is a greenfield lakehouse with Direct Lake models and data engineering built on Fabric from scratch, that is a different engagement — see Microsoft Fabric implementation. If you are moving off spreadsheets or a legacy BI stack rather than off Premium, start with business intelligence migration services. And if you already have a plan and need senior hands only for the cutover, Power BI Flex Support buys blocks of consulting time without a project contract.

Why is Microsoft retiring Power BI Premium P SKUs?

Microsoft no longer sells Power BI Premium per-capacity SKUs. Existing subscriptions run to the end of their current agreement term and then stop, and Fabric F SKUs are the replacement path. Per-user licensing is untouched: Pro and Premium Per User continue exactly as they are, and the EM and A embedded SKUs sit outside this retirement entirely.

The expiry is not a soft one. When a P SKU subscription ends, the capacity enters a 30-day grace period; from day 31 interactive operations are throttled and users feel the delay, and on day 91 and beyond all operations are rejected. The data is retained but unreachable until the workspaces are reassigned to an F SKU capacity or the capacity is deleted. That is why the reassignment is scheduled before the subscription ends rather than after it lapses — the rule is set out in Microsoft's Premium to Fabric migration overview.

Enterprise Agreement customers have more room. While the agreement is active, existing P SKU capacity can generally be renewed annually through it until the EA term ends; customers on expiring Enterprise Agreements or Microsoft Cloud Agreements cannot add or purchase new P capacity at all. Contract terms genuinely differ, so the date on your own renewal — not a vendor blog post — sets your timeline. Confirm it with your Microsoft account representative before you plan around it. One more scope limit worth knowing: Fabric is not yet available in sovereign clouds, so P SKUs remain supported there.

Which Fabric F SKU replaces your P SKU?

The like-for-like starting point is the F SKU with the equivalent compute: P1 maps to F64, P2 to F128 and P3 to F256. Size from what your capacity actually consumes, measured in the Microsoft Fabric Capacity Metrics app, rather than from the SKU name on your invoice — and treat consolidation or resizing as a second project.

F64 is the line that costs money if you cross it downward. On F64 and larger, users holding a free license with the Viewer role can open content, exactly as they could on a P SKU. On F2 through F32, every viewer needs a Pro or PPU license. A business that right-sizes from P1 to F32 on compute alone can find it has just bought several hundred per-user licenses to replace a capacity license it already had — and the per-user bill lands in a different budget from the Azure one, which is how it gets missed.

Two Microsoft tools do the arithmetic. The Capacity Metrics app gives you the CU baseline you are running today; the Fabric SKU Estimator projects what that becomes on F. Register the Microsoft.Fabric resource provider in Azure and stand up a trial capacity if you want to test real workloads before committing to a purchase. Buy the F SKU before you reassign anything — Fabric will not move workspaces onto a capacity that does not exist yet.

• Peak and sustained CU consumption across a full business cycle, month-end close included
• How many viewers hold only a free license — this is the F64 threshold decision, not a compute decision
• Azure region: same-region is the recommended default and by far the lowest-risk move
• Whether Power BI Report Server is in scope — it needs a Fabric capacity reservation or SQL Server Enterprise Edition with Software Assurance
• Whether any workspace holds Fabric items or large storage format semantic models, which constrain a cross-region move

What happens on migration day?

For a same-tenant, same-region move, very little that is dramatic. You provision the F SKU first, then reassign each workspace to the new capacity in the Fabric admin portal, or in bulk using Microsoft's capacity migration notebook. Expect no downtime beyond the refreshes that happen to be running at the moment a workspace moves.

The work that decides whether the migration was clean is the validation that follows. Confirm scheduled refreshes complete on the new capacity. Confirm gateway connections and their stored credentials still resolve. Confirm deployment pipelines and Git integration still bind to the right workspaces. Then check the capacity-level settings that were customized on the P SKU — semantic model memory limits are the classic one — because those do not travel with the workspace and have to be reapplied in the Fabric admin portal.

Keep the P SKU alive through that window. Fabric does not decommission it for you: cancellation is a deliberate, manual step in the Microsoft 365 admin center, and while both capacities exist a workspace can be reassigned back in minutes if something looks wrong. Cancel only after the new capacity has carried a full business cycle, month-end included, without surprises.

• Provision and validate the F SKU before touching a single workspace
• Move one low-traffic pilot workspace and prove it end to end — refresh, gateway, report, app
• Reassign the rest in waves, heaviest refresh schedules last
• Monitor the new capacity in the Capacity Metrics app for one to two weeks and compare to the P SKU baseline
• Assign Azure RBAC, tags and budgets on the capacity resource before you open it to everyone
• Cancel the P SKU manually once the migration has been validated

What breaks in a cross-region or cross-tenant migration?

Cross-region reassignment fails outright when a workspace holds Fabric items — lakehouses, warehouses, notebooks or Data Factory pipelines. Large storage format semantic models have to be backed up and restored, or converted to small storage format, before they will move. Cross-tenant is not a supported one-click migration at all: workspaces, gateways, models, reports and apps are recreated by hand.

Two consequences follow that teams rarely budget for. A semantic model that is backed up and restored comes back with a new GUID, so every report bound to the original has to be rebound to the replacement. And gateway relay endpoints are region-bound, so a cross-region target usually needs additional on-premises data gateway configuration and testing — particularly where Bring Your Own Relay is in use — before a single scheduled refresh succeeds.

Unless data residency or another hard constraint forces it, keep the move in the same region and the same tenant, and run consolidation, regional moves and resizing as separate workstreams afterwards. Every one of those changes is a variable that will be blamed for a performance complaint three weeks later. You want the licensing change to be the only thing that changed. If a multi-region estate is unavoidable, buying an F SKU in each target region is a cleaner answer than a cross-tenant rebuild.

Will your Fabric bill be higher than Power BI Premium was?

At list pay-as-you-go rates, often yes — Microsoft's own guidance says PAYG is typically higher than the equivalent P SKU. The levers that close the gap are Azure reservations for steady workloads, pausing capacities that are genuinely idle outside business hours, and resizing on demand rather than paying all year for a month-end peak.

Autoscale as it worked on Premium does not exist on F SKUs. You scale up and down through the Azure portal instead, and the new guardrails — workspace-level surge protection and capacity overage protection — are what stop one runaway notebook from swallowing the capacity everyone else is reporting on. Set Azure budgets and alerts on the capacity's resource group on day one, apply Azure tags so chargeback lands on the right cost center, and watch spend daily for the first month while the baseline settles.

Two costs are easy to miss in the business case. The first is per-user licensing, if the target SKU sits below F64. The second is your own people's time: the sizing analysis, the validation pass, and the month-end you now have to sit through twice. Budgeting the second one honestly is usually what keeps the first one from becoming a surprise.

How we scope and run the engagement

We start with the two facts that set everything else: the date your agreement actually ends, and what your capacity really consumes across a full business cycle. From there the work is a sized recommendation you can defend in a budget meeting, a piloted cutover, validation against your own reports and gateways, and a stabilization window before the old subscription is canceled.

Engagements are led by Edward Pinela, MBA, a principal consultant with more than twenty years in business intelligence and enterprise data work — the person who scopes the migration is the person who runs it. Most Premium-to-Fabric work is a fixed-scope project. If you already have the plan and need senior hands only for the sizing analysis or the cutover itself, Power BI Flex Support starts at $2,500 for 20 hours at $100–$125 per hour, in prepaid blocks whose hours do not expire.

Once the licensing move is done and stable, the wider Fabric surface is open to you — mirroring, shortcuts, Direct Lake, OneLake security. That is the moment to decide whether any of it is worth doing, on its own merits. Those are optional follow-ups rather than migration requirements, and they belong in a Fabric implementation project with its own scope instead of being bolted onto a deadline-driven cutover. If the reporting estate itself needs attention beyond the capacity move, Power BI consulting services is the broader engagement.

Further reading: Microsoft Learn — Power BI Premium to Microsoft Fabric migration overview.