Power BI Premium P1 to Microsoft Fabric F64 Migration: Why Most Teams Are Over-Provisioned

Originally published at costfabric.com.

With Power BI Premium per-capacity (P1, P2, P3) retired in favor of Microsoft Fabric F-SKUs, every licensing table and migration slide deck shows the same one-to-one mapping: P1 (8 v-cores) equals F64 (64 Capacity Units).

Because F64 is also the threshold where free Power BI viewer access kicks in (so report viewers do not each need a paid Power BI Pro license), procurement and BI teams almost always default to migrating their old P1 straight into a 1-year reserved F64.

When you inspect the Fabric Capacity Metrics app a month after the migration, however, a huge percentage of those F64 tenants look the same: average CU utilization across the week sits between 14% and 28%, overnight utilization drops below 10%, and the only time the graph crosses 60% is during a poorly staggered 7:00 AM refresh wave.

Here is why the P1 to F64 rule of thumb causes so much overspending, and how to check what your workload actually uses before you renew.

Why an F64 behaves differently than an old P1

On legacy Power BI Premium P1, teams routinely sized for peak morning concurrency because CPU spikes from unoptimized DAX or overlapping dataset refreshes could degrade interactive report rendering right away.

Microsoft Fabric capacities (F2 through F128+) enforce compute governance differently:

1. 24-hour background smoothing: Scheduled semantic model refreshes, Dataflow Gen2 runs, and Spark jobs are smoothed across a full 24-hour window rather than creating a sharp instantaneous wall that blocks report viewers.
2. 5-minute interactive smoothing: Interactive DAX queries are smoothed across at least 5 minutes, absorbing brief executive dashboard bursts.
3. Flexible workspace-to-capacity assignment: Unlike a monolithic P1 where every workspace had to live on the same capacity, Azure lets you provision smaller Pay-As-You-Go or reserved F-SKUs (F8, F16, F32) and separate production BI from bursty development or ETL workloads.

The Pro-license math trap

The most common defense for keeping an under-utilized F64 (~$5,008/month on a 1-year reservation, or ~$8,410/month Pay-As-You-Go) is that dropping below F64 requires Power BI Pro licenses for report viewers.

Do the arithmetic on your actual viewer headcount before accepting that assumption:

• Dropping from a reserved F64 (~$5,008/month) to a reserved F32 (~$2,504/month) saves roughly $2,504 per month ($30,048 per year) in capacity spend.
• Even at ~$10 to $14 per user per month for Power BI Pro, $2,504 per month covers roughly 180 to 250 paid viewer seats.
• More importantly, in many Microsoft 365 Enterprise tenants, a large share of corporate users already hold Microsoft 365 E5 licenses, which include Power BI Pro at zero incremental cost.

If your organization either has fewer than 200 Pro-less viewers or already runs on E5, paying an extra $30,000 to $50,000 per year for an F64 that sits 75% empty is pure waste.

Where you actually have to be careful when right-sizing

Dropping from F64 to F32 or F16 is not just a matter of clicking "Scale" in the Azure portal on a Friday afternoon. While CU throughput scales linearly, per-artifact guardrails also step down with the SKU:

• Max semantic model memory: An F64 supports up to 25 GB per model in memory, whereas an F32 caps individual models at 10 GB and F16 caps them at 5 GB.
• Direct Lake framing and fallback guardrails: Max rows per table and max memory before a Direct Lake model falls back to DirectQuery decrease on smaller F-SKUs.
• Smoothed background floor: If a single workspace has 30 unoptimized Dataflow Gen2 refreshes running with default staging enabled, that background floor will consume twice the percentage of an F32 as it did on an F64.

Check your 14-day utilization profile first

Before you sign a 12-month reservation on an F64 (or before you scale down blindly and hit an out-of-memory error on Monday morning), measure three symptoms from your last 14 days of Capacity Metrics:

• What percentage of your 30-second windows sit below 15% CU?
• What is your steady-state 24-hour background smoothing floor?
• How many windows actually cross 50% or 100% CU, and which specific operations cause them?

You can run that symptom check offline in 5 minutes using the zero-macro Excel workbook at https://costfabric.com/tools/.

If the checker shows that more than half of your F64 spend is going to idle headroom, and you want to verify which target F-SKU and workspace layout your semantic models can safely step down to without hitting memory or throttling limits, request a free 48-hour capacity readout at https://costfabric.com/check/.