Microsoft's Azure data platform grew over a decade by adding services — Azure Data Factory for orchestration, Azure Synapse Analytics for data warehousing and Spark, Azure Data Lake Storage Gen2 for storage, Power BI Premium for BI, Azure Stream Analytics for real-time processing. Each service was well-designed for its purpose, but organisations that used all of them faced the compounding costs and complexity of five separate billing meters, five separate management planes, five separate security configurations, and five separate teams of specialists. Migrating to Microsoft Fabric is the answer to this fragmentation — a unified platform that provides all these capabilities under a single product, a single pricing model, and a single administrative surface. This guide covers what Fabric's pricing model actually is (the original post got this wrong), which workloads Fabric covers, the real migration benefits, and how to structure the migration programme.

The Problem Fabric Was Built to Solve

The fragmented Azure data estate created four specific operational problems that Fabric was designed to eliminate. Each problem had a real cost, and understanding it makes the Fabric value proposition concrete rather than abstract.

Data copies and movement costs. In a fragmented Azure data stack, data frequently moved between services — from Data Lake to Synapse for SQL queries, from Synapse to Power BI datasets for reporting, from Data Factory staging areas to analytics outputs. Each movement incurred compute and egress costs and introduced latency. Fabric's OneLake — a single logical storage layer that all Fabric workloads share — eliminates most of this data movement. Lakehouses, Warehouses, and Power BI semantic models all read from the same OneLake storage, without data copies between services.

Billing complexity and fragmentation. An organisation running Azure Data Factory, Synapse, ADLS Gen2, and Power BI Premium had four separate billing meters with four separate pricing models — DIU-hours for ADF, DWU-hours for Synapse SQL pools, storage GB for ADLS, and per-capacity or per-user for Power BI. Finance teams found it difficult to understand total data platform cost, and data teams found it difficult to attribute cost to specific workloads. Fabric's CU model puts all workloads on a single meter, enabling unified cost visibility and workload-level attribution through the Capacity Metrics App.

Identity and access management silos. Each Azure data service had its own access control layer — Synapse workspace permissions, ADLS RBAC and ACLs, ADF pipeline permissions, Power BI workspace roles — and keeping these aligned as teams grew and changed required sustained administrative effort across multiple management planes. Fabric's workspace-based access model and OneLake's unified security layer simplify this to a single access control surface that governs all workloads within a workspace.

Skill fragmentation. Building and maintaining a fragmented Azure data estate required specialists in ADF pipeline development, Synapse SQL and Spark administration, Power BI development, and ADLS configuration — a team composition that was difficult to hire for and expensive to maintain. Fabric's unified platform, with its shared Spark engine (for Notebooks and Data Flows), shared pipeline engine (for Data Pipelines), and shared storage (OneLake), allows a broader range of professionals to contribute across the platform rather than within a narrow service silo.

"Fabric's value is not in any single new capability it is in removing the tax that fragmentation imposes on every team, every project, and every budget cycle. The consolidation benefit compounds over time in ways that are hard to quantify before migration and obvious after it."

What Microsoft Fabric Actually Is

Microsoft Fabric is a unified Software-as-a-Service analytics platform that provides six integrated experience categories: Data Factory (pipelines and Dataflows Gen2 for data integration), Data Engineering (Spark Notebooks and Lakehouses for data transformation and storage), Data Warehousing (SQL-based Fabric Warehouse for structured analytical workloads), Data Science (ML model development and experimentation in Notebooks), Real-Time Intelligence (Eventhouse and KQL for streaming and time-series data), and Power BI (semantic models, reports, and dashboards for business intelligence).

All six experience categories run on a shared infrastructure: OneLake for storage, a shared Spark and SQL compute layer, and a unified Fabric capacity that all workloads consume from the same CU pool. This sharing is what makes Fabric a platform rather than a bundle — the workloads are genuinely integrated at the storage and compute layer, not simply co-located under a single brand.

The Fabric Pricing Model: F SKUs and Capacity Units

