How do Power BI Premium P-SKUs map to Fabric F-SKUs?

The official 2026 mapping: P1 (8 v-cores) → F64 (64 CUs); P2 (16 v-cores) → F128 (128 CUs); P3 (32 v-cores) → F256 (256 CUs); A4 Embedded (8 v-cores) → F64 (64 CUs); EM3 (4 v-cores) → F32 (32 CUs). Each P-SKU maps 1:1 by v-core count. The critical difference: F64+ is now required for free Power BI Pro viewer inclusion — sub-F64 SKUs (F2 through F32) require per-user Pro seats.

Will Fabric F64 be cheaper than Power BI Premium P1?

For typical P1 tenants migrating to F64, capacity monthly cost is essentially flat ($4,995 EA P1 vs $5,003 for F64 1-year reserved). Net savings come from consolidating separate Synapse/ADF/Databricks workloads onto the same F64 capacity — typically $1,500-$8,000/month savings. Copilot and Real-Time Intelligence are included as net-new value. Exceptions where you pay more: sub-P1 tenants (EM3, A4) losing free Pro viewer inclusion, and tenants heavily using Autoscale which bills separately.

How long does P1 to F64 migration take?

Enterprise P-SKU to F-SKU migration typically takes 12 weeks: Weeks 1-2 assessment (inventory, capacity mapping, cost modeling); Weeks 3-4 Fabric prerequisites (tenant settings, capacity provisioning, Purview integration); Weeks 5-6 parallel run on pilot workspace; Weeks 7-9 cutover wave 1 (30% of workspaces, non-critical); Weeks 10-11 cutover wave 2 (40% of workspaces); Week 12 final cutover of business-critical workspaces plus legacy capacity retirement. Data does not move — capacity reassignment is a metadata change.

Do I need to migrate from Power BI Premium P-SKU to Fabric?

Yes — Microsoft is deprecating the legacy P-SKU model. Every enterprise on P1, P2, or P3 needs a migration plan before their annual EA true-up date. Fabric F-SKU includes everything P-SKU included (Power BI Pro viewer seats at F64+, workspace capabilities, RLS, deployment pipelines) plus new workloads (Data Engineering, Data Factory, Data Warehouse, Real-Time Intelligence, Data Science, Copilot). Continuing on P-SKU past its retirement date is not supported.

Can I rollback a Fabric F-SKU migration?

Yes — Fabric supports capacity reassignment back to legacy P-SKU capacity until P-SKU end-of-life. If a wave of migrated workspaces exhibits unacceptable behavior, reassign affected workspaces back to the original P-SKU capacity, investigate root cause, and re-migrate after fix. Data is not moved during capacity reassignment — it is a metadata change, so rollback is fast and low-risk. Plan rollback windows into every migration wave; do not decommission legacy P-SKU capacity until 7+ days of clean operation on F-SKU.

How is a Power BI engagement priced for enterprise workloads?

Pricing is modeled against three variables: the complexity of the semantic layer, the volume and velocity of source data, and the governance footprint required after go-live. A scoped implementation typically runs as a fixed-fee discovery sprint followed by a time-and-materials build, because dataset refresh patterns and row-level security rules almost always evolve once real user personas review early drafts. Licensing is separated from consulting fees and mapped against Power BI Pro, Premium Per User, and Fabric capacity SKUs so finance teams can plan capacity uplift independently of delivery cost. A typical mid-market rollout lands between 120 and 480 consulting hours across data modeling, DAX optimization, report design, and deployment pipelines. Fabric workloads add capacity sizing sessions to avoid over-provisioning F-SKUs on day one.

How long does a production-ready Power BI rollout take?

A single subject-area workspace with a conformed star schema, deployment pipeline, and row-level security ships in roughly six to eight weeks once source access is granted. Multi-domain rollouts that span finance, operations, and customer analytics typically run three to five months because the semantic model has to reconcile calendar, product, and organizational hierarchies that rarely align across source systems. Fabric lakehouse projects add four to six weeks for medallion design, Direct Lake tuning, and OneLake shortcut setup. Timelines compress when an authoritative data dictionary already exists and lengthen when stakeholders are discovering definitions (for example, what counts as "active customer") for the first time. Governance, training, and center-of-excellence enablement are run in parallel rather than sequentially.

What delivery methodology do you use for Power BI and Fabric projects?

