Microsoft Fabric consolidates Power BI, Azure Synapse, Azure Data Factory, and other Microsoft data services into a single platform. Here is what it actually includes, what it is genuinely better at, and the honest assessment of when migration makes sense — and when it does not.
The quick answer
Microsoft Fabric is Microsoft's unified analytics platform — a single SaaS product that consolidates Power BI, Azure Synapse Analytics, Azure Data Factory, and Azure Data Lake Storage into one environment with a shared data layer (OneLake), unified governance (Microsoft Purview integration), and a common capacity billing model. For organisations deeply invested in the Microsoft 365 ecosystem, it is the most integrated path to a modern data platform. For organisations that have already built on Databricks, Snowflake, or other best-of-breed tools, the migration cost is real and the incremental benefit is often marginal. Whether to migrate depends entirely on what you have today and what problems you are trying to solve.
What Microsoft Fabric actually is
Fabric is not a single new product — it is a platform that wraps and unifies a set of existing and new Microsoft data services under a common experience, billing model, and governance layer. Understanding what each component does helps cut through the marketing:
**OneLake** — A unified data lake that is the storage layer for all Fabric workloads. Conceptually similar to Azure Data Lake Storage Gen2, but with a single unified namespace across your organisation and support for shortcuts (logical pointers to data in other locations — S3, ADLS, Google Cloud Storage — without copying it). All Fabric engines read and write to OneLake. OneLake uses Apache Parquet and Delta Lake format natively, which means data stored in OneLake can be read by Spark, SQL, and other engines without conversion.
**Lakehouses** — A Fabric Lakehouse is a Delta Lake-based lakehouse environment with a Spark compute engine, a SQL analytics endpoint, and a visual interface. Conceptually similar to a Databricks Lakehouse, but hosted in Microsoft's managed environment. Data engineers write PySpark or Spark SQL; the SQL analytics endpoint allows BI tools to connect via standard SQL.
**Data Warehouse** — A fully managed SQL warehouse (based on Azure Synapse's distributed SQL engine) for structured analytics workloads. Separate from the Lakehouse but reads from the same OneLake storage.
**Data Factory** — The data integration and orchestration service within Fabric (evolved from Azure Data Factory). Pipelines, dataflows, and connectors for ingesting data from source systems into OneLake.
**Power BI** — The BI and reporting layer, now tightly integrated as a native Fabric workload. Semantic models (formerly Power BI datasets) sit alongside Lakehouses and Warehouses in the same Fabric workspace.
**Real-Time Intelligence** — The streaming and event analytics workload, integrating Azure Event Hubs with KQL (Kusto Query Language) databases for real-time data processing and alerting.
**Data Activator** — An alerting and automation layer that can trigger Power Automate flows or notifications based on data conditions. Newer capability, still maturing.
**AI and Copilot features** — Fabric includes Copilot capabilities across workloads: generating PySpark code, writing DAX, suggesting transformations. Quality varies by workload but is improving.
What Fabric replaces (and what it does not)
Fabric consolidates several Azure services that previously required separate configuration, billing, and governance:
| Replaced by Fabric | Legacy Azure service |
|---|---|
| Fabric Lakehouse | Azure Synapse Spark pools + ADLS Gen2 |
| Fabric Data Warehouse | Azure Synapse dedicated SQL pool |
| Fabric Data Factory | Azure Data Factory (ADF) |
| Power BI (unified) | Power BI Premium / Premium Per User |
| Real-Time Intelligence | Azure Stream Analytics + Azure Data Explorer |
Fabric does **not** replace Databricks, Snowflake, Azure SQL Database, Azure Cosmos DB, or Azure Machine Learning. These remain separate products that can integrate with Fabric via OneLake shortcuts or standard connectors.
Where Fabric is genuinely better
**Unified governance.** The single biggest advantage of Fabric over a multi-service Azure architecture is governance. Instead of configuring access control separately across ADF, ADLS, Synapse, and Power BI — with different permission models in each — Fabric provides a unified workspace model where permissions, sensitivity labels, and Microsoft Purview integration apply consistently across all workloads. For compliance-driven organisations (financial services, healthcare, government), this is a material simplification.
**Power BI integration.** Fabric is the first environment where Power BI semantic models sit alongside data engineering workloads in the same environment, reading from the same OneLake tables without a separate connection layer. The integration eliminates a common source of data consistency issues: the BI layer reading from a different version of the data than the engineering layer. For organisations where Power BI is the primary BI tool, this is the strongest argument for Fabric.
**Capacity billing simplicity.** Fabric charges by capacity unit (Fabric Capacity, measured in CUs) rather than per-service. A single Fabric capacity subscription covers Lakehouse, Warehouse, Data Factory, and Power BI workloads. This simplifies cloud cost management significantly compared to separate billing accounts across multiple Azure services with different pricing models. It also enables pausing capacity when not in use, which reduces idle compute costs.
**OneLake shortcuts.** The ability to create logical shortcuts to data in external storage (S3, ADLS, GCS, Snowflake) without copying it is genuinely useful. It allows Fabric workloads to read from external data sources as if they were local, while the data remains in its original location. This is particularly valuable for organisations that want to adopt Fabric gradually — using shortcuts to read from existing Snowflake or ADLS data while migrating incrementally.
**Reduced operational overhead.** Fabric is a fully managed SaaS platform. There are no Synapse clusters to provision, no ADLS accounts to configure, no ADF integration runtime to manage. For organisations that do not have deep Azure infrastructure expertise, the reduced operational overhead is meaningful.
Where Fabric has limitations
**Spark capabilities are behind Databricks.** Databricks Spark engine is more mature, more performant for complex Spark workloads, and more tightly integrated with the MLflow/Unity Catalog ecosystem. For organisations with significant ML engineering requirements, Databricks remains the stronger platform. Fabric's Lakehouse is good for data engineering workloads but is not a direct replacement for Databricks in ML-heavy environments.
**SQL warehouse is behind Snowflake for pure SQL analytics.** For organisations where SQL query performance and the Snowflake ecosystem (Data Sharing, Snowpark, mature ecosystem of connectors) are primary requirements, Fabric's SQL warehouse is a credible but not superior alternative. The performance gap has narrowed but has not closed.
**The platform is still maturing.** Fabric launched in 2023 and is on a rapid development cadence. Some capabilities — Data Activator, Copilot features, the Real-Time Intelligence workload — are still developing. Organisations that adopt early will encounter features that are not yet production-grade, documentation gaps, and breaking changes. This is not a reason to avoid Fabric, but it is a reason to be deliberate about which workloads to migrate first.
**Migration effort is real.** Migrating an existing Azure data platform to Fabric requires genuine work: reorganising ADLS storage into OneLake, migrating ADF pipelines to Fabric Data Factory, updating Power BI connections, and rethinking the permission model. For organisations with mature existing Azure architectures, the migration cost often exceeds the short-term benefit. The value is most clear for organisations starting fresh or for those whose current architecture is fragmented and poorly governed.
The migration decision framework
Migrate now if:
- You are starting a new data platform with no legacy architecture to migrate
- Your primary BI tool is Power BI and the unified Fabric/Power BI experience solves a real consistency problem
- Your existing Azure data platform is fragmented across many separately managed services and governance is a persistent problem
- You do not have significant ML engineering requirements that would favour Databricks
Wait or migrate selectively if:
- You have a mature Databricks or Snowflake environment that is working well — the migration cost is not justified by incremental benefit
- Your ML engineering team is productive on Databricks and the switch to Fabric Lakehouse would disrupt established workflows
- You are in the middle of a multi-year platform build on existing Azure services — completing the build then evaluating Fabric for the next platform is more pragmatic than switching mid-build
- Your data engineering team needs Fabric capabilities that are still maturing (Real-Time Intelligence, advanced Copilot features)
Migrate via shortcuts if:
- You want to adopt Fabric gradually — connecting Fabric workloads to existing Snowflake or ADLS data via OneLake shortcuts lets you use Fabric's governance and Power BI integration without full migration
What a Fabric migration involves
A full migration from an existing Azure data platform to Fabric typically follows this sequence:
1. **OneLake reorganisation** — Migrate ADLS Gen2 storage into OneLake, or create shortcuts pointing to existing ADLS storage. This is the foundation; everything else depends on it.
2. **Data Factory pipeline migration** — Migrate ADF pipelines to Fabric Data Factory. The tooling is similar; most pipeline logic migrates with modest rework.
3. **Synapse to Lakehouse/Warehouse migration** — Migrate Synapse Spark notebooks to Fabric Lakehouse (straightforward for PySpark). Migrate Synapse dedicated SQL pool to Fabric Data Warehouse (requires query compatibility review and performance validation).
4. **Power BI semantic model migration** — Update Power BI semantic models to read from Fabric Lakehouses/Warehouses rather than Synapse or direct storage connections. The biggest benefit — unified governance — comes from this step.
5. **Permission model redesign** — Migrate from service-specific permission models (ADLS ACLs, Synapse workspace permissions, Power BI row-level security) to the unified Fabric workspace permission model.
Timeline for a mid-market organisation migrating a mid-complexity Azure data platform: 12–20 weeks, depending on pipeline complexity and governance scope.
FAQs
Does Microsoft Fabric replace Azure Data Factory?
Fabric includes its own data integration capability (Fabric Data Factory) that provides the same pipeline and dataflow functionality as ADF, within the Fabric environment. For new Fabric-native workloads, Fabric Data Factory is the right tool. For existing ADF pipelines that are working well and are not being migrated to Fabric, there is no urgency to move — ADF continues to be supported. Microsoft's roadmap points toward Fabric Data Factory as the future, but ADF is not being deprecated imminently.
Can we use Microsoft Fabric alongside Databricks?
Yes. OneLake shortcuts allow Fabric workloads to read from Databricks-managed Delta Lake tables in ADLS without copying data. The common pattern for organisations with both platforms: Databricks handles ML engineering and complex Spark pipelines; Fabric (particularly Power BI + Fabric Warehouse) handles governed SQL analytics and reporting. The OneLake shortcut to ADLS means both platforms read from the same underlying data, which maintains consistency without requiring a single-platform commitment.
What is Microsoft Fabric's pricing compared to Azure services?
Fabric charges by Fabric Capacity (F-SKUs or P-SKUs), with capacity covering all Fabric workloads (Lakehouse, Warehouse, Data Factory, Power BI). For organisations currently paying for Power BI Premium and separate Azure Synapse and ADF costs, Fabric capacity can be cost-neutral or cheaper while providing a significantly better experience. The key cost driver is capacity sizing — over-provisioned Fabric capacity is expensive. Fabric's pause capability (capacity can be paused and restarted) reduces idle costs compared to always-on Azure services.
Is Microsoft Fabric suitable for non-Microsoft BI tools like Tableau?
Fabric's SQL analytics endpoint and XMLA endpoint (for Power BI semantic models) allow Tableau and other BI tools to connect via standard SQL or Analysis Services connections. Tableau can connect to Fabric Lakehouses and Warehouses as standard SQL data sources. The primary integration advantage is for Power BI users — Tableau users get functional connectivity but not the deeper semantic model integration that Power BI gets natively.
Our cloud engineering practice designs and implements Microsoft Fabric architectures, including migrations from Azure Synapse, ADF, and multi-service Azure environments. Our Power BI consulting practice covers Fabric's Power BI integration specifically. If your organisation is evaluating Fabric or planning a migration, book a free 30-minute audit and we will give you a direct assessment of whether the migration makes sense for your current architecture.
A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.
Book a Call →