Understanding Fabric's pricing model correctly is essential for building an accurate migration business case — the original post on this page described an inaccurate model. Fabric's pricing is fundamentally different from the per-service billing model of the Azure data stack it replaces.

Fabric is purchased as a capacity subscription in SKU tiers: F2, F4, F8, F16, F32, F64, F128, F256, F512, and F1024. Each SKU provides a defined number of Capacity Units (CUs) per second. All Fabric workloads — pipelines, Spark jobs, SQL queries, Power BI refreshes, real-time queries — consume from the same CU pool rather than billing on separate meters. The monthly cost is the SKU subscription price, regardless of which mix of workloads runs on the capacity.

Power BI Pro licences remain per-user — they are required for users who create and publish Power BI content. Power BI viewing through Fabric-backed workspaces can be served to a broader audience without individual Pro licences, depending on the distribution model and licence configuration.

The CU model has a significant implication for organisations migrating from a fragmented Azure stack: if the workloads that previously ran on separate Azure services (ADF, Synapse, ADLS compute) are migrated to Fabric, those workloads consolidate onto the Fabric CU pool and the separate Azure service costs disappear. For many organisations, the Fabric capacity subscription cost is substantially lower than the aggregate cost of the replaced Azure services — though the exact comparison depends heavily on workload volumes and the SKU tier selected.

What Fabric Replaces and What Happens to Existing Services

Fabric does not immediately deprecate the Azure services it conceptually replaces. Azure Data Factory, Azure Synapse Analytics, and Azure Data Lake Storage Gen2 continue to be available as standalone Azure services with their own pricing. The migration to Fabric is a deliberate programme choice, not an automatic transition.

The Fabric workloads that replace existing Azure services are: Fabric Data Pipelines replace Azure Data Factory for orchestration; Fabric Lakehouses replace Azure Data Lake Storage Gen2 and Synapse Spark pools for data engineering; Fabric Warehouse replaces Azure Synapse Analytics SQL pools for relational data warehousing; Fabric Eventhouse replaces Azure Stream Analytics and parts of Azure Data Explorer for real-time intelligence. Power BI's experience in Fabric is functionally the same Power BI product with the same reports, datasets, and semantic models, now backed by Fabric capacity instead of Power BI Premium.

Five Substantive Benefits of Migrating to Fabric

1. Unified storage eliminates data movement costs. OneLake's single logical storage layer means data written to a Lakehouse by a Spark pipeline is immediately readable by a SQL query in Fabric Warehouse and by a Power BI DirectLake semantic model — without any data copy or movement. The storage cost is the OneLake storage component (included in the Fabric capacity), not the sum of separate ADLS Gen2, Synapse dedicated pool, and Power BI dataset storage.

2. Single billing meter simplifies FinOps. Replacing four or five separate Azure service billing meters with a single Fabric CU capacity subscription dramatically simplifies the data platform FinOps programme. The Fabric Capacity Metrics App provides workload-level CU attribution — which pipeline, which Spark job, which semantic model refresh consumed how many CUs — enabling cost accountability without the cross-service billing reconciliation that the fragmented Azure stack required.

3. Faster time from data to insight. The elimination of inter-service data pipelines that previously moved data between services reduces the latency between data availability and analytical access. A pipeline that previously took 4 hours because it involved ADF extraction, ADLS staging, Synapse loading, and Power BI dataset refresh can complete in a fraction of that time when all components run natively in Fabric without inter-service data movement.

4. Power BI DirectLake mode. Fabric enables Power BI DirectLake — a new semantic model storage mode that reads directly from Delta Parquet files in OneLake at in-memory speed, without importing data into a Power BI dataset. DirectLake provides query performance comparable to Import mode without the dataset refresh cycle, and analytical capacity comparable to DirectQuery without the per-query source database overhead. This is a genuinely new capability that is not possible outside the Fabric architecture.

