What Happens When Your Microsoft Fabric Trial Ends? Capacity SKUs, Pricing, and Moving to Production

If your Microsoft Fabric trial is winding down and you are not sure what comes next, you are in the right place. The trial is designed to be generous; Microsoft gives teams a meaningful runway to build proof-of-concept work, validate the platform, and generate internal buy-in. What it does not do is prepare teams for the purchasing decision that follows.

This post covers the questions we hear most often as a Microsoft CSP partner working with customers at exactly this moment: how Fabric capacity is priced, what the different SKUs actually mean, why F64 is a fundamentally different purchase than F32, and how to get from trial to production without landing in a billing situation that is difficult to reverse.

The Trial Does Not Convert

The most common misconception we encounter is that the trial can be upgraded or converted into a paid capacity. It cannot.

The Fabric trial gives each business user a trial capacity type, a temporary resource that exists outside any normal billing relationship. When the trial ends, it is gone. The paid capacity you move to must be provisioned as a new Azure resource, under a new billing relationship, from scratch.

Where you provision that new resource determines how you are billed, and that billing relationship is permanent. More on this shortly. First, it helps to understand what you are actually buying.

What Is Microsoft Fabric Capacity?

Microsoft Fabric is a unified analytics platform that brings data engineering, data warehousing, real-time intelligence, data science, and Power BI together under one roof. Rather than licensing individual services separately, Fabric uses a capacity-based model: you purchase a shared pool of compute power measured in Capacity Units (CUs), and every workload on the platform draws from that pool.

This represents a meaningful departure from how organizations have historically purchased analytics tools. Instead of paying per user for Power BI, per-hour for Azure Synapse, and separately for Data Factory pipelines, a single Fabric capacity meter covers all of it. That unified model is what makes Fabric pricing both simpler and, for many organizations, more cost-effective than the legacy alternative.

The Fabric SKU Lineup

Fabric capacities are sold in F-SKUs that double at each tier, from F2 at entry level up to F2048 for the largest enterprise deployments. Each SKU corresponds to a number of Capacity Units, and each SKU also includes a free Mirroring storage allocation equal to its CU count in terabytes.

Pricing scales linearly with CU count, approximately $0.18 per CU per hour in US regions. That puts F64 at roughly $11–$12 per hour at pay-as-you-go rates, or approximately $8,000–$9,000 per month if running continuously. Pricing varies by region; Microsoft's Fabric pricing page is the authoritative source for your specific geography and currency.

Two purchasing models are available:

• Pay-as-you-go: You pay only for the hours the capacity is actively running. Fabric capacity can be paused and resumed, which makes pay-as-you-go viable for teams with predictable off-hours or weekend inactivity, and a smart way to control costs on smaller development or testing environments.
• Reservations (1 or 3 year): Committing to a reservation can save approximately 41% compared to pay-as-you-go. A reserved F64 runs approximately $6,100 per month, versus $8,000–$9,000 on pay-as-you-go. Reservation charges run whether the capacity is paused or not, so this model fits consistent production workloads, not development environments or seasonal deployments.

The F64 Threshold: The SKU That Changes Your Cost Structure

The jump from F32 to F64 crosses a licensing boundary that changes the economics of the entire deployment, and it is the detail organizations consistently miss when they first evaluate Fabric.

With an F64 or larger capacity, the equivalent of a Power BI Premium P1, Power BI report consumers do not require a Power BI Pro license. Below F64, the Power BI Pro license requirement remains in effect.

Power BI Pro licenses run approximately $14 per user per month. For an organization with 200 report consumers, that is $2,800 per month in per-user licensing on top of whatever is being spent on data infrastructure. At 500 users it is $7,000 per month. At 1,000 users, $14,000 per month. Content creators still need Pro or Premium Per User licenses regardless of capacity size, but for organizations with a large base of report consumers, those per-user figures compound quickly against the cost of a smaller SKU.

F64 becomes the natural starting point for any conversation where an organization has enough report consumers that eliminating per-user Pro licensing makes the capacity cost attractive by comparison. The crossover point varies, but for teams above roughly 200–300 report consumers, the math often favors F64 before factoring in the additional compute and storage headroom.

