What the Power BI to Microsoft Fabric Migration Actually Means for Manufacturing IT
If your organisation runs Power BI Premium and your Microsoft Enterprise Agreement is approaching renewal, you will have a migration conversation with Microsoft whether you initiate it or not. Power BI Premium P SKUs are being retired. The replacement is Microsoft Fabric F SKUs, purchased through Azure. For Premium customers at EA renewal, the capacity migration is mandatory.
What migration guides tend to skip is the decision that sits alongside the mandatory piece.
The licensing migration is not a rebuild. Power BI reports, dashboards, DAX measures, and semantic models carry forward unchanged. The workspace reassignment is largely administrative, and Microsoft provides automation tooling to run it at scale. What changes is the underlying capacity infrastructure, how it is procured (Azure consumption billing rather than Microsoft 365 licensing), and what platform capabilities become available once the new capacity is in place.
For a manufacturing IT lead, that last point is where the real work is. In engagements with manufacturers preparing for EA renewals, the workspace reassignment typically takes a day. The decisions that take weeks involve whether to extend into Fabric’s broader capabilities at the same time: OneLake for historian and MES data, Direct Lake mode for large sensor datasets, and real-time intelligence workloads for OT data streams.
This guide covers both.
Should You Migrate Now? A Decision Framework for Manufacturing IT Leads
The mandatory question is when the migration needs to happen. The more important question for manufacturing IT is what scope it should cover.
Power BI Premium customers on the renewal cycle must reassign workspaces to Fabric capacity. That part is settled. What is a decision is whether to extend into Fabric workloads beyond Power BI at the same time, or treat the initial migration as a like-for-like capacity swap and plan the platform expansion separately.
Four signals indicate it is time to do both at once:
1. Your MES, ERP, and historian data live in separate tools with no common data layer. If your data team spends meaningful time reconciling production data before it reaches Power BI, a Fabric Lakehouse and unified pipeline architecture addresses that at the source rather than at the reporting layer.
2. Historian or real-time OT data is straining Power BI Import mode. If refresh schedules run every 30 minutes and reports are still lagging behind plant activity, Direct Lake mode and Fabric’s KQL real-time intelligence layer are the correct fix, not a faster refresh cadence.
3. You run multiple plants across Azure regions and have no unified governance model. Fabric’s workspace architecture and OneLake provide the cross-site governance structure multi-plant operations need.
4. Your EA renewal is within 6 months. Leaving the platform assessment until after renewal means starting the Fabric workload evaluation without the benefit of early reserved capacity pricing negotiations.
If none of these apply, migrating the capacity at renewal and evaluating Fabric workloads in the following 12 months is a reasonable approach.
| Dimension | Migrate capacity only | Migrate and expand to Fabric workloads |
|---|---|---|
| Data sources | Single or few, cloud-connected | Multi-source: MES, ERP, historian, LIMS |
| Team structure | BI analysts only | Cross-functional: BI, data engineering, IT |
| Governance needs | Workspace-level RLS | Multi-plant lineage, unified data layer |
| Renewal timeline | More than 12 months out | Within 6 months |
The Licensing Math: P SKU to F SKU for Manufacturing Organisations
The SKU transition is straightforward once you have the equivalency table. The hidden costs are where manufacturing organisations tend to be caught off guard.
SKU equivalency
| Power BI Premium P SKU | Equivalent Fabric F SKU |
|---|---|
| P1 | F64 |
| P2 | F128 |
| P3 | F256 |
F64 is the minimum SKU that enables Copilot and allows free-licence users to consume reports without a Power BI Pro licence. Below F64, report consumers still require Pro licences, which affects the per-user cost calculation for larger plant populations.
Pricing model
Fabric F SKUs are purchased through Azure rather than through Microsoft 365, which moves the procurement conversation from the software agreement into Azure consumption budgeting. Reserved capacity (1-year or 3-year annual commitment) saves up to 40.5% compared to pay-as-you-go, according to Microsoft’s published Fabric pricing documentation. For manufacturers with consistent, predictable Power BI usage, reserved capacity is the standard recommendation.
Two hidden costs specific to manufacturing
First: on-premises Power BI Report Server. Manufacturers running Power BI Report Server for shop floor reporting lose the dual-use rights that covered it under P SKUs. Under F SKUs, on-premises reporting requires separate SQL Server Enterprise per-core licensing with Software Assurance. If this applies to your environment, it needs to be in the cost model before the EA renewal conversation, not discovered afterwards.
Second: multi-region capacity. Fabric capacities are purchased per Azure region. Manufacturers with plants in the EU, US, and APAC may need separate Fabric capacities in each region to meet data residency and latency requirements, which increases total capacity spend compared to a single global Premium capacity.
One offset worth flagging: if your organisation has a Microsoft Azure Consumption Commitment (MACC) agreement, Fabric capacity spend counts toward that commitment. For manufacturers already running significant Azure infrastructure for IoT or ERP integration, this can reduce the net licensing cost meaningfully.
What Microsoft Fabric Unlocks for Manufacturing Analytics
Migrating to Fabric capacity does not automatically activate any of the following. These capabilities become available once the capacity is in place, and each one requires a deliberate decision to implement. What they address are specific problems manufacturing data teams encounter with standalone Power BI.
OneLake as a unified data destination
In a typical manufacturing environment, Power BI connects directly to MES, ERP, and historian systems via an on-premises data gateway, one connection per source, one gateway load per query. OneLake changes this structure: data from historian systems, MES platforms, and ERP is extracted once into a unified storage layer, and Power BI connects to the governed layer on top. Cross-system joins become clean, gateway load drops, and data engineering and BI teams work from the same source rather than separate extracts.
Direct Lake mode for large industrial datasets
Historian data from systems like AVEVA PI or Wonderware accumulates years of high-frequency sensor readings. In Import mode, refreshing that volume is slow and often incomplete within a scheduled refresh window. Direct Lake mode queries the Delta Lake tables in OneLake directly, without a scheduled refresh cycle. For manufacturing dashboards tracking OEE trends over 12-24 months of sensor history, this changes what is actually reportable without a next-day data lag.
Real-time Intelligence using KQL databases
Power BI’s refresh cadence cannot serve real-time OT use cases. Fabric’s KQL database layer handles high-frequency, time-series data. Manufacturers monitoring line speed, temperature, or energy consumption at the second or minute level can connect a KQL database to live OT streams and surface alerts without waiting for the next report refresh.
Fabric Pipelines as a consolidation layer
Manufacturers running separate Azure Data Factory instances per plant or per system can consolidate data movement into Fabric Pipelines within a single governed workspace. This reduces infrastructure fragmentation and centralises pipeline monitoring. It is not a replacement for complex ADF configurations in every case, but for straightforward MES and ERP ingestion pipelines, consolidation is usually the right direction.
For manufacturers evaluating whether Fabric’s built-in Spark is sufficient for ML workloads or whether a dedicated platform makes more sense, [our Fabric vs Databricks post] covers that comparison in detail.
Manufacturing-Specific Migration Risks to Assess Before You Start
Generic migration guides cover workspace reassignment and semantic model validation. The risks below are specific to manufacturing environments and tend to surface during a migration rather than before it.
On-premises data gateway dependencies
If MES, historian, or ERP systems sit behind a firewall, Power BI connects through an on-premises data gateway. That gateway carries forward to Fabric, but connection types, gateway versions, and data source configurations need to be validated before the workspace migration runs. In environments using legacy gateway versions or industrial connectors such as the OSIsoft PI Connector or AVEVA, this validation has a real lead time and should not be left to the week of migration.
Large semantic models from historian data
Models pulling years of sensor readings from historian systems can approach or exceed standard Power BI model size thresholds. In Fabric, large semantic model storage is supported under Premium capacity but must be explicitly enabled. The model needs to be sized and assessed for refresh behaviour before migration. Discovering a model exceeds limits during a production migration is a preventable problem.
Cross-region Fabric items
Manufacturers with plants in different Azure regions face a specific constraint: workspaces containing Fabric items (Lakehouses, SQL Warehouses, KQL databases) cannot be automatically moved between regions. Those items must be deleted and recreated in the target region. Regional strategy and workspace assignments need to be defined before any Fabric items are created.
Scheduled refresh and pipeline recreation
Scheduled data refresh jobs do not automatically transfer when a workspace is reassigned to Fabric capacity. For a manufacturing environment running dozens of refresh schedules feeding daily OEE reports, shift summaries, and quality dashboards, these need to be inventoried before migration and recreated and validated afterwards.
Existing Power BI dataflows
Dataflows built for MES or ERP data transformation do not automatically migrate to Dataflow Gen 2 or Fabric Pipelines. Complex transformation logic may need to be re-engineered rather than lifted and shifted. This is a scoping item, not a blocker, but it needs to be in the project estimate before migration timelines are set.
A Practical Migration Sequence for Manufacturing IT
A manufacturing Fabric migration does not need to be a multi-month project from day one. The sequence below is built for an IT lead who needs to scope, pilot, and expand in a controlled order without disrupting plant reporting at any stage.
Phase 1: Assess (4-6 weeks)
Inventory the full Power BI estate: workspaces, semantic models, dataflows, and scheduled refreshes. Map each dataset to its source system and gateway dependency. Flag any on-premises Report Server deployments that will lose dual-use rights under F SKUs. Model pay-as-you-go, 1-year reserved, and 3-year reserved capacity scenarios, and bring that cost model into the EA renewal negotiation rather than arriving without one.
Governance decisions belong in this phase: who administers the Fabric capacity, who approves workspace creation, and how Fabric items are governed across plants. These questions become harder to answer after workspaces have already been migrated and users have started creating Fabric items.
Phase 2: Pilot (4-8 weeks)
Pick one plant or one reporting domain as the pilot scope. OEE reporting for a single production line is a reliable starting point because it is high-visibility but low-risk if something needs to be adjusted. Migrate the workspace to Fabric capacity, recreate scheduled refreshes, implement row-level security, and run in parallel with the old capacity assignment for at least 4 weeks before decommissioning.
Phase 3: Expand (ongoing)
Migrate remaining workspaces in order of reporting criticality. Once the capacity migration is stable, begin evaluating Fabric workloads: which datasets suit Direct Lake mode, which OT monitoring use cases justify a KQL database, and whether OneLake consolidation is the right next step for MES and historian data.
The [manufacturing data integration post] covers the data architecture groundwork that makes this phase structured rather than open-ended.
FAQ: Power BI to Microsoft Fabric Migration for Manufacturing
Do existing Power BI reports still work after migrating to Fabric?
Yes. Reports, dashboards, semantic models, and DAX measures carry forward unchanged. Migrating from Power BI Premium to Fabric capacity is a workspace reassignment, not a rebuild. Report users in most cases notice no difference during or after the migration.
What is the Fabric SKU equivalent of Power BI Premium P1?
F64. P2 maps to F128 and P3 to F256. F64 is also the threshold for Copilot access and for allowing free-licence users to consume Power BI content without a Pro licence assigned.
What happens to the Power BI on-premises data gateway when migrating to Fabric?
The on-premises data gateway carries forward to Fabric and continues serving the same data source connections. Gateway versions, connection types, and driver configurations should be validated before migration, particularly for industrial connectors used in manufacturing environments such as OSIsoft PI or AVEVA systems.
Can a manufacturing plant migrate to Fabric without disrupting shift reporting?
Yes, with a parallel-run period. Migrate the workspace to Fabric capacity, validate reports against current data, and keep the old Premium capacity assignment active during testing. Decommission the old assignment only after validation has been signed off by the teams running the reports.
Is Microsoft Fabric the right choice for manufacturers already using Databricks?
Not necessarily a replacement for Databricks. Fabric’s built-in Spark covers most standard manufacturing analytics workloads, but Databricks provides more depth for custom ML model development and fine-grained MLOps workflows. [Our Fabric vs Databricks post] covers this comparison in detail for manufacturers evaluating both platforms.
Next Step: Assess Your Power BI Estate Before Your EA Renewal
The EA renewal is the forcing function. For manufacturing IT leads, the window for a proper assessment covers licensing model, gateway dependencies, on-premises Report Server dual-use rights, and Fabric workload readiness. That window is the 3-4 months before the renewal conversation with Microsoft, not after it.
Simple BI works with manufacturers to scope this assessment: inventorying the Power BI estate, mapping data source and gateway dependencies, modelling licensing scenarios against current usage, and identifying where Fabric workloads create genuine value versus where a like-for-like capacity migration is the right call.
In a 30-minute discovery call, we review your current Power BI environment and give you a clear view of what migration involves for your specific data estate.
