On 14 March 2024, Microsoft confirmed what the data industry had anticipated: Power BI Premium Per Capacity P-SKUs are being retired. The announcement marked a formal consolidation of Microsoft's analytics licensing into a single platform Microsoft Fabric, managed through Azure rather than Microsoft 365. For organisations that have built enterprise BI programmes on Power BI Premium capacity, this is not a distant planning item. Every existing P-SKU customer will need to migrate to a Microsoft Fabric F-SKU at their next renewal, and the decisions made now about SKU sizing, cost modelling, and workspace migration sequencing will determine how smooth that transition is.

Why Microsoft Is Retiring Power BI Premium Per Capacity

The retirement of Power BI Premium Per Capacity Microsoft Fabric is driven by a strategic platform consolidation, not a cost-cutting exercise. Power BI Premium was provisioned through Microsoft 365, while Microsoft Fabric runs on Azure infrastructure. Operating two separate licensing and provisioning frameworks for what is increasingly a unified analytics platform created purchasing complexity, governance fragmentation, and a bifurcated feature roadmap.

By consolidating onto Fabric F-SKUs, Microsoft routes all capacity purchasing through Azure, enabling organisations to apply Fabric spend against Microsoft Azure Consumption Commitments (MACC). This is commercially significant for organisations with large Azure Enterprise Agreements spend that previously sat outside their Azure commitment now counts toward it. Beyond the commercial benefit, the consolidation unlocks Azure-exclusive features for all capacity customers: Trusted Workspace Access for OneLake shortcuts, Managed Private Endpoints for Spark, and the full Fabric workload set that was unavailable on P-SKUs.

"The retirement of Power BI Premium Per Capacity is not a disruption, it is a platform maturation. Organisations that plan their P-SKU to F-SKU migration deliberately will exit the process with more analytical capability, better cost visibility, and a stronger position on their Azure commitment."

What Changes and What Stays the Same

The most important signal in Microsoft's announcement is what does not change. All existing Power BI Premium capabilities, large semantic models, advanced AI features, deployment pipelines, paginated reports, XMLA endpoints, dataflows, and report sharing without per-user Pro licences - remain fully available on Fabric F-SKUs. Organisations moving from a P1 to an F64 do not lose any Power BI functionality they currently depend on. The product experience for Power BI workloads is identical.

What does change is the provisioning model, the billing relationship, and the breadth of available workloads. F-SKUs are provisioned through the Azure portal rather than the Microsoft 365 admin centre. They are billed through Azure, making them eligible for MACC and Azure Hybrid Benefit. And they unlock the full Microsoft Fabric workload set Lakehouse, Data Engineering notebooks, Data Factory Gen2, Real-Time Intelligence, and Data Science, as capabilities that can be consumed from the same capacity budget that previously served only Power BI.

One capability that does not transfer to Fabric is Power BI Report Server, the on-premises report hosting component that came bundled with P-SKU licences. Organisations relying on Report Server for on-premises BI distribution will need to address this separately. The on-premises use case is not supported by F-SKUs, and any dependence on Report Server should be identified and planned for before the migration is executed.

P-SKU to F-SKU Mapping: Understanding Compute Equivalence

Microsoft designed the F-SKU series to provide direct compute equivalence to the P-SKU series, simplifying capacity sizing decisions for migrating organisations. The mapping is straightforward: each P-SKU maps to a specific F-SKU at the same compute level, measured in Capacity Units (CUs).

The compute equivalence means that workloads running on a P1 should perform identically on an F64 with no re-tuning required. For capacity administrators who have spent time optimising query performance and managing CU consumption on P-SKUs, the migration does not reset that work, the same performance characteristics apply at the equivalent F-SKU tier. For a more detailed breakdown of F-SKU tier selection, our guide to choosing the right Microsoft Fabric SKU covers workload sizing, cost modelling, and tier selection in depth.

Cost Model Differences: Reserved vs Pay-As-You-Go Pricing

The pricing model for Microsoft Fabric F-SKUs differs structurally from the P-SKU model, and understanding this difference is essential before committing to a migration timeline. P-SKUs were priced as flat monthly subscriptions, a fixed cost regardless of actual utilisation. An organisation paying for a P1 at approximately $4,995 per month was billed that amount whether the capacity ran at 10% utilisation or 100%.

Pay-As-You-Go F-SKUs

F-SKUs on a pay-as-you-go basis are billed per hour of active capacity approximately $7.30 per hour for an F64 at list pricing. The critical difference is that F-SKUs can be paused when not in use, so an organisation that runs an F64 for 12 hours per weekday and pauses it evenings and weekends pays for approximately 240 billing hours per month rather than 720, producing a monthly cost of roughly $1,750 well below the P1 equivalent. For organisations with clearly defined operational hours and workloads that do not require 24-hour availability, pay-as-you-go F-SKUs can deliver significant cost reduction.

Reserved F-SKUs