Delivery runs on a five-stage pattern: Discover, Model, Visualize, Operationalize, and Enable. Discover captures questions stakeholders actually want answered, not just source tables. Model builds a Kimball-style star schema (or a medallion lakehouse in Fabric) with conformed dimensions and documented grains. Visualize produces reports against a shared theme file, applies accessibility tokens, and uses bookmarks and field parameters instead of bespoke page duplication. Operationalize wires up deployment pipelines, dataset refresh monitoring, and Azure DevOps or GitHub source control via TMDL. Enable delivers hands-on training for citizen developers and a lightweight center-of-excellence charter. Each stage ends with a demo and a written acceptance checklist, so scope creep is visible before it becomes rework.

How do you secure sensitive data inside Power BI reports?

Security is layered rather than relying on a single control. Row-level security and object-level security are enforced inside the semantic model using DAX filter expressions driven by Entra ID group membership, so filters survive refresh and cannot be bypassed by report-level tricks. Sensitivity labels from Microsoft Purview are applied at dataset and report scope and follow exports into Excel and PDF. Workspace roles follow a least-privilege pattern (Admin, Member, Contributor, Viewer) and are granted to Entra ID groups, never individuals. Private endpoints and VNet data gateways keep on-premises sources off the public internet, and tenant-level settings restrict publish-to-web, external sharing, and guest access. Every production dataset is audited quarterly against a written RLS test plan.

Can existing Excel and Tableau reports be migrated into Power BI?

Yes, but a migration is an opportunity to redesign rather than a literal port. Excel financial models usually translate cleanly into a semantic model: named ranges become dimensions, pivot tables become matrix visuals, and SUMIFS chains become well-formed DAX measures with variables. Tableau workbooks require more interpretation because Tableau extracts and Power BI datasets have different refresh and relationship semantics; calculated fields are rewritten as DAX, LOD expressions become CALCULATE patterns, and dashboard actions are rebuilt using bookmarks and drillthrough. A discovery audit catalogs every report, ranks them by business value, and retires the long tail of duplicates before migration starts. This typically reduces the report estate by 30–50 percent.

How do you optimize DAX performance on large semantic models?

DAX performance starts with the model, not the measure. Star schemas with integer surrogate keys, single-direction relationships, and calculated columns materialized in Power Query outperform ambiguous snowflakes every time. Measures are written using variables (VAR/RETURN) to avoid repeated context transitions, and expensive patterns like FILTER over entire tables are replaced with KEEPFILTERS and Boolean filter arguments. Aggregation tables and composite models offload detail-level queries from imported caches to Direct Lake or DirectQuery sources. Every measure that appears in a production report is profiled with DAX Studio and VertiPaq Analyzer; queries above a 2-second threshold on representative hardware are rewritten before release. Fabric capacity metrics are reviewed weekly to catch runaway refreshes and interactive CPU spikes.

Do you support Microsoft Fabric, OneLake, and Direct Lake workloads?

Fabric is now the default landing zone for new analytics workloads unless a client has a specific reason to stay on legacy Power BI Premium capacity. Engagements cover medallion architecture design in lakehouses, data engineering pipelines built in Fabric notebooks or Dataflows Gen2, shortcut-based integration with Azure Data Lake Storage and Amazon S3 through OneLake, and Direct Lake semantic models that skip import refresh entirely. Capacity sizing is based on measured workload patterns rather than vendor rules of thumb, and F-SKU scaling is automated through Azure Logic Apps or the Fabric REST API so off-hours costs stay predictable. Copilot in Fabric is configured with tenant-level data boundaries and audit logging before it is enabled for end users.

What training and enablement do end users receive after go-live?

Training is tiered by persona. Report consumers get a 45-minute guided tour covering filters, bookmarks, subscriptions, and mobile access. Analysts get a three-session workshop on self-service semantic model extensions, composite models, and publishing to workspaces that follow the governance pattern. Data modelers receive a two-day immersion on star schema design, DAX fundamentals, and deployment pipeline usage. Every session is recorded, indexed, and paired with a sandbox workspace seeded with representative sample data. A written center-of-excellence charter defines who owns certified datasets, who can promote a report to production, and how to request enhancements. Office hours run for 30 days post-launch so questions do not pile up into a formal change request.

How are Power BI deployments managed across dev, test, and production?

Every production workspace is paired with matching development and test workspaces wired through Power BI deployment pipelines. Datasets are source-controlled as TMDL files in Azure DevOps or GitHub so pull requests can be reviewed by a second modeler before merge. Environment-specific parameters (connection strings, sensitivity label rules, capacity assignments) are swapped at deployment time using parameter rules rather than manual edits. Fabric deployment pipelines handle lakehouses, notebooks, and data pipelines with the same promotion pattern. Refresh schedules, gateway assignments, and alerting are applied through the Power BI REST API so they survive redeployment. A written change-management checklist covers dataset certification, dependency impact analysis, and rollback procedure for every promotion to production.

Which industries and data sources do you support most often?

