Co-authored by

What Is Being Retired — and What Isn't

Quick answer: Only Power BI Premium per-capacity (P-SKUs: P1 through P5) is retiring. Power BI Pro and Premium Per User (PPU) continue unchanged. If your organization holds a P1, P2, P3, P4, or P5 capacity, you are in scope for this migration. If you use only Pro or PPU licenses, nothing changes.

This distinction matters because many organizations hold a mix. A P1 capacity lets finance publish reports without per-user licensing; Pro licenses cover the analysts doing the publishing. The capacity is what is ending — the Pro licenses persist.

What replaces P-SKUs is Microsoft Fabric capacity, sold as F-SKUs (F2 through F1024) purchased through Azure. The compute equivalence is direct: F64 replaces P1, F128 replaces P2, and so on. What changes is the billing model (Azure hourly instead of fixed monthly), the product branding, and the scope — Fabric F-SKU capacities also unlock Data Engineering, Data Warehouse, Real-Time Intelligence, and Data Science, not just Power BI.

If you run only Power BI on Premium today, your reports, semantic models, workspaces, and row-level security definitions all carry over unchanged after a workspace reassignment. The migration is a metadata operation. Reports do not need to be republished or rebuilt.

The Deadlines That Apply to You

Quick answer: New P-SKU purchases ended July 1, 2024. Non-EA customers lost renewal rights on February 1, 2025 — that cutoff has already passed. EA customers may renew through their active Enterprise Agreement term. When a P-SKU subscription ends, you have 30 days of free matching capacity, then throttling from day 31 onward, and potential capacity freeze after day 90.

Most of this timeline has already happened. The question for organizations still on P-SKUs is not whether to migrate but when their expiry date falls.

How to tell which bucket you are in. Check your billing portal or ask your Microsoft account team. If your organization purchased through a Microsoft Enterprise Agreement, your EA expiry date is the hard deadline — post-expiry, you lose the ability to renew the P-SKU. If you purchased through the Microsoft 365 admin center or a cloud reseller, the February 2025 non-EA cutoff already applied.

The throttling mechanics matter for operations planning. After 30 days of free matching capacity, Microsoft delays all new interactive operations by 20 seconds on submission. For a finance dashboard used at month-end close, that is not a quiet performance degradation — it is a visible failure for every user who opens a report. After day 90, the capacity can be frozen entirely, blocking access to all Power BI data in workspaces assigned to that capacity.

Source: Microsoft Power BI Blog — Grace period for transitioning from Power BI Premium to Microsoft Fabric

Your Like-for-Like Target: P1 to F64

Quick answer: F64 replaces P1. The full P-to-F mapping follows a straightforward compute-unit equivalence. At F64 and above, Power BI report viewers need only a free Fabric license — the same viewer access that existed at P1.

The compute unit equivalence, from Microsoft Learn — Understand Microsoft Fabric licenses:

The F64 free-viewer threshold is the key parity point for most organizations. If you ran P1 specifically to share reports with hundreds of viewers without per-user licensing, that same capability transfers at F64. Below F64 — F2 through F32 — every viewer still requires a Pro or PPU license. Downsizing from P1 to F32 to cut costs would force you to license your entire viewer population, likely at a higher total cost than staying at F64.

On pricing. F-SKUs bill per hour through Azure. F64 at pay-as-you-go costs approximately $8,410 per month (US West 2 rates at $0.18/CU/hour). With a 1-year Azure reservation, that drops to approximately $5,003 per month — close to the former P1 list price of $4,995 per month. For production capacity running around the clock, the reservation is almost always the right choice. For development or test environments you actively pause outside business hours, pay-as-you-go with overnight pausing can cut the cost by 40–50%.

For a full breakdown of Pro, PPU, and Fabric scenarios across different organization sizes, see the Power BI licensing comparison guide. If cost optimization is the primary concern, the Power BI licensing cost optimization guide covers where Premium-tier features have justified their cost and where they have not.

The Migration Checklist

