Power BI Premium to Fabric Capacity: The Migration Runbook

Microsoft is retiring Power BI Premium per-capacity SKUs (P1–P5) at the end of each customer’s current agreement term, and the migration to Fabric F SKUs is manual. EPC Group’s runbook sequences it: buy the F SKU first, triage workspaces by blast radius, reassign in batches, validate, then cancel. Never the reverse. EPC Group is a Houston-based Microsoft consulting firm operating since 1997, with six Microsoft Solutions Partner designations and 216+ M&A tenant migrations covering 1.83 million users.

Quick facts

What Microsoft actually retired — and what it did not

Read the scope precisely; most internal panic here is misdirected. The retirement applies to per-capacity SKUs. Power BI Pro ($14.00 per user/month, paid yearly) and Premium Per User ($24.00) continue unchanged. Embedded EM and A SKUs are out of scope. Our Power BI Premium and Premium versus Premium Per User pages cover the per-user side.

What changes is the ownership model. A P SKU was bought in the Microsoft 365 admin center against an M365 commitment, priced globally, fixed in size for the term. An F SKU is an Azure resource: bought in the Azure portal, priced regionally, resizable on demand, pausable, taggable for chargeback, countable against a Microsoft Azure Consumption Commitment, and visible in Microsoft Cost Management. Trusted workspace access, managed private endpoints and Azure Monitor become available. Power BI Premium autoscale — the P SKU feature that added v-cores billed per 24-hour period — does not exist on F SKUs; the equivalents are on-demand resizing and capacity overage.

Two consequences follow. Your Power BI cost centre moves from the M365 bill to the Azure bill, usually a different approver and budget line — start that conversation in week one. And Power BI Report Server changes footing: on F SKUs it comes through a Fabric capacity reservation of F64 or higher, or SQL Server Enterprise Edition with Software Assurance. Verify that licence before you cancel.

The renewal-date trap

The renewal date is the forcing function. Everything else is scheduling around it.

Microsoft’s grace and throttled-access windows are a safety net, not a migration window. If your subscription ends with no F SKU in place, the estate degrades on a published clock: 30 days of free grace, 60 days of interactive delay, then a hard block on day 91. Your data is retained, but that block is a full business outage for every consumer on the capacity.

1. Enterprise Agreement still active? You can keep running existing P SKU capacity and renew it annually through the agreement until the EA term ends. Confirm your contract terms with your Microsoft account representative — this is contractual, not product, behaviour. Set the migration date at EA term end minus 90 days.
2. EA or Microsoft Cloud Agreement expiring? You cannot add or renew P SKU capacity through it. Migrate now; do not wait for the renewal conversation.
3. Baseline consumption data in hand? With 30–45 days of Capacity Metrics history on the P SKU you are ready to size and buy. Without it, install the app today — that collection is the long pole.
4. Mid-year with no renewal pressure? Migrate anyway. Every P capacity is now on a dead commercial path, and migrating on your schedule costs a fraction of migrating on a deadline.
5. Sovereign cloud? Unaffected for now. Revisit when Microsoft publishes sovereign guidance.

Renewal minus 90 days gives you a four-to-eight week execution window plus a real buffer, and keeps the grace period as untouched reserve.

The Dual-Run Handover Model

The Dual-Run Handover Model is EPC Group’s framework for this migration. Its governing idea: for a defined window you pay for both capacities at once, and the project should be designed to make that window short, cheap and safe rather than to avoid it. Teams that eliminate the overlap by cancelling early end up in the day-91 block. Durations below are typical for a single-region estate of 40–120 workspaces.

Two rules are non-negotiable: the F SKU is purchased before any workspace moves, and the P SKU is cancelled only after the last workspace is validated on F. Every catastrophic version of this project violates one of them.

Workspace triage: which workspaces move first, and why

Reassignment takes seconds, which makes it tempting to move everything at once. Do not. The risk is not in the reassignment; it is in what you discover afterwards, and you want to discover it on a workspace nobody is watching.

Score each workspace on two axes. Blast radius — who notices if it breaks: distinct viewers over 30 days, executive audience, whether it backs an app or embedded surface. Item complexity — how many things can fail: large storage format models, Fabric items (Lakehouse, Warehouse, Notebook, pipeline, Eventstream, KQL database, Dataflow Gen2), gateways, deployment pipelines, XMLA write clients, paginated reports.