Heaviest experience sits in healthcare, financial services, energy, manufacturing, and public sector, because each of those verticals pushes a different dimension of Power BI: HIPAA-bound PHI handling, transaction-grain reconciliation, time-series sensor data, cost-center-driven manufacturing variance, and FedRAMP-aligned government reporting. Source systems frequently include Microsoft Dynamics 365, SAP ECC and S/4HANA, Salesforce, Workday, Epic and Cerner (Oracle Health), Infor, and a long tail of legacy ODBC databases connected through on-premises data gateways. Fabric engagements add Azure Data Lake Storage, Snowflake, Databricks, BigQuery, and Amazon S3 through OneLake shortcuts. Regardless of source, the modeling discipline is identical: conformed dimensions, documented grains, and a semantic layer that hides the join complexity from report authors.

Power BI Premium P1/P2/P3 to Fabric F-SKU Migration

Q: What is the biggest risk in P-SKU to F-SKU migration?

Under-sizing the target F-SKU is the biggest risk. Migrating P1 to F64 sounds equivalent, but Fabric workloads (Copilot, Data Factory, Real-Time Intelligence) that were separate on Synapse now compete for the same CU pool. Baseline your P1 CU% first: if you were running at 60%+ under Power BI alone, size up to F128. Second-biggest risk: reserved capacity commitment lock-in on 3-year terms before you have measured actual Fabric usage patterns. Start with 1-year reserved and adjust after 3-6 months.

Microsoft is deprecating the legacy Power BI Premium P-SKU capacity model and consolidating everything onto Fabric F-SKUs. Every enterprise on P1, P2, or P3 needs a migration plan before their annual EA true-up date. The Fabric F-SKU is not a drop-in replacement — it has different billing math, different features included, different failure modes, and different capacity management. This runbook covers the P-to-F mapping, the billing math (including where you save and where you pay more), the cutover playbook by phase, and the 12 pitfalls that most enterprises hit mid-migration.

P-SKU to F-SKU Mapping

Microsoft's official capacity mapping (2026):

Legacy P-SKU	v-cores	Replacement F-SKU	Fabric CUs	Notes
P1	8	F64	64	Direct replacement. Same viewer license included.
P2	16	F128	128	Direct replacement.
P3	32	F256	256	Direct replacement.
A4 (Embedded)	8	F64	64	Embedded gets same capacity, add F16 workload isolation.
EM3	4	F32	32	Sub-P1 tier; no free viewer inclusion.

Every P-SKU maps 1:1 by v-core count. The critical difference is that F64+ is now required for free Power BI Pro viewer inclusion — sub-F64 SKUs (F2 through F32) require per-user Pro seats.

Billing Math: Where You Save (or Pay More)

Direct comparison for a large tenant migrating P1 → F64 with 2,000 named users:

Cost bucket	Legacy P1 model	Fabric F64 model	Delta
Capacity monthly	$4,995 (P1 with EA)	$5,003 (F64 1-yr reserved)	+$8/mo
Pro seats for viewers	Included	Included (F64+)	$0
Data engineering workloads	Separate Azure Synapse/ADF	Included in F64	-$1,500-$8,000/mo
Copilot	Not available	Included, uses CU pool	Net-new value
Real-Time Intelligence	Not available	Included, uses CU pool	Net-new value

Net for typical P1 tenant: save $1,500-$8,000/month by consolidating Synapse/ADF workloads onto the same F64 capacity that already delivers Power BI. This is the primary business case for the migration.

Exceptions where you pay more:

Sub-P1 tenants (EM3, A4) migrating to F32 lose free Pro viewer inclusion. Add ~$14/user/month for viewers.
Multi-region tenants with capacity in each region — F-SKU has region-specific reserved capacity pricing; verify against P-SKU regional pricing.
Tenants heavily using Autoscale — Fabric Autoscale bills separately per burst CU-hour; heavy autoscale usage can offset the base savings.

The 12-Week Migration Runbook

Weeks 1-2: Assessment

Inventory all P-SKU capacities in your tenant (Fabric Admin → Capacities)
Export usage from Capacity Metrics App — identify peak CU%, throttling events, top consumers
Map every P-SKU to target F-SKU using the mapping table above
Identify Autoscale patterns (frequency, magnitude) — model against Fabric Autoscale pricing
Calculate 12-month reserved capacity commitment vs pay-as-you-go break-even

Weeks 3-4: Fabric Prerequisites

Enable Fabric tenant setting: `Microsoft Fabric` at tenant level
Provision target F-SKU capacity in same region as legacy P-SKU
Verify Entra ID admin roles map cleanly (Fabric Admin vs legacy Power BI Admin)
Provision Fabric Domains for federated ownership (Build 2026 recommended pattern)
Set up Purview integration for lineage tracking

