Power BI Premium Is Being Retired: A 90‑Day Renewal Countdown Checklist

Scenario: A Team With One Busy P3 Capacity

We’ll use a common setup:

• One Power BI Premium P3 capacity in a production tenant.
• Mix of:
  • Classic Power BI semantic models (Import, DirectQuery, Composite).
  • Paginated reports.
  • A few dataflows (Gen1 and some recently created Gen2).
  • One or two Fabric trial workspaces someone spun up and never fully adopted.
• The capacity is used by:
  • Finance and operations reports refreshed daily.
  • Executive dashboards with large DirectQuery models.
  • Paginated reports for regulatory packs.

The renewal notice says the P3 term is ending, and your account team is talking about F SKUs and Fabric capacity instead.

Your risks in the next 90 days:

• Lose dedicated capacity and fall back to shared capacity performance/limits.
• Break refresh SLAs or paginated workloads.
• Mis‑size Fabric capacity and overspend.
• Miss the chance to consolidate BI + data engineering into one Fabric plan.

Let’s structure the next 90 days so you avoid all of that.

0–90 Days Before Renewal: Understand What “Retirement” Actually Means

Microsoft’s current direction (as of late 2026):

• P SKUs (Power BI Premium per capacity) are being phased out in favour of Fabric capacity SKUs (F‑series).
• Existing Power BI workloads (reports, semantic models, dataflows, paginated) run on Fabric capacity with the Power BI workload enabled.
• The Power BI service isn’t going away. The underlying capacity offer is changing.

For your reports and models:

• Content in Premium workspaces remains compatible with Fabric capacity.
• You mainly need to ensure:
  • Workspaces are assigned to a capacity that will exist after renewal.
  • Capacity is sized correctly for your workload.
  • Any non‑Power BI Fabric workloads (Lakehouses, Warehouses, Notebooks) are accounted for.

So the question isn’t “Will my reports stop working?” but “On which capacity will they run, and at what cost and performance?”

90 Days Before: Inventory and Classify Your Workloads

First step: know what you’re actually running on the P capacity.

1. List All Premium Workspaces

Use the Power BI admin portal:

• Go to Admin portal → Capacity settings → Fabric capacities (or Power BI Premium if you still see the legacy view).
• For your P capacity, export the list of workspaces.

Classify each workspace:

• Critical production: SLAs, exec reporting, regulatory.
• Important but flexible: department dashboards, operational reports.
• Non‑critical / experimental: sandboxes, PoCs, personal workspaces.

2. Identify Workload Types

Per workspace, note:

• Semantic models:
  • Size (GB), refresh frequency, mode (Import, DirectQuery, Composite).
• Paginated reports:
  • Volume, typical runtime, data sources.
• Dataflows:
  • Gen1 vs Gen2, refresh schedules.
• Any Fabric items:
  • Lakehouses, Warehouses, Pipelines, Notebooks.

This classification drives both capacity sizing and migration risk.

3. Capture Current Capacity Utilisation

Use the Power BI Premium Capacity Metrics app (or the Fabric Capacity Metrics app if you already have Fabric capacities):

• Install or open the Power BI Premium Capacity Metrics app from AppSource.
• Focus on:
  • CPU utilisation patterns.
  • Memory pressure and eviction events.
  • Query wait times and refresh durations.

Export at least 30 days of data to see typical and peak usage.

This becomes your baseline when you discuss Fabric SKUs.

60 Days Before: Decide Your Post‑Premium Capacity Strategy

With inventory and metrics in hand, you can decide how to replace the P capacity.

1. Choose Between Fabric Capacity and Premium Per User (PPU)

You have two main options:

1. Fabric capacity (F SKUs)

   • Pros:
     • Dedicated capacity similar to P SKUs.
     • Supports Power BI + Fabric workloads (Lakehouse, Warehouse, Data Engineering, Data Science).
     • Good fit for teams already or soon using Fabric beyond Power BI.
   • Considerations:
     • You pay for capacity, not per user.
     • You must manage capacity health and workspace assignment.

2. Power BI Premium per user (PPU)

   • Pros:
     • Simple licensing: pay per user who needs Premium features.
     • No dedicated capacity management.
   • Limitations:
     • No dedicated capacity that you control; workloads run on Microsoft‑managed shared infrastructure.
     • Not a substitute if you rely on predictable performance for large models or heavy refresh.
     • Does not unlock Fabric capacity features (Lakehouse, Warehouse, etc.).

In our P3 scenario:

• Heavy production workloads + some Fabric experimentation → Fabric capacity is the realistic successor.

2. Map P Capacity to an F SKU

P and F SKUs aren’t identical, but you can use a practical mapping:

• Look at your P3 metrics:
  • If CPU rarely exceeds ~50–60% and memory pressure is low → you might be safe with an F64 or similar.
  • If you’re hitting high CPU and memory eviction during business hours → consider F128 or above.

Details like exact v‑core counts and pricing are documented in Microsoft’s SKU tables and may change, so treat the mapping as:

• Start from current utilisation, then choose an F SKU that comfortably covers peak use.
• Plan to monitor and adjust rather than guessing up front.

3. Decide Workspace Strategy

You don’t have to move everything to one Fabric capacity:

• Production capacity (e.g. F128):
  • Critical production workspaces.
• Dev/Test capacity (e.g. F32/F64):
  • Development, QA, experiment workspaces.
• Shared/PPU:
  • Personal and low‑criticality workspaces.

This split gives you cost control and performance isolation.

45 Days Before: Plan the Actual Transition

Once you’ve picked a target SKU and capacity layout, plan the move.

1. Create Fabric Capacity and Configure Workloads

In the Microsoft Fabric admin experience:

1. Purchase or provision the Fabric capacity (F SKU).
2. In Admin portal → Capacity settings → Fabric capacities:
   • Ensure the Power BI workload is enabled.
   • Optionally enable other workloads (Data Warehouse, Lakehouse, Data Engineering, etc.) if you plan to use them.

Key point: Power BI workloads must be enabled for existing reports and models to run on the new capacity.

2. Define a Workspace Migration Plan

For each workspace on the P capacity:

• Decide target capacity:
  • Production Fabric capacity.
  • Dev/Test Fabric capacity.
  • Shared/PPU.
• Decide migration window:
  • Preferably outside peak business hours.
• Decide validation steps:
  • Compare refresh duration before/after.
  • Check key report performance before/after.

3. Communicate Impact to Stakeholders

For critical stakeholders (finance, exec reporting):

• Explain:
  • Capacity is changing, not the Power BI product.
  • Their reports will continue to work, but performance may change slightly.
  • There will be a short migration window where refreshes may be delayed.

Set expectations now so you’re not firefighting on renewal day.

30 Days Before: Test Migration on a Non‑Critical Workspace

Before you move the core production workspace, do a dry run.

1. Pick a Representative Workspace

Choose a workspace that:

• Uses typical semantic models and refresh schedules.
• Has enough usage to show performance patterns.

2. Move Workspace to Fabric Capacity

From the workspace settings:

• Go to Workspace → Settings → Advanced → License mode / Capacity.
• Change assignment from the existing P capacity to your new Fabric capacity.

Confirm:

• The workspace shows the new capacity name.
• Power BI workload is active on that capacity.

3. Validate Behaviour

Over a few days:

• Monitor refresh duration and failures.
• Check report query performance.
• Use the Fabric Capacity Metrics app to see:
  • CPU utilisation for the new capacity.
  • Memory utilisation and any throttling.

If you see issues:

• Adjust refresh schedules (stagger heavy refreshes).
• Consider bumping the capacity SKU if you’re consistently saturating CPU.

This test reduces surprises when you move the main production workspace.

14 Days Before: Move Production Workspaces in Waves

With a successful test, move the critical workspaces.

1. Wave 1: High‑Impact but Low‑Risk

Start with:

• Operational dashboards with frequent refresh but moderate complexity.
• Finance reports that can tolerate a short maintenance window.

Steps:

1. Announce a migration window.
2. Move workspace to Fabric capacity.
3. Trigger a manual refresh.
4. Validate key reports with business users.

2. Wave 2: Paginated and Regulatory Reports

Paginated reports can be sensitive to performance and data source behaviour.

For each paginated workspace:

• Move to Fabric capacity.
• Run typical paginated reports (including longer ones).
• Verify:
  • Report completion times.
  • Data source connections (especially if they rely on gateways).

3. Wave 3: Remaining Workspaces and Cleanup

Finally:

• Move remaining Premium workspaces as planned.
• Reassign non‑critical workspaces to shared or PPU if appropriate.

Cleanup:

• Ensure no workspace remains assigned to the retiring P capacity.
• Document the new capacity structure and ownership.

Budget: How to Avoid Surprises

The retirement of Power BI Premium P SKUs usually triggers budget questions.

1. Compare Current Spend to Fabric Capacity Costs

Work with procurement and your Microsoft account team to:

• Get current P SKU spend (monthly or annual).
• Get pricing for candidate F SKUs.

Then:

• Align your utilisation data with SKU sizing.
• Avoid over‑buying “just in case” by planning to monitor and adjust.

2. Factor in New Workloads

Fabric capacity supports more than Power BI:

• Lakehouses and Warehouses.
• Data Engineering (Spark notebooks, pipelines).
• Real‑time analytics.

If your organisation plans to use these:

• Treat them as additional load on the same capacity.
• Consider a separate capacity for heavy data engineering if BI SLAs are strict.

3. Decide on a PPU Strategy for Edge Cases

Some users may need Premium features but not contribute much load:

• A few analysts who need larger datasets but don’t publish widely.
• External users who require access to specific Premium‑only content.

You can:

• Put their content on shared capacity.
• License them with PPU for Premium features.

This can be cheaper than sizing capacity purely for edge cases.

7 Days Before: Final Checks Before P Capacity Expires

With a week to go:

1. Confirm No Critical Workspace Is Still on P Capacity

In the admin portal:

• Verify that the retiring P capacity has zero workspaces assigned.

2. Validate Monitoring and Alerting

Ensure you have:

• Capacity metrics available in a monitoring workspace.
• Alerts (via Power BI or external tooling) for:
  • High CPU utilisation over sustained periods.
  • Frequent refresh failures.

3. Communicate the Change as Done

Let stakeholders know:

• Reports are now running on Fabric capacity.
• No further disruption is expected on the renewal date.

This reduces anxiety around the term “retirement”.

After Renewal: Use Fabric Features Intentionally

Once you’re off P SKUs and on Fabric capacity, you can start using Fabric more deliberately.

Practical next steps:

• Move heavy Power Query transformations from dataflows to Lakehouse + Warehouse + Data Engineering pipelines where they fit better.
• Use Direct Lake (where appropriate and supported) for large models to reduce refresh pressure.
• Consolidate data engineering workloads onto the same or a dedicated capacity, with clear ownership.

But keep one principle: BI reliability first. Don’t load the capacity with experimental Spark jobs that compromise your report SLAs.

One Concrete Takeaway

If your organisation is facing Power BI Premium being retired, treat the next 90 days as a capacity migration project, not a licensing panic: inventory workloads, choose an F SKU based on actual utilisation, move workspaces in controlled waves, and keep Power BI workloads enabled on Fabric capacity so your reports keep running while your budget and architecture evolve.