Two triage rules repeatedly save projects. Run discovery against every workspace, not just the ones you expect to hold Fabric items — users create them during trials, and those are exactly the items that do not survive a cross-region move. And treat cross-region changes as a separate project: standard Power BI items survive a cross-region reassignment, but large storage format models and all Fabric items do not, and restored models get a new GUID that forces report rebinding. Migrate same-region, then run consolidation, resizing and regional moves as separate Fabric workstreams.

The cost-delta worksheet

You cannot get this number from a pricing page, because the P SKU side is contractual — P SKU list pricing is no longer published on Microsoft’s Power BI pricing page. The worksheet starts with your invoice, not a rate card. Build one row per capacity.

All rates are US East, as published at time of writing (July 2026), from the Azure Retail Prices API and Microsoft’s Fabric pricing page. F SKUs are priced regionally and P SKUs were priced globally, so the delta is not uniform across a multi-region estate. Three things this worksheet exposes that a rate-card comparison never does:

Line F is real money. A six-week dual-run on an F256 at reserved rates is roughly $30,000 no vendor comparison table shows you. Budget it, and shorten it by batching aggressively once the pilot is clean.

Line G is the sizing cliff. Right-sizing a P1 down to an F32 looks like a 50% compute saving until you count the viewers who lose free access. At 400 viewers, Pro licences at $14/user/month cost $5,600/month — more than the compute saved. Below F64, do the licence arithmetic first.

Line D is a commitment, not a discount. A reservation is a one- or three-year commitment for a quantity of CUs in a region. It does not cover storage or networking, and it does not renew automatically unless you enable renewal. It also interacts badly with the pause-and-resume savings play: pausing stops the compute billing meters, but a reservation is prepaid capacity. Reserve your always-on floor, run the variable tier pay-as-you-go, and confirm the interaction with your Microsoft account team. Our Power BI cost and licensing guide works the per-user side, and Fabric capacity FinOps and right-sizing takes over once you are live.

Sizing from evidence, not from the mapping table

P1→F64 is a compute-equivalence reference. Microsoft is explicit that it should not be read as functional or licensing equivalence.

Open the Capacity Metrics app against the P capacity and review the maximum period available, accounting for Premium autoscale — autoscale on P inflates what you appear to need on F, because it was compute you bought separately. Sustained periods near 100% CU utilization justify the equivalent or larger SKU; long low-utilization stretches justify a smaller SKU plus a pause schedule. Then add the Fabric workloads you plan to introduce after migration using the Fabric SKU Estimator, which models forward consumption from a workload profile rather than history. The F SKU cost model derives the reserved break-even in full.

If you plan to split one P1 into a production F SKU plus a smaller dev/test F SKU you pause when idle, check total consumption first. Splitting a capacity already near 100% utilization creates overloads on both halves. Scale up before you split. See our Fabric consulting services guide for the post-go-live discipline.

The rollback plan

Most teams skip this because reassignment is fast and reversible. It is reversible — until it isn’t.

Reversible states. While the P SKU is active and paid, you can reassign a workspace back to it — the entire reason the P capacity stays alive through Phase 5. If a wave fails validation, reassign it back to P, fix, re-run. Keep the P capacity’s admin list intact.

Irreversible states. Three actions cross the line. Cancelling the P SKU starts the grace/throttle/block clock with no path back — make it a change-controlled event with a named approver. Cross-region reassignment of a workspace holding Fabric items or large storage format models removes those items; recovery is from your backup, not from Fabric. Git-syncing a migrated workspace against a repository missing items can delete them — restore Fabric items into a separate workspace and verify counts before moving them across.

Pre-conditions before any wave. Capture item definitions to Git through Fabric Git integration; Git captures definitions, not data. Copy Lakehouse files and Warehouse tables outside the workspace. Back up large storage format models via XMLA tooling or Premium backup/restore, and record report-to-model bindings so you can rebind after the GUID changes. Record item counts per workspace — comparing counts after discovery is your most reliable validation signal.