Quick answer: Six steps: inventory current P-SKU usage, select your F-SKU size, provision Fabric capacity in Azure, reassign workspaces, validate refresh schedules and RLS, then decommission the old capacity. The workspace reassignment is a metadata operation — no reports need to be rebuilt.

Step 1 — Inventory current P-SKU utilization

Run the Fabric Capacity Metrics App against your Premium capacity before provisioning anything. You need to know: peak CU consumption by workload, which workspaces are assigned to the P-SKU, and which semantic models run on scheduled refresh. Document the refresh count, refresh window timing, and any dataflows feeding into models.

Also pull the full list of workspaces assigned to Premium capacity from the Power BI admin portal (Capacity settings). This list becomes the reassignment manifest for step 4.

Step 2 — Select your F-SKU size

Start from the P-to-F equivalence table above for like-for-like parity, then adjust based on actual utilization from the Capacity Metrics App. Organizations with consistently low P1 consumption can sometimes run on F32 if they are willing to license viewers per-user. If free-viewer access is a requirement, F64 is the floor.

If you are also planning to use Fabric Data Engineering or Real-Time Intelligence in production, F64 is a practical minimum. Below F64, some workloads become capacity-constrained quickly. The Microsoft Fabric enterprise adoption roadmap covers sizing in more depth for organizations going beyond Power BI.

Step 3 — Provision Fabric capacity in Azure

Create the Fabric capacity through the Azure portal, not the Microsoft 365 admin center. Select the Azure region that matches your Power BI tenant home region — for UAE-based organizations, that is UAE North (the only GCC region with full Fabric support as of 2026). Assign a capacity administrator and configure auto-scale limits if appropriate.

If you plan to purchase a reservation, do it at this step or within the first billing period. The capacity can run pay-as-you-go initially and a reservation applied retroactively within the same billing month, but cleaner to lock it in upfront.

Step 4 — Reassign workspaces from P-SKU to F-SKU

Workspace reassignment is a metadata change in the Power BI admin portal under Capacity settings. It does not interrupt active user sessions mid-report-load, but it cancels any in-flight refresh jobs running at the moment of reassignment. Schedule the cutover during a low-activity window — not at month-end close, and not mid-refresh window.

Microsoft provides an automated migration tool using Fabric REST APIs for organizations with large workspace counts. For most organizations with fewer than 50 workspaces, the admin portal is sufficient.

Step 5 — Validate refresh schedules and RLS

After reassignment, manually trigger the three to five most critical semantic model refreshes and confirm they complete cleanly. Check refresh history in the Power BI service. Focus on:

• Models using gateway connections — confirm the on-premises data gateway resolves correctly after reassignment
• Models with incremental refresh — verify the first post-migration refresh does not trigger a full historical reload
• Reports with row-level security — use the "View as role" feature in Power BI Desktop to confirm RLS filters apply correctly on the new capacity

RLS is not affected by capacity migration itself, but it should be validated before users are told the cutover is complete. A misconfigured role on a finance report that exposes cross-departmental data is a harder conversation than a 10-minute validation step.

Step 6 — Decommission the P-SKU capacity

Once all workspaces are on the F-SKU and the first full refresh cycle completes without errors, cancel the P-SKU subscription. The reserved pricing savings do not fully materialize until you are off the P-SKU billing. Document the cancellation date — that is the moment the new cost profile begins.

Operational Gotchas to Avoid

Quick answer: Four traps catch organizations mid-migration: pausing capacity cancels in-flight jobs (drain first), Azure reservations bill even when capacity is paused, scaling below your reservation size does not reduce the bill, and auto-scale overage costs roughly 3× the standard rate.

Drain critical jobs before pausing or migrating

When you pause a Fabric capacity or migrate workspaces away from it, any running refreshes, Spark notebooks, and pipeline runs are cancelled immediately — not gracefully completed, not queued. If you need to pause capacity during the migration window to avoid double-billing, confirm no refreshes are running first. The safest cutover window is the gap after your last overnight refresh completes and before your first morning user session starts.

Reservation billing does not pause with capacity

