Your ERP holds the most strategic data in your organisation: orders, inventory, margins, DSO, production costs. Your Power BI reports consume a 24-hour-old copy exported by a Python script that runs overnight. Between the two, a data engineer spends every Friday reconciling tables that refuse to join.
Microsoft Fabric offers a different architecture. Since its general availability launch in November 2023, the platform unifies what was previously scattered across Azure Data Factory, Azure Synapse Analytics, Power BI Premium, and Azure Data Lake Storage Gen2 — all under a single pane of glass. For a CIO overseeing one or more ERPs on Azure, the question is no longer “should we look at Fabric?” but “how do we architect it correctly?”
This practical guide covers available connectors by ERP, the four-step data pipeline, and concrete use cases for a mid-market industrial company.
What Is Microsoft Fabric and Why CIOs Are Talking About It in 2026
Fabric = Data Factory + Synapse + Power BI + OneLake in a Single Platform
Microsoft Fabric is a unified analytics SaaS platform that brings six distinct experiences under one interface and one licensing model: Data Factory (ingestion and orchestration), Data Engineering (Spark notebooks), Data Warehousing (relational warehouse), Real-Time Intelligence (event streams), Data Science (ML), and Power BI (visualisation).
The central element that sets Fabric apart from a simple integration of Azure services is OneLake. OneLake is a single storage layer, managed by Microsoft on Azure Data Lake Storage Gen2, where all Fabric components read and write without duplicating data. A Delta Lake file ingested by a Data Factory pipeline is immediately readable by a Spark notebook, queryable by a SQL warehouse, and visualisable in Power BI — with no intermediate copy.
For a CIO accustomed to classic ERP architectures with three or four separate data stores (SQL Server for reporting, integrator SFTP, SSAS cubes, archive Blob Storage), the shift to a single shared lake is a substantial architectural change.
How Fabric Compares to Azure Data Factory Alone and Databricks
Azure Data Factory alone remains relevant for targeted ETL pipelines between two systems. But it provides neither centralised storage, nor a SQL engine, nor visualisation. A classic ADF architecture requires separately provisioning Azure Synapse or Azure SQL Database, Power BI Premium, and ADLS Gen2. Fabric bundles these with unified licence governance.
Databricks is a serious alternative in the data science and high-volume segment. It too supports the Delta Lake format. The structural difference: Databricks is multi-cloud and aimed at advanced data engineering teams. Fabric is optimised for Microsoft-centric organisations (Teams, SharePoint, Dynamics 365) and integrates Power BI natively, which reduces the adoption curve for business users.
For a mid-market company running on Azure that lacks a dedicated data engineering team but has one or two Power BI power users, Fabric is generally more accessible.
Fabric Pricing: F4 to F2048 SKUs — What It Actually Costs for Mid-Market
Microsoft Fabric runs on Azure capacities purchased on-demand or as annual reservations. SKUs range from F2 to F8192, with each tier doubling available compute power.
For a mid-market company consolidating two to three ERPs with reasonable data volumes (under 500 GB of operational tables), an F8 is typically a sufficient starting point. Based on Azure West Europe pricing verified in July 2026 (Agilytic), an F8 costs approximately €657/month on annual reservation, or around €1,300/month on pay-as-you-go. The reservation is roughly 40% cheaper but billed continuously.
A tactical advantage of pay-as-you-go: capacity can be paused during off-peak hours (nights, weekends), reducing the actual bill by 50–70% if your pipeline is batch-only.
Per-user licences (Free, Pro, PPU) are added on top of capacity. From F64 and above, users with a Free licence can view Power BI reports in read-only mode. Below F64, each Power BI reader needs a Pro licence (approximately €10/month/user).
Native Fabric Connectors for Major ERPs
Dynamics 365 Finance & Supply Chain — Native Integration via Fabric Link
For organisations running Dynamics 365 Finance or Supply Chain Management, Microsoft provides Fabric Link (formerly Azure Synapse Link for Dataverse). The integration is native: from the Power Apps portal, the administrator enables export of Dataverse tables directly to OneLake, without building a custom pipeline.
D365 tables (orders, inventory, general ledger, accounting entities) appear in your Fabric lakehouse as Delta Lake files, updated near-real-time via change data capture. Microsoft officially decommissioned the legacy “Export to Data Lake” feature on 25 March 2025 (Microsoft Learn), making Fabric Link the standard path for Dynamics 365.
Coverage is broad: Finance, Supply Chain Management, Customer Insights, Field Service, and Marketing are all supported via Dataverse.
SAP S/4HANA and SAP HANA — Via SAP Connectors in Fabric
For SAP, Fabric offers several approaches depending on the version and deployment model:
- SAP HANA connector (GA since 2024 in Fabric Pipelines): direct connection to an on-premise or cloud SAP HANA instance via SQL. Supports partitioned copy for large volumes. Requires a Self-Hosted Integration Runtime (SHIR) for on-premise instances.
- OData connector (Fabric Dataflows Gen2 or Pipelines): for SAP S/4HANA Public Cloud, which exposes its entities via OData APIs (CDS Views, communication arrangements). This is the recommended approach for S/4HANA Cloud without direct HANA database access.
- Partner connectors: for advanced scenarios (RFC, BAPI, SAP change data capture), partners like Theobald Software (xtract for Fabric) or USB4SAP enable more comprehensive extractions from SAP ECC or S/4HANA on-premise systems.
Microsoft also announced enhanced collaboration with several SAP specialist partners in 2025 to cover S/4HANA analytical scenarios, including table snapshots and CDS queries (Microsoft Community Hub).
Odoo, Sage Business Cloud, and Other Mid-Market ERPs — Via Dataflow Gen2 and REST Pipelines
For ERPs without a native Fabric connector, the generic approach uses their REST or OData API:
- Odoo exposes an XML-RPC API and, since version 16, a JSON REST API. A Dataflow Gen2 in Fabric can query these endpoints to extract data models (sale.order, account.move, stock.quant) and load them into a lakehouse.
- Sage Business Cloud and other mid-market ERPs typically expose documented REST APIs. Ingestion is built via Fabric Pipelines using the generic REST connector. Pagination and OAuth token management are configurable directly in the Fabric interface, without code.
The limitation of this approach: it is batch-based (periodic API calls) rather than streaming. For reports refreshed hourly, this is sufficient. For near-real-time (under five minutes), you need webhooks or dedicated CDC connectors, which increases complexity.
OneLake as the ERP Data Governance Layer
The “One Copy of the Truth” Principle
In a classic ERP architecture, operational data exists in multiple copies: in the source ERP, in the reporting data warehouse, in Excel exports sent to managers, and sometimes in a legacy OLAP cube. Each copy gradually diverges whenever export business rules are not strictly identical.
OneLake breaks this model by applying a shortcut principle rather than copying. Dynamics 365 tables remain in Dataverse; they are accessible in OneLake via a pointer that reads them directly, without duplication. A Power BI report querying that shortcut always reads source data, not an intermediate copy.
For SAP or Odoo data, however, ingestion produces a real copy in OneLake (Delta Lake files). But this copy is unique — all Fabric tools share it. No more desynchronisation between the Finance report and the Supply Chain report because they read two different warehouses updated at different times.
Rights Management and Domain Segmentation
OneLake integrates Microsoft Purview for governance and cataloguing. Each Fabric workspace corresponds to a business domain (Finance, Supply Chain, HR) and access rights are managed at the workspace level via Fabric roles (Viewer, Contributor, Member, Admin).
Segmentation matters for ERP data, which often contains sensitive information (payroll, per-client margins, supplier data). Fabric inherits the Entra ID access controls from your Microsoft 365 tenant, avoiding the need to manage a separate identity repository.
Microsoft Purview also enables data lineage creation: tracing that a figure in a Power BI report comes from a Dynamics 365 Finance table via a Fabric pipeline, with the last update timestamp. This is a strong argument for auditors and management control teams who want to understand the production chain behind a KPI.
Lakehouse vs Warehouse in Fabric: When to Choose Which for Your ERP
Fabric offers two analytical storage modes:
- Lakehouse: Delta Lake file storage (structured Parquet format + transaction logs). Accessible via Spark (notebooks) and SQL (automatic endpoint). Ideal for semi-structured data, large volumes, and complex transformations.
- Warehouse: managed SQL warehouse with full DDL (tables, views, stored procedures). Ideal for teams that prefer to reason in T-SQL and build classic dimensional models (star or snowflake).
For a mid-market company with a single ERP and a limited team: start with a Lakehouse. The learning curve is gentler, and the automatic SQL endpoint allows querying data without managing a full DDL schema.
For a group with multiple ERPs and an experienced BI team: a T-SQL Warehouse simplifies multi-source consolidation, explicit integration rules, and shared business views.
From Raw ERP Data to Power BI Reports — The 4-Step Pipeline
Step 1 — Ingestion via Dataflow or Pipeline
ERP data enters Fabric via one of these mechanisms:
- Fabric Link (Dynamics 365): triggered automatically by change data capture, no pipeline to maintain.
- Fabric Pipeline with a source connector (SAP HANA, REST, OData): scheduled orchestration (hourly, nightly) or event-triggered.
- Dataflow Gen2: low-code interface inspired by Power Query, for lightweight on-the-fly transformations during ingestion.
Data lands in the Lakehouse “Files” folder in raw form (the bronze layer in a medallion architecture).
Step 2 — Transformation into Delta Lake
A Spark notebook or SQL script transforms raw data into structured Delta Lake tables (silver layer, then gold layer). This step applies business rules: joining ERP entities, standardising currencies, computing aggregates (DSO, inventory turnover, service rate).
The Delta Lake format (Parquet + transaction log) guarantees transformation atomicity and enables time-travel: rolling back to a previous version of data in case of a transformation error.
Step 3 — Power BI Semantic Model in Direct Lake Mode
This is Fabric’s key innovation for Power BI teams: Direct Lake mode.
In classic Import mode, Power BI copies data into an in-memory cache. This is fast, but data is frozen until the next refresh (typically 1 or 8 times per day on Premium).
In DirectQuery mode, Power BI queries the source database on every interaction. Always up to date, but often slow on ERP volumes.
Direct Lake mode combines both advantages: Power BI reads Delta Lake files directly from OneLake without copying them, with performance close to Import mode. As soon as a pipeline loads new data into the lakehouse, reports reflect the update without manual refresh.
Step 4 — Publishing in Teams and SharePoint for Business Users
Power BI reports published to a Fabric workspace are accessible directly in Microsoft Teams (Power BI tab in a channel) and SharePoint Online (Power BI web part). Business users access ERP KPIs without leaving their familiar tools.
For non-technical profiles (executives, operational managers), this integration reduces adoption friction. The report is not “in the IT system”; it is in the management team’s Teams channel.
Concrete Use Cases for a Mid-Market Industrial Company
Real-Time DSO Dashboard from Dynamics 365
Days Sales Outstanding (the average collection period for customer receivables) is a key treasury indicator for mid-market companies. Calculated manually from an accounting export, it is often available only at end of week.
With Fabric Link + D365 Finance, invoice and payment tables are continuously exported to OneLake. A semantic model calculates DSO by customer, by sales rep, and by segment in Direct Lake mode. The CFO consults a continuously updated figure in Teams — not a Friday Excel export.
Multi-ERP Consolidation for a Corporate Group
A group with a UK subsidiary running SAP S/4HANA and a German subsidiary running Odoo 17 has two incompatible data repositories: different expense accounts, currencies, and group-specific consolidation rules.
Fabric centralises both sources in OneLake. A Spark transformation layer normalises the charts of accounts to a group reference. The monthly consolidation report, previously produced over five days by the management controller, becomes a nightly-updated dashboard.
A realistic example: a 300-employee company consolidating three ERPs in a Fabric F8 (approximately €657/month on annual reservation in West Europe, per Agilytic) can produce fifteen Power BI reports in Direct Lake. Without Fabric, an equivalent architecture requires Azure Data Factory, Azure Synapse Analytics, Power BI Premium, and ADLS Gen2 managed separately — with significantly higher maintenance and expertise costs.
Predictive Purchase Analysis via Fabric Notebooks
Once ERP data is in OneLake, Fabric notebooks (Python/Spark) can train forecasting models on supplier order history. A simple model (linear regression or Random Forest on seasonal volumes) anticipates stockouts and optimises reorder points.
Fabric’s advantage over an ad-hoc ML project: the notebook runs on the same capacity as the ingestion pipeline and the Power BI report. No separate ML environment to provision. The trained model is exportable to Azure ML if requirements grow more complex.
Pitfalls and Limitations to Anticipate
Data Latency: Batch vs Near Real-Time
Except for Dynamics 365 via Fabric Link (which is change-data-capture based), most ERP integrations in Fabric are batch: the pipeline triggers hourly, nightly, or on demand. Reports therefore reflect data with a lag.
For use cases where freshness is critical (real-time inventory management, intraday cash alerts), batch is not sufficient. You then need Fabric’s Real-Time Intelligence features (KQL databases, Event Streams) coupled with ERP webhooks. Complexity and cost increase accordingly.
Defining the required freshness level before architecting the solution is a prerequisite that many teams overlook.
On-Premise ERPs and the Self-Hosted Integration Runtime
For on-premise ERPs (SAP ECC, on-site Sage Business Cloud, Dynamics AX 2012), Fabric cannot access the database directly from the cloud. The connection goes through a Self-Hosted Integration Runtime (SHIR): an agent installed on an internal network server that relays Fabric queries to the local data source.
The SHIR is a dedicated Windows machine (or VM), with the associated maintenance constraints: updates, availability, network security. For organisations aiming to eliminate all on-premise infrastructure, this is a friction point. For those already running a hybrid Azure infrastructure, it is a familiar and manageable component.
Fabric Does Not Replace a Master Data Management Strategy
This is the most common trap. Fabric centralises ERP data, but it does not fix data quality at the source. If your master data (customer repository, item nomenclature, chart of accounts) is inconsistent in the ERP, Fabric centralises it as-is — and aggregates inconsistencies at scale.
A supplier created three times with different spellings in your ERP will appear as three rows in your lakehouse. A consolidation report built on ungoverned master data will produce incorrect figures, no matter how sophisticated the Fabric pipeline.
Before connecting Fabric to your ERP, audit your master data quality. If it is in disarray, a prior MDM initiative is essential — our guide Master Data Management and ERP covers the six-step methodology.
Microsoft Fabric fundamentally changes the analytics equation for mid-market CIOs running on Azure: one platform, one shared lake, native connectors for Dynamics 365 and SAP, and Power BI in Direct Lake for always-current reports. The complexity has not disappeared — it has shifted towards master data governance and defining required freshness levels.
To go further on the KPIs to monitor after deploying an ERP data architecture, read our guide ERP and Business Intelligence: Embedded Reporting, Dashboards and Analytics in 2026 and our article on post-deployment ERP governance.
If you want to validate the architecture before committing a Fabric budget, a three-month proof of concept on a target process (accounting consolidation or DSO dashboard) is the recommended approach. Typical budget: €15,000 to €30,000. Outcome: a Go/No-Go decision based on concrete data on actual refresh rates, capacity costs, and BI team adoption.
