Somewhere in the last few months, a Power BI Premium renewal notice landed on a procurement desk with a number that didn’t match last year’s invoice, and nobody could immediately explain why. That scene is playing out across a lot of finance and IT organizations right now, because Power BI Premium’s per-capacity SKUs (the familiar P1 through P5 tiers) are being phased out in favor of Microsoft Fabric capacity, and a Fabric capacity migration for many enterprises is landing at the exact moment their Enterprise Agreement comes up for renewal. Non-EA customers lost the ability to renew Premium capacity back in January 2025. EA holders have had more breathing room, but only until their current agreement term ends, and a wave of three-year EAs signed in 2023 are hitting that wall throughout 2026.
The mechanics of the transition get covered reasonably well in Microsoft’s own migration documentation: reassign workspaces to a Fabric F-SKU, validate refreshes and gateways, decommission the old capacity. What gets far less attention, and what has already caught more than one IT Director off guard mid-negotiation, is a licensing detail buried a few layers into the SKU comparison: not every Fabric capacity size preserves the free-viewer access that Power BI Premium customers have taken for granted for years.
Why F64 Is the Number That Actually Matters
Under Power BI Premium, any user with the Free license could view content in a workspace backed by Premium capacity, so long as they had a Viewer role. That was one of Premium’s core value propositions for large organizations: a single capacity purchase covered report consumption for hundreds or thousands of employees without individual Pro licenses.
Fabric capacity does not carry that benefit uniformly across its SKU range. Free-user viewing only returns at F64 and above. Anything from F2 through F32, the sizes that map to smaller or mid-sized Premium deployments on paper, requires every single viewer to hold a Power BI Pro or Premium Per User license. For an organization whose consumption metrics suggest a P1-equivalent capacity would be plenty, the naive read-across is F64 anyway (Microsoft’s own sizing guidance maps P1 to F64), so this often isn’t a problem for P1 customers specifically. The real exposure shows up for organizations that assumed they could right-size downward, based on actual utilization data, into an F32 or smaller footprint to save on the recurring Fabric bill, only to discover that doing so would require issuing several hundred new Pro licenses to preserve the same viewer population that costs nothing today.
That’s not a hypothetical. It’s the kind of number that shows up in a board deck as a line item nobody budgeted for, and it’s precisely the sort of decision that needs to be modeled before a renewal date forces a choice, not after.
The Real Timeline Pressure
Microsoft’s transition isn’t open-ended once a Premium term lapses. There’s a 30-day grace period after a P-SKU subscription ends, during which capacity keeps functioning while a migration gets finalized. After day 30, access starts getting throttled, meaning interactive operations slow down or get delayed. Past day 90, every operation against that capacity gets rejected outright. The underlying data isn’t deleted, but it becomes fully inaccessible until either the migration completes or the capacity is retired for good.
For a CIO or IT Director, the practical implication is that “we’ll deal with the Fabric migration next quarter” is not a safe posture once an EA renewal date is visible on the calendar. The sequencing matters too: the recommended path is to provision the new F-SKU capacity, reassign workspaces to it, validate that refreshes and reports behave correctly, and only then cancel the old Premium subscription, because that cancellation doesn’t happen automatically and the two capacities can run in parallel briefly during validation. Treating this as a same-week swap invites exactly the kind of outage that turns a licensing decision into an incident review.
Sizing the Fabric Capacity Migration Instead of Guessing at It
The good news is that Microsoft doesn’t leave the sizing decision to intuition. The Fabric Capacity Metrics app, which connects to a tenant’s actual consumption history, is the mechanism most consulting teams now use to baseline 30 to 45 days of real Premium usage before committing to an F-SKU size. Organizations with sustained utilization near the ceiling of their current capacity generally need an equivalent or larger Fabric SKU to avoid throttling. Organizations with long stretches of low activity, evenings, weekends, month-end lulls followed by spikes, are often better served by a smaller capacity paired with Fabric’s pause and resume functionality, something Premium never offered. Pausing a capacity during genuinely idle hours stops billing entirely, which is a real lever for reducing the annual spend rather than just shifting it from a Microsoft 365 line item to an Azure one.
That said, the free-viewer threshold at F64 has to be weighed against pure utilization math. A tenant whose usage data suggests F32 is technically sufficient may still come out ahead financially by sizing up to F64 and avoiding a mass Pro license rollout, and that comparison is specific enough to the organization’s own viewer count and existing Pro license penetration that it needs to be run as an actual cost model, not assumed either way.
What Else Changes Beyond the Bill
A few other differences are worth putting in front of a decision-maker evaluating this migration, because they shape both cost and risk. Fabric capacity is billed through Azure, on a pay-as-you-go or reserved basis, rather than through the Microsoft 365 commitment model Premium customers are used to, which means the invoice shows up in a different place and often gets reviewed by a different team. Capacity-level settings, things like semantic model memory limits or custom workload configurations, don’t carry over automatically during migration and need to be recreated on the new capacity, so a lift-and-shift assumption can leave gaps in governance that only surface later. And for organizations considering a cross-region move as part of the migration, perhaps to consolidate capacity somewhere with better Azure pricing, large-format semantic models and other Fabric items generally don’t survive that move intact; they need to be backed up and recreated, which introduces real downtime that a same-region migration wouldn’t require. For most organizations, the operational cost of that rebuild outweighs whatever regional pricing delta prompted the idea in the first place.
Getting Ahead of the Renewal Date
None of this argues against moving to Fabric capacity. The pause and resume billing, the built-in Power BI Embedded rights, the tighter Azure governance integration through managed private endpoints and RBAC, these are genuine improvements over what Premium offered, and the migration itself is generally low-risk when it stays within the same tenant and region. The argument is against treating this as a routine renewal to be handled by whoever owns the Microsoft relationship without IT and finance jointly reviewing the sizing math first.
The organizations getting this right are starting the Capacity Metrics baseline well before their EA renewal conversation, running the free-viewer cost comparison as an actual spreadsheet rather than an assumption, and building the migration into a maintenance window rather than a renewal-week scramble. We’ve walked several clients at Routeget Technologies through exactly this exercise this year, and the pattern holds: the technical migration is rarely the hard part. The licensing model change underneath it is what catches finance teams by surprise, and it’s avoidable with about a month of preparation.
If your Power BI Premium renewal or EA term ends anytime in the next twelve months, that preparation should be starting now, not when the notice arrives.
#PowerBI #MicrosoftFabric #FabricCapacityMigration #ITBudgetPlanning #DataAnalyticsStrategy #CloudCostManagement
No comment yet, add your voice below!