If you purchase an F64 Azure reservation and later pause the capacity overnight to save costs, the reservation continues billing. Reservations are capacity commitments, not consumption-based pricing. Only the pay-as-you-go overage — burst above the reserved size — stops when the capacity is paused.

The practical implication: for production capacities running 24×7, reservations offer meaningful savings (approximately 41% vs. pay-as-you-go). For development or test capacities you actively pause on evenings and weekends, pay-as-you-go is typically cheaper than a reservation you cannot switch off.

Scaling below your reservation does not lower the bill

Reservations are bound to a specific CU size. If you reserve F64 and later scale down to F32, the F64 reservation continues billing — you are running F32 compute at F64 cost. Changes to reservation size require either a new reservation purchase or a support ticket through Azure. For organizations that want burst capability with cost control, the cleaner pattern is a reservation at baseline size with auto-scale enabled for peaks.

Auto-scale overage is not free insurance

If auto-scale is enabled on a Fabric capacity, Microsoft charges burst units at approximately 3× the reservation per-unit rate. A single data engineering job that spikes unexpectedly can generate significant overage charges. Set an auto-scale maximum unit limit to cap exposure, and monitor utilization with the Capacity Metrics App through the first 30 days after cutover.

When to Bring in Help

Quick answer: If you have more than 50 workspaces, incremental refresh on large models, or RLS roles that enforce cross-departmental data boundaries, a structured migration engagement avoids data access incidents and billing surprises that are expensive to unwind.

The steps above are manageable for organizations with a single P1, clean workspace structure, and predictable refresh schedules. Complexity grows when:

• Multiple P-SKU capacities with different EA renewal dates are in play
• Incremental refresh is active on large models — a full historical reload on a multi-billion-row fact table after a failed migration is a multi-hour recovery, not a 10-minute rollback
• RLS is enforced across dozens of roles with dynamic username-based filtering
• The organization also wants to stand up Fabric Data Engineering alongside the capacity swap, introducing lakehouse provisioning, OneLake shortcuts, and medallion architecture decisions

The Microsoft Fabric enterprise adoption roadmap for UAE and Saudi covers the full platform buildout for organizations going beyond a simple capacity swap.

Beyond The Analytics runs P-SKU to Fabric migration assessments for GCC enterprises: a capacity audit using the Fabric Capacity Metrics App, a workspace inventory, an F-SKU sizing recommendation, and a cutover plan sequenced around your refresh schedule and reporting calendar. If your EA is approaching renewal or you are already inside the grace period, reach out before the throttling window starts.

Frequently Asked Questions

Q: When is Power BI Premium retiring?

Power BI Premium per-capacity (P-SKUs) is already in retirement. New P-SKU purchases ended July 1, 2024. Non-EA customers could not renew after February 1, 2025. EA customers can continue renewing until their Enterprise Agreement expires. The capacity does not switch off on a single date — it ends at your specific subscription renewal, followed by the 30-day free grace period and the 90-day data-access window.

Q: What replaces my P1 capacity?

Fabric F64 is the like-for-like replacement for P1. Both provide 64 Capacity Units (8 v-cores). At F64, Power BI report viewers need only a free Fabric license, matching the P1 viewer-access model. The difference is the billing model (Azure hourly vs. fixed monthly) and the fact that F64 also unlocks the full Fabric platform: Data Engineering, Data Warehouse, Real-Time Intelligence, and Data Science.

Q: Will my reports break during the migration?

Reassigning workspaces from P-SKU to F-SKU is a metadata operation. Reports, semantic models, dashboards, and row-level security definitions transfer without republishing or rebuilding. The only interruption risk is refreshes running at the exact moment of workspace reassignment — those are cancelled, not queued. Schedule the cutover during a low-activity window and validate refreshes manually before telling users the migration is complete.

Q: Is there a grace period if my P-SKU expires before I migrate?

Yes, but the grace period is a managed wind-down, not a safety net. Microsoft provides 30 days of free matching capacity after your subscription ends. After that, all interactive operations are delayed by 20 seconds on submission. After 90 days, the capacity may be frozen and access to Power BI data in the affected workspaces can be blocked. Plan to complete the migration before the subscription end date, not after.