Power BI Premium P SKUs to Microsoft Fabric F SKUs
Cohash moves Power BI Premium P SKU capacities to Microsoft Fabric F SKUs. We baseline load with the Fabric Capacity Metrics app, pick the F SKU and region, buy it before anything moves, and reassign workspaces in batches with refreshes, gateways and reports checked after each one. The P SKU is cancelled only when every batch is validated, and cost alerts are in place before the first Azure invoice.
- 01Baseline and inventory
- 02SKU and region decision
- 03Provision
- 04Reassign in batches
- 05Stabilize and cancel
The story
Told without the client's name or anything that could identify them.
A retailer's analytics team ran its reporting on a Power BI Premium P SKU whose agreement was due to end, and Microsoft no longer sells new P SKUs. Most report readers used Free licenses, so a cheaper F SKU below F64 would have meant buying Pro licences for all of them. We started with a capacity baseline from the Fabric Capacity Metrics app and a count of Free-license viewers, which settled the size at F64 or larger in the same region. The F SKU was bought and set up with budgets and alerts before anything moved, workspaces were reassigned in checked batches, and the P SKU was cancelled once every batch passed.
why it was urgentMicrosoft has stopped selling Power BI Premium P SKUs and is retiring them. Each one ends with its agreement term, followed by a 30-day grace period. After that it gets rough. Interactive work is throttled from day 31, and from day 91 every operation is rejected until the workspaces sit on an F SKU. Enterprise Agreement customers can renew P SKUs until the EA term ends.
- openYour P SKU runs out inside twelve months and there's still no F SKU on order.
- recurringLots of report viewers are on Free licenses, and no one has worked out what a smaller F SKU would do to them.
- blockedSome workspaces hold large storage format models or Lakehouses, and someone has suggested changing region at the same time.
- openFinance wants Fabric spend to count toward the Azure commitment.
The estate, before and after
Before: reporting on a Power BI Premium P SKU
Workspaces ran on a per-capacity P SKU with Autoscale and an agreement about to end. Billing sat in Microsoft 365, and nobody had checked what a smaller F SKU would mean for Free-license viewers.
Read the diagram as text
- On-premises databases → On-premises data gateway: source data
- On-premises data gateway → Workspaces: refresh
- Workspaces → Power BI Premium P SKU: runs on
- Power BI Premium P SKU → Microsoft 365 billing: billed until cancelled
- Report authors → Workspaces: publish
- Free-license viewers → Workspaces: view reports
After: the same workspaces on a Fabric F SKU
Workspaces run on an F SKU bought through Azure, and budgets and alerts were in place before anything moved. Capacity Metrics feeds those alerts. When a peak comes, a named owner resizes the capacity.
Read the diagram as text
- On-premises databases → On-premises data gateway: source data
- On-premises data gateway → Workspaces: refresh
- Workspaces → Fabric F SKU: runs on
- Report authors → Workspaces: publish
- Free-license viewers → Workspaces: view reports
- Fabric F SKU → Azure subscription: billed in Azure
- Fabric F SKU → Fabric Capacity Metrics: CU telemetry
- Fabric Capacity Metrics → Azure subscription: resize on alert
How we run it, phase by phase.
5 phases take you from Power BI Premium P SKU capacity to Microsoft Fabric F SKU capacity. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Baseline and inventory
Run the Fabric Capacity Metrics app through a busy period to capture CU consumption. List workspaces by owner, and count Free-license viewers, gateways and large storage format models.
- phase 02
SKU and region decision
The default is a 1:1 move to the equivalent F SKU in the same region. Watch the F64 line, though. Free-license viewing needs F64 or larger, and below it every viewer needs Pro or PPU, so the choice changes licence cost as well as capacity.
- phase 03
Provision
Register the Microsoft.Fabric resource provider. Buy the F SKU, pay-as-you-go or reserved, and put Azure RBAC, tags, budgets and alerts on the capacity before you reassign anything.
- phase 04
Reassign in batches
Move workspaces in the Fabric admin portal or with the capacity migration notebook from semantic-link-labs. Check each batch for refreshes, gateway connections and report load before the next one goes.
- phase 05
Stabilize and cancel
Watch capacity use for one to two weeks and through a month-end close, reapply custom workload settings, and turn on surge and overage protection. Then cancel the P SKU in the Microsoft 365 admin center, because Fabric doesn't do it for you.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Reports run on an F SKU sized from measured load
Sizing used Fabric Capacity Metrics data plus the viewer licence count. Free-license viewers carried on reading reports without any new Pro licences.
- result 02
Capacity cost is set up in Azure before the first invoice
We set up RBAC, tags, budgets and cost alerts on the F SKU's Azure subscription, and only then reassigned the first workspace.
- result 03
Every workspace move has a validation record
We checked refreshes, gateway connections and report load after each batch. The results sit in a per-batch log, next to the reassignment scripts.
- result 04
Peaks have a named owner
F SKUs don't have Autoscale. Surge and overage protection is on, and a named owner resizes the capacity in the Azure portal when the alerts fire.
- result 05
The P SKU is cancelled, not left billing
We waited for a month-end close on the new capacity. Then the P SKU was cancelled in the Microsoft 365 admin center, using the cancellation checklist.
Risks we plan for
-
Undersizing below F64
A smaller F SKU looks cheaper until every Free-license viewer needs a Pro licence. Viewer counts go into the sizing decision from the start.
-
Cross-region surprises
Large storage format models need a backup and restore. Lakehouses, notebooks and other Fabric items make cross-region reassignment fail, and restored models come back with new IDs, so reports have to be rebound.
-
No more Autoscale
P SKU Autoscale doesn't exist on F SKUs. Peaks are handled by resizing in the Azure portal, so someone needs to own that and the alerts that trigger it.
-
Running both and paying twice
Pay-as-you-go F SKU rates usually run higher than the P SKU they replace, and the P SKU bills until someone cancels it. Put the reservation decision and a firm cancel date in the plan.
Where AI helps, and where it needs guardrails
Most of this move is licensing and capacity work, and AI adds little to it. On the target, Microsoft made Fabric IQ in Copilot Chat generally available in September 2026, with a data engineering agent in preview, and those workloads run on the new capacity. We script batch reassignment and validation in notebooks. Any agent that can resize or pause capacity must sit behind approval, since one wrong call stops every report.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- document01
Capacity baseline and F SKU sizing note, including viewer licence impact
yours to keep - plan02
Workspace batch plan with owners and validation checks
yours to keep - document03
Azure capacity setup with RBAC, tags, budgets and alerts
yours to keep - code04
Reassignment scripts and a per-batch validation log
yours to keep - report05
P SKU cancellation checklist and post-move cost review
yours to keep
Platforms and services on this move
Services involved
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01What happens if our P SKU ends before we move?
There's a 30-day grace period. Interactive operations are throttled from day 31, and from day 91 everything is rejected. Your data stays, but nobody can use it until workspaces move to an F SKU or the capacity is deleted.
02Do Pro or Premium Per User licences change?
No. Pro, PPU and embedded EM and A SKUs aren't part of this retirement. Only per-capacity P SKUs are.
03Will reports look or behave differently?
On F64 or larger in the same region, reports, semantic models and apps carry on as before. A refresh running during reassignment can be interrupted, so we time batches around the refresh windows.
04Should we also move to Direct Lake or OneLake?
Maybe later. Microsoft treats mirroring, shortcuts and Direct Lake as optional follow-ups. We keep them out of the licensing move so it stays short and low-risk.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case study
Apache Airflow 2 to Airflow 3
Upgrading self-managed Apache Airflow 2, now past end of life, to Airflow 3, and fixing removed features, auth and scheduling changes before DAGs move.
read the case studyc7c3de34 - 01Microsoft Learn: Power BI Premium to Microsoft Fabric migration overviewlearn.microsoft.com ↗
- 02Microsoft Learn: Power BI Premium P SKU migration decision guidelearn.microsoft.com ↗
- 03Microsoft Azure blog: FabCon and SQLCon 2026 in Barcelona (28 Sep 2026)azure.microsoft.com ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it