Abort criteria. Roll the wave back if refreshes fail on more than one workspace for an unisolated cause, or if item counts do not reconcile. Sustained 100% CU utilization in the first 24–48 hours is a sizing signal, not a correctness failure — scale up on demand before continuing.

Communications plan for report consumers

Capacity migration is invisible when it works, so the only messages people remember are about failures. Send fewer, more specific ones.

Put two details in every pre-move message: report URLs do not change, and per-user licences do not change. Those two questions generate most ticket volume. Our Power BI gateway guidance covers the refresh-path checks.

What breaks — failure modes

What changed in 2026

• Microsoft published a dedicated P-to-F migration doc set — overview, decision guide, how-to and FAQ under power-bi/support/. Previously the only official guidance was the licensing page and a blog post. If you scoped this project in 2025, re-scope it.
• The retirement timeline is now explicit. The 30-day grace / day-31 throttle / day-91 block sequence is documented, making the renewal date a plannable milestone.
• The bulk path is scripted. Microsoft’s semantic-link-labs Capacity Migration notebook handles many-workspace and split-across-capacity scenarios.
• The Capacity Metrics app gained a Health page and the Chargeback app went generally available in May 2026. Health surfaces utilization, throttling and cumulative debt across every capacity you administer; Chargeback allocates CU consumption by workspace, item, domain and user.
• Capacity overage entered preview — an opt-in way to pay through a spike at 3× the pay-as-you-go rate instead of throttling. Not a substitute for correct sizing.
• Workspace-level surge protection entered preview, adding per-workspace CU limits, auto-blocking and a mission-critical exemption — controls that did not exist on P SKUs.

Frequently asked questions

Sources and verification

Every figure above is a Microsoft list price or a Microsoft-published behaviour, traceable to one of these. Rates are US East as published July 2026; F SKUs are priced regionally, so confirm your own region before modelling.

1. Microsoft Learn — Power BI Premium to Microsoft Fabric migration overview
2. Microsoft Learn — P SKU to F SKU migration decision guide (retirement timeline, grace/throttle/block)
3. Microsoft Learn — Migrate workspaces from Power BI Premium to Microsoft Fabric (step order, troubleshooting)
4. Microsoft Learn — Power BI Premium to Microsoft Fabric migration FAQ
5. Microsoft Learn — Understand Microsoft Fabric licenses (SKU-to-CU table, F64 viewer rule)
6. Microsoft Learn — Microsoft Fabric features by SKU and capacity type
7. Microsoft Learn — What is the Microsoft Fabric Capacity Metrics app?
8. Microsoft Learn — Understand the metrics app Health page
9. Microsoft Learn — Microsoft Fabric Chargeback app
10. Microsoft Learn — What is the Fabric SKU Estimator (preview)?
11. Microsoft Learn — Save costs with Microsoft Fabric Capacity reservations
12. Microsoft Learn — Pause and resume your Fabric capacity
13. Microsoft Learn — The Fabric throttling policy
14. Microsoft Learn — Capacity overage (preview) in Microsoft Fabric
15. Microsoft Learn — Surge protection
16. Microsoft Learn — Manage your Fabric capacity
17. Microsoft Learn — Reassign a workspace to a different capacity
18. Microsoft Learn — Plan your capacity size
19. Microsoft — Microsoft Fabric pricing
20. Microsoft — Power BI pricing (Pro $14.00, PPU $24.00 per user/month paid yearly, July 2026)
21. Azure Retail Prices API — serviceName eq 'Microsoft Fabric', armRegionName eq 'eastus'. Source of every dollar figure here, as published July 2026
22. Microsoft — semantic-link-labs Capacity Migration notebook (bulk and split scenarios)

Where to go next

If your Enterprise Agreement renews in the next twelve months, the migration date is already fixed — you just haven’t written it down. EPC Group runs the baseline, triage grid and cost-delta worksheet as a fixed-scope assessment and hands you a dated runbook. Start with Microsoft Fabric consulting or Power BI consulting.

Related: Power BI Premium · Premium vs PPU · Fabric vs Databricks · Snowflake to Fabric · Data governance firms · Microsoft consulting firms · Power Platform firms · Houston · Phoenix · Microsoft Frontier Company · CFO AI governance · Power BI pricing and licensing