For organisations that require continuous capacity availability 24/7 Power BI report access, continuous data refresh, or always-on real-time analytics the reserved pricing model provides cost predictability comparable to the P-SKU structure. One-year and three-year reserved F-SKU commitments offer discounts of approximately 40–50% versus pay-as-you-go list pricing, bringing the effective monthly cost of an F64 on a three-year reservation into close parity with a P1 subscription. MACC-eligible organisations can apply reserved F-SKU spend against their Azure commitment, which further reduces the net effective cost.

Grace Period and Migration Timeline

Microsoft has structured the transition with a formal grace period to reduce the risk of service interruption for organisations that do not migrate immediately at renewal. Existing customers can continue renewing P-SKU agreements until their current contract end date. After that date, renewal is not available and migration to F-SKUs becomes mandatory.

At the point of P-SKU expiry, Microsoft provides 30 days of free F-SKU capacity at the equivalent tier to give the migration team time to reassign workspaces without paying for two capacities simultaneously. After the 30-day free period, all new interactive operations are slowed by a 20-second submission delay, with the capacity potentially being frozen entirely 90 days or more after the subscription end date. Organisations that plan to use the full 90-day window as their migration period are taking a significant operational risk; the throttling behaviour during that window will disrupt production workloads.

The practical implication is clear: migration planning should begin at least three to four months before the P-SKU renewal date, not after it lapses.

How to Migrate: Workspace Reassignment Step by Step

The core technical migration action is workspace reassignment, moving workspaces currently assigned to a P-SKU capacity to a newly provisioned F-SKU capacity. This is operationally straightforward for small environments and becomes more complex at scale.

For small tenants with fewer than 20 workspaces, manual reassignment through the Power BI Admin portal or workspace settings is sufficient. Navigate to each workspace's settings, change the capacity assignment from the existing P-SKU to the new F-SKU, and confirm. Report access and dataset refresh schedules are unaffected by the reassignment, the transition is transparent to end users.

For large enterprise tenants with hundreds or thousands of workspaces, Microsoft provides an automated migration tool built on Fabric REST APIs. This tool enables bulk reassignment through a scripted process, reducing what would otherwise be a weeks-long manual effort to hours. Organisations using this tool should run it in a non-production environment first, validate that all workspace assignments and permissions transfer correctly, and test a representative sample of reports and refresh schedules before executing the production migration.

What Microsoft Fabric Adds Beyond Power BI Premium

The Power BI Premium Per Capacity to Microsoft Fabric migration is not simply a licensing change, it is an expansion of analytical capability available to the organisation. On an F-SKU, the same capacity budget that previously served only Power BI workloads now supports Fabric Lakehouse, Data Engineering (Spark notebooks), Data Factory Gen2 pipelines, Real-Time Intelligence with Eventhouse and KQL Database, Data Science with MLflow integration, and the full OneLake data architecture including shortcut access to Azure Data Lake Storage Gen2, Amazon S3, and Google Cloud Storage.

For data engineering teams that have been running Azure Data Factory pipelines and Synapse Spark pools as separate Azure services alongside Power BI Premium, consolidating those workloads onto Fabric capacity simplifies the architecture and reduces the total monthly Azure bill. The incremental cost of data engineering capability within Fabric is the shared utilisation of CUs already purchased for Power BI not an additional licence. For a deeper comparison of Fabric's capabilities against the Synapse stack it replaces, see our guide to the Azure Synapse vs Microsoft Fabric feature comparison.

Next Steps: Planning Your Migration Before Your Renewal Date

The most effective starting point for Power BI Premium Per Capacity to Microsoft Fabric migration planning is identifying your P-SKU renewal date and working backward from it. A well-executed migration for an organisation with 50–200 workspaces requires four to eight weeks from initial F-SKU provisioning to validated production cutover. Larger environments with complex governance configurations or extensive XMLA-connected tools will need more.

Before provisioning the F-SKU, run the Fabric Capacity Metrics app against your current P-SKU capacity for at least two weeks to establish a baseline utilisation profile. This tells you whether your existing P1 is consistently under-utilised in which case a pay-as-you-go F64 with pause scheduling may cost materially less or whether it runs near capacity during business hours, pointing toward a reserved pricing commitment. Getting this analysis right before signing an F-SKU agreement prevents over- or under-provisioning at a commitment level that locks in for 12 or 36 months.

If your organisation needs to structure the migration programme, assess F-SKU sizing, negotiate the MACC application, or design the Fabric workload architecture that extends beyond Power BI, our Microsoft Fabric consulting team at Numlytics can lead that work end to end. We work with data and IT leadership across the US, UK, Australia, and UAE. Speak with a certified Fabric consultant to scope your migration before your renewal window opens.

For help managing capacity consumption after migration, see our guide to limiting capacity utilization in Microsoft Fabric, a practical overview of the governance controls available to prevent unexpected CU overruns.