Power BI is not being retired. Power BI Premium per-capacity SKUs are. Microsoft no longer sells new P SKUs, and each existing P SKU subscription ends at the end of its current agreement term. So for most organisations the Power BI Premium to Fabric move already has a date. It is the renewal date in the contract, and it arrives whether or not anyone has planned for it.
That makes this one of the few migrations in the Microsoft estate where the decision has been made for you. What is left to decide is the order you do it in, the size you land on, and who owns the new bill. Those three are where the risk is.
What is actually retiring, and what is not
The scope is narrower than the headlines, and getting it wrong in either direction is expensive.
Retiring: Power BI Premium per capacity, the P1 to P5 SKUs. No new purchases, no add-ons, and customers with an expiring Enterprise Agreement or Microsoft Cloud Agreement cannot renew them.
Not retiring:
- Power BI Pro and Premium Per User. Per-user licences continue as they are, and your users need no licence change as part of this migration.
- Embedded licences (EM and A SKUs). They are not part of this retirement.
- Sovereign clouds. Microsoft Fabric is not yet available there, so P SKUs remain supported until Microsoft publishes separate guidance.
One exception matters for timing. If your Enterprise Agreement is still active, you can keep renewing existing P SKU capacity annually until the agreement ends. That buys time. It does not change the destination, and it makes the renewal of the agreement itself the real deadline. What that agreement is, and what each one changes about running the estate, is set out in CSP, Enterprise Agreement or MCA.
The timeline Microsoft publishes
Microsoft’s migration guidance sets out exactly what happens when a P SKU ends with nothing in its place.
| Phase | When | What happens |
| Retirement | End of your current agreement term | The P SKU subscription ends and cannot be renewed |
| Grace period | Days 1 to 30 | Capacity keeps running at its current size, at no charge |
| Throttled access | Days 31 to 90 | Interactive operations are delayed; data can still be exported |
| Full block | Day 91 onward | All operations rejected; data retained but inaccessible |
Microsoft is blunt about how to read that table: the grace and throttled periods are a safety net, not a planned migration window. Its advice is to migrate now if a P SKU is still active. We agree, and for a practical reason: day 31 is when report users start noticing, and a throttled month-end close is not the moment to be sizing a capacity.
Mapping your P SKU to an F SKU
The mapping is by capacity units, and it is one to one in raw compute.
| P SKU | Fabric equivalent |
| P1 | F64 |
| P2 | F128 |
| P3 | F256 |
| P4 | F512 |
| P5 | F1024 |
F64 is the line that matters for licensing. On F64 and larger, users with only a Fabric Free licence and the Viewer role can still view Power BI content, exactly as they could on a P SKU. On F2 to F32, every viewer needs a Power BI Pro or Premium Per User licence. So an estate that looks oversized on a P1 cannot simply drop to F32 to save money if it has a large read-only audience: the capacity saving can be wiped out, several times over, by the licences it forces.
What changes more than the size is how the capacity is bought:
- Purchase channel. P SKUs were bought through the Microsoft 365 admin center. F SKUs are bought in the Azure portal, which usually means a different budget holder and a different approval path.
- Pricing. P SKUs had global pricing. F SKUs are priced by region, pay-as-you-go by default, with optional yearly reservations.
- Flexibility. F SKUs can be scaled up or down and paused, and they bring Azure-native capabilities such as managed private endpoints, trusted workspace access, Azure Monitor and Cost Management.
- Report Server. Power BI Report Server remains available, included with a Fabric reservation of F64 or higher.
The order that avoids an outage
The single most common way to turn this into an incident is to cancel first. Microsoft’s guidance is explicit about the sequence, and it is worth following exactly:
- Buy the F SKU first, in the same region as the P SKU unless data residency requires otherwise.
- Reassign workspaces to the new capacity. For large estates Microsoft provides an automated route through the Fabric REST APIs.
- Validate across a full business cycle, including month-end and quarterly close, using the Fabric Capacity Metrics app against the baseline you captured on the P SKU.
- Then cancel the P SKU.
For the first 30 days on the new capacity, track spend daily in Azure Cost Management and set budgets and alerts on the capacity’s resource group. Consider a reservation once daily consumption is steady, not before.
Our position: move like for like, then right-size from evidence
In our view the right Power BI Premium to Fabric migration lands on the direct equivalent first, P1 to F64, and only then right-sizes from measured consumption.
The temptation is to use the migration to cut the capacity on day one, because the bill is suddenly visible in Azure and someone wants a saving to show. We would not do that. A capacity sized on a quiet week fails at month-end, and the F64 line means a downsize can move cost from capacity into licences rather than removing it. Measure through a real close, then decide.
The migration is, however, the right moment to fix one structural thing. Microsoft describes a common pattern when moving from a single P1: keep one F64 for production, and add a smaller F SKU for development and test that is paused when idle. Many P1 estates run development work on the production capacity simply because there was no cheap alternative. Now there is. Microsoft attaches one caution to that, and it is worth repeating: do not split a capacity that is already running close to its ceiling without scaling up first, because the split moves the overload rather than removing it. It also publishes no recommended split sizes, so the baseline decides this too. How to split and charge back capacity is covered in Fabric capacity planning and chargeback.
Where this connects
Two related pieces are worth reading alongside this one.
If your Power BI estate was built on older guidance, our enterprise Power BI deployment guide still covers modelling, refresh and governance, with a note on reading its capacity recommendations as F SKUs.
And if your data platform also runs on Azure Synapse, the capacity move is a natural point to plan what changes when you migrate off Synapse, so you land on one platform rather than two.
Where to start
This week, not at renewal:
- Find the end date of every P SKU subscription and the agreement it sits under, and check whether an active Enterprise Agreement changes it. Microsoft’s advice is to confirm the specific terms with your Microsoft account representative before fixing a migration date.
- Baseline consumption with the Capacity Metrics app, and note the viewer audience on each capacity.
- Buy the F SKU in the same region and agree who owns it in Azure.
- Reassign and validate through a real close, then cancel the P SKU.
Veratas runs this as part of a Microsoft Fabric implementation, from the capacity move through right-sizing and the platform work that usually follows it. If Fabric is new to the estate rather than a destination for an existing one, what the first six weeks deliver sets out the foundation underneath it.
If your renewal date is inside the next six months and nobody owns the move yet, talk to our team. It is far easier before day one than after day 31.
Frequently asked questions
Is Power BI being retired? No. Only Power BI Premium per-capacity SKUs, P1 to P5, are retiring. Power BI Pro, Premium Per User and embedded licences are not affected.
When does our Power BI Premium capacity stop working? At the end of the current agreement term. Content then stays available at no charge for a 30-day grace period, is throttled from day 31 to day 90, and is blocked from day 91 until the workspaces move to a Fabric capacity.
Which Fabric SKU replaces a P1? F64. The mapping by capacity units is P1 to F64, P2 to F128, P3 to F256, P4 to F512 and P5 to F1024. Right-size from measured consumption after the move.
Do report viewers need Pro licences after moving to Fabric? Not on F64 or larger, where Fabric Free users with the Viewer role can view content as they did on a P SKU. On F2 to F32, every viewer needs a Pro or Premium Per User licence.
Can we keep renewing our P SKU? Only while an Enterprise Agreement is active, annually until the agreement term ends. Customers with expiring Enterprise Agreements or Microsoft Cloud Agreements cannot renew.
What is the safest order to migrate in? Buy the F SKU first, reassign and validate workspaces through a full business cycle, then cancel the P SKU. Cancelling first starts the grace period with nothing to move to.
Will the move cause downtime? For a same-region reassignment of standard Power BI items, Microsoft expects none beyond any refreshes running at the time. A cross-region move is different: large storage format semantic models and Fabric items have to be backed up, deleted and recreated in the new region, and they are unavailable while that happens. Allow up to an hour after reassignment before users can create Fabric items on the new capacity.
Azure and Business Intelligence Architect with 17+ years of experience delivering cloud data and analytics solutions. Focus areas include Azure data platforms, ETL and ELT architecture, and enterprise BI on Microsoft Azure.