Weeks 5-6: Parallel Run

Migrate one non-critical workspace to F64 as pilot
Copy 2-3 semantic models via workspace clone
Validate query performance parity (see Direct Lake+ benchmark guide for methodology)
Validate RLS enforcement identical
Validate scheduled refresh reliability over 7 days

Weeks 7-9: Cutover Wave 1

Migrate first 30% of workspaces (typically dev and non-critical prod)
Use Fabric workspace assignment change (no data movement required — Power BI semantic models auto-adopt new capacity)
For semantic models on Direct Lake+, verify OneLake shortcuts remain valid
Retire the F-SKU-attached legacy P-SKU capacity only after 7 days of clean operation

Weeks 10-11: Cutover Wave 2

Migrate second 40% of workspaces
Monitor CU% against baseline — flag any workload that exceeds 80% of new F-SKU CU allocation
Right-size mid-migration if needed (upgrade F64 → F128 is instantaneous)

Week 12: Final Cutover + Retirement

Migrate final 30% of workspaces (business-critical, executive-visible)
Retire remaining legacy P-SKU capacity
Publish final migration report: CU utilization, cost delta, feature gains

The 12 Migration Pitfalls (In Order of Frequency)

1. Under-sized F-SKU

Migrating P1 to F64 sounds equivalent — but Fabric workloads (Copilot, Data Factory, Real-Time Intelligence) that were separate on Synapse now compete for the same CU pool. Baseline your P1 CU% first; if you were running at 60%+ under Power BI alone, size up to F128.

2. Reserved capacity commitment lock-in

Fabric reserved capacity is billed in 1-year and 3-year terms. Committing to 3-year F256 before validating actual usage patterns has caused enterprises to overpay $80,000-$200,000/year. Start with 1-year reserved on the F-SKU you actually need; upgrade after 3-6 months of measured data.

3. Sub-F64 EM3/A4 downgrade

Tenants on EM3 or A4 who "downsize" to sub-F64 lose free Pro viewer inclusion. This is a real cost increase, not a migration savings. Path: bundle small tenants into a shared F64 capacity via workspace consolidation.

4. Direct Lake semantic models tied to legacy P-SKU-owned Lakehouses

Direct Lake semantic models are tied to specific OneLake locations. If you have a Lakehouse in the P-SKU capacity, migrate the Lakehouse first and update Direct Lake shortcuts before migrating the semantic model.

5. RLS role assignments referencing deleted legacy admin groups

Migrating tenant admin groups mid-migration can break RLS role assignments. Audit RLS assignments against Entra ID group membership before migration.

6. Autoscale pricing surprises

Fabric Autoscale bills per burst CU-hour separately from base capacity. Tenants with heavy P1 Autoscale patterns migrating to F64 often see Autoscale bills exceed base capacity. Set explicit Autoscale caps in Fabric.

7. Deployment pipelines pointing at old capacity

Existing Power BI deployment pipelines have hardcoded capacity assignments. Update pipeline definitions before promoting content post-migration.

8. Certified semantic model endorsement resets

Semantic model endorsements (Certified, Promoted) persist across migration, but the certifying user must retain access. Audit certifying user list before migration.

9. External tenant sharing configurations

External tenant sharing settings live on the tenant not the capacity, so they persist. BUT Fabric adds new external sharing controls (Data Domain sharing, cross-tenant OneLake shortcuts) that must be reviewed against your data governance policy before enabling.

10. Report subscriptions with hardcoded workspace paths

Report email subscriptions retain their workspace path even after capacity change. Test 5-10 sample subscriptions post-migration to confirm delivery.

11. Third-party ISV connectors on legacy P-SKU

Some third-party ISV connectors (Bring Your Own Key, custom auth providers, legacy Analysis Services connectors) have not been recertified for Fabric F-SKU. Audit ISV connectors before migration.

12. Multi-geo tenant data residency

Fabric F-SKU has different multi-geo semantics than legacy P-SKU. If your P-SKU had specific data residency in multiple regions, verify Fabric F-SKU multi-geo configuration explicitly — do not assume the migration preserves it.

Rollback Plan

If a wave of migrated workspaces exhibits unacceptable behavior, Fabric supports capacity reassignment back to legacy P-SKU (until P-SKU end-of-life). Rollback path: reassign affected workspaces back to the original P-SKU capacity, investigate root cause, re-migrate after fix. Data is not moved during capacity reassignment — rollback is a metadata change.

Related Guides

Ready to plan your P-SKU to F-SKU migration? Book a 30-minute migration assessment and we will map your capacity, workloads, and 12-week runbook to your annual EA date.