5. Unified governance and security. Fabric's unified workspace model, OneLake's shared security layer, and Microsoft Purview integration provide a single governance surface for all workloads. Sensitivity labels, access permissions, data lineage, and audit logging apply consistently across Lakehouses, Warehouses, Notebooks, Pipelines, and Power BI content within the same workspace — rather than requiring separate governance configurations per service.

A Phased Migration Strategy That Works

A successful migration to Microsoft Fabric follows a phased approach that builds confidence and value at each stage rather than attempting a full-estate cutover.

Phase 1 — Assess and baseline. Catalogue the existing Azure data estate: which services are in use, which workloads run on each, what the current monthly costs are per service, and which business domains they serve. For organisations already on Power BI Premium, the Power BI Premium to Fabric capacity upgrade is typically the lowest-friction starting point — the same reports, datasets, and workspaces move to Fabric with minimal change, immediately enabling OneLake integration and DirectLake capability.

Phase 2 — Migrate data engineering workloads. Move Azure Data Factory pipelines to Fabric Data Pipelines for orchestration workloads that are compatible with the Fabric Pipeline connector library. Migrate Azure Synapse Spark notebooks to Fabric Spark Notebooks and move the underlying data to Fabric Lakehouses in OneLake. This phase delivers the storage consolidation benefit and removes the most significant separate billing meters.

Phase 3 — Migrate SQL warehousing workloads. For organisations running Azure Synapse SQL dedicated pools, evaluate migration to Fabric Warehouse. Fabric Warehouse provides T-SQL compatibility for most analytical SQL patterns, and the Delta Parquet storage format used by OneLake is readable by both Fabric Warehouse and the Lakehouse SQL analytics endpoint — enabling flexible access patterns without storage duplication.

Phase 4 — Optimise and expand. Once the core data engineering and BI workloads are on Fabric, the optimisation phase applies Fabric-specific capabilities: enabling DirectLake on semantic models where Import mode refresh cycles were previously a constraint, implementing real-time intelligence workloads in Eventhouse for streaming data sources that previously went to Azure Stream Analytics, and connecting additional source systems using the growing Fabric connector ecosystem.

Who Should Migrate Now vs Who Should Wait

Migrate now if your organisation is already on Power BI Premium (the Premium to Fabric capacity upgrade is low-friction and immediately enables Fabric's unified storage and DirectLake); if you are running Azure Synapse and Azure Data Factory together and want to reduce the operational overhead of managing two separate services; or if you are starting a new data platform programme and can build on Fabric natively rather than inheriting the fragmented Azure service model.

Wait or migrate selectively if you have a heavily customised Azure Synapse Spark environment with workloads that depend on Synapse-specific configurations not yet available in Fabric; if your organisation has strict data residency requirements in regions where Fabric is not yet available; or if you are in the middle of a major Synapse investment that would be disrupted by a platform migration.

Fabric vs the Fragmented Azure Data Stack

Next Steps for Your Fabric Migration

The right starting point for most enterprise migrating to Microsoft Fabric programmes is a data platform assessment — a structured inventory of the current Azure data estate, a workload-by-workload migration readiness evaluation, and a cost model that compares the current fragmented billing with the equivalent Fabric capacity subscription. This assessment is what converts the Fabric migration from a technology discussion to a business case discussion with a clear ROI narrative.

For organisations already on Power BI Premium who want to begin the migration without a full programme commitment, the Power BI Premium to Fabric capacity upgrade is a single administrative action in the Microsoft 365 admin centre that enables all Fabric workloads under the existing capacity cost. It is the lowest-risk starting point available and provides immediate access to DirectLake, OneLake integration, and the full Fabric workload set.

If your organisation is planning a Fabric migration and wants expert guidance on the assessment, business case, migration sequencing, and technical delivery, speak with a certified Microsoft Fabric consultant at Numlytics. We work with data engineering, finance, and IT leadership teams across the US, UK, Australia, and UAE to design and deliver Fabric migration programmes that reduce platform cost, simplify governance, and accelerate analytics value. For more detail on specific Fabric capabilities, see our posts on Fabric's capacity model, Fabric capacity overage, and Fast Copy in Fabric Data Pipelines.