It is also worth understanding what F64 represents in the context of legacy Power BI licensing. F64 is equivalent to the Power BI Premium P1 SKU that many enterprise organizations have historically paid for, but the Fabric F64 includes six additional workloads that Power BI Premium never provided: Data Engineering, Data Science, Data Warehouse, Real-Time Intelligence, Data Activator, and Databases. As we covered in our post on changes to Power BI Premium capacity licenses, organizations currently paying for any combination of Power BI Premium, Azure Synapse, and Data Factory often reduce total spend while significantly expanding capability when they consolidate onto Fabric.

What the Smaller SKUs Are Good For

The smaller SKUs serve real purposes and should not be dismissed as merely a stepping stone.

F2–F8 make sense for development and testing environments, isolated departmental workloads, or organizations exploring Fabric features before committing to production capacity. The pause-and-resume capability on pay-as-you-go makes these tiers highly cost-efficient for non-continuous use.

F16–F32 are viable for production deployments where the Power BI consumer count is small enough that per-user Pro licensing is still cheaper than crossing the F64 threshold, or where Fabric is being used primarily for non-Power BI workloads. For non-Power BI activities like data pipelines, data warehouses, and notebooks, no Power BI Pro license is required regardless of capacity size. If your Fabric use case is primarily engineering-focused rather than consumer-facing business intelligence, F32 may be the right starting point even at scale.

Before settling on F32, run this calculation: count your expected Power BI report consumers and multiply by $14 per month. If that number combined with your F32 costs approaches what F64 would cost, the decision is clearer than it first appears.

Moving from Trial to Production: Where Organizations Get Into Trouble

Once the right SKU is identified, the next critical decision is where to provision it. This is where the most consequential mistakes happen.

Azure subscription billing relationships are established at the time a resource is created and cannot be changed afterward. If someone provisions an F64 capacity directly through the Azure portal while logged into a Pay-As-You-Go account, it lands under direct Microsoft billing. It cannot be moved to CSP billing after the fact. Fixing it requires deleting the resource and reprovisioning it under the correct subscription, which means migrating all workspaces again.

This happens more often than it should. A motivated data engineer, trying to keep trial workloads alive before procurement has signed off, provisions the capacity without realizing the billing consequence.

For customers working with CloudServus as their CSP partner, the production capacity is provisioned under the customer's CSP-billed Azure subscription from day one. That subscription sits under the Azure Plan in Partner Center, where we manage the billing relationship on the customer's behalf. Getting this right at provisioning time is one of the concrete ways a CSP partner earns its place in the conversation.

Once the production capacity exists in the right subscription, migrating workspaces from the trial is low-risk and non-destructive. It happens through the Fabric Admin portal; workspaces are reassigned one at a time, data and content stay intact throughout, and the trial and production capacities can coexist while the migration is validated before the trial is decommissioned.

Where a Fabric Partner Adds Ongoing Value

Getting from trial to production cleanly is the starting line, not the finish line. Organizations that get the most out of Microsoft Fabric do not just provision a capacity and point workspaces at it; they make architecture decisions early that compound in value over time.

The CloudServus Data & AI practice works with customers across the full Fabric lifecycle: from initial capacity sizing and CSP provisioning through lakehouse architecture, medallion layer design, semantic model governance, and AI/ML integration using Fabric's native data science workloads. Common inflection points where customers engage after the trial phase include:

• Capacity right-sizing and reservation strategy. Is pay-as-you-go with pause schedules more cost-efficient than a reservation for your usage pattern? We model this before the purchase, not after.
• OneLake architecture. How workspaces, lakehouses, and domains are structured early in a Fabric deployment determines how manageable the platform is at scale. Getting the architecture right in the first 90 days is significantly easier than refactoring it later.
• Power BI semantic model governance. F64 eliminates the per-consumer Pro license requirement, but it does not automatically govern who builds what or how. Dataset certification, sensitivity labels, and lineage tracking are the unglamorous work that separates well-run Fabric deployments from ones that accumulate technical debt.
• AI and Fabric. Microsoft's data science workloads in Fabric, including notebooks, ML model deployment, and integration with Azure AI services, are maturing quickly. Organizations that start building AI capabilities into their Fabric environment now are building on infrastructure that is designed for it, rather than adding AI onto a separate stack later.

If your team is wrapping up a Fabric trial and working through what production looks like, whether that is the right SKU, the billing relationship, the architecture, or where to invest first, that is exactly the conversation the CloudServus team is built for. Talk to one of our consultants and we will help you build a plan that makes sense for where your organization is today and where it is headed.