Microsoft Fabric — What it Replaces, What it Doesn't

Most articles about Microsoft Fabric describe the architecture. This one describes what changes on a Monday morning at a manufacturing site when it is running.

The answer is more specific — and more limited — than the marketing materials suggest. That specificity is useful.

Walk into a mid-market manufacturing or FMCG business that has been on Azure for three to five years. Here is what you usually find.

An Azure Synapse workspace that was set up to be the data warehouse. It has somewhere between 40 and 200 pipelines, most of which are undocumented. It has a dedicated SQL pool that is running 24/7 and costing more than it should. The team that built it has mostly moved on.

Separate Azure Data Factory pipelines feeding Synapse — also largely undocumented, built incrementally as each new data source was added.

A Power BI Premium capacity slab sitting on top of that. Import mode datasets refreshing on schedules that nobody has reviewed in 18 months. When the Synapse pipeline fails at 3 a.m., the Power BI dataset fails silently, and the operations team spends the first hour of the morning wondering why their OEE dashboard is showing yesterday's numbers.

Azure Databricks, in some cases, handling a specific machine-learning workload or a complex transformation that could not be done in Synapse. Billed separately. Governed separately. Integrated by a set of fragile API calls.

Microsoft Fabric replaces that stack — or a significant portion of it.

OneLake replaces the Azure Data Lake Storage Gen2 layer and the Synapse dedicated SQL pool as the canonical storage. Delta Parquet is the open format sitting underneath. Azure Data Factory continues to do the ingestion work — pulling from SAP S/4HANA, SAP ByDesign, Microsoft Dynamics 365, or NetSuite — but it lands the data in OneLake rather than Synapse. The warehouse capability in Fabric replaces the Synapse dedicated pool for most analytical workloads. The Direct Lake connection mode in Power BI replaces Import mode for the high-priority operational reports — which means the dashboard reads from the lake directly, no scheduled refresh, no 4 a.m. pipeline dependency.

For a CIO managing that legacy Synapse estate, the consolidation argument is real. Fewer moving parts. One billing relationship. One governance boundary. Microsoft Purview runs natively across OneLake without a separate connector. Copilot in Power BI has access to the semantic model without a separate AI infrastructure investment.

The ERP. SAP S/4HANA, SAP ByD, Dynamics 365 — these remain the systems of record for financial transactions, sales orders, procurement, and inventory. Fabric consumes from them. It does not replace them.

The MES or SCADA layer on the plant floor. If your production data comes from a manufacturing execution system — whether that is a purpose-built MES or a SCADA historian — Fabric ingests from it via OPC-UA, MQTT, or a file-based extract. It does not manage the production process. OT/IT integration still needs to be solved at the protocol layer before Fabric sees the data.

The master-data steward. This is the one most organisations miss. Fabric organises and governs data with exceptional capability — but it cannot clean data that was never clean. If your SAP ByDesign has three versions of the same material code, or your customer master has 400 duplicate records, OneLake will store all three versions and all 400 duplicates with equal fidelity. The data steward who owns master data quality in the ERP is still required. Fabric is not a substitute for data discipline upstream.

Copilot in Power BI is genuinely useful in a Fabric estate. A supply chain analyst who wants to ask "what was our OTIF performance for the UAE last quarter compared to the prior year?" can get a chart in seconds rather than building a DAX measure from scratch.

The caveat: Copilot answers from the semantic model. If the semantic model does not have a well-defined OTIF measure — or if OTIF is defined differently in two datasets — Copilot will either fail to answer or answer confidently with the wrong figure. The intelligence is in the model, not in the AI.

This is not a criticism of Copilot. It is an architectural reality. Build the semantic model correctly, define the measures with business precision, and Copilot becomes a genuinely fast interface for non-technical users. Skip that work, and Copilot becomes a source of plausible-sounding but incorrect answers.

If your organisation has already built a tuned Azure Databricks lakehouse — purpose-built for a specific ML workload, optimised over 18–24 months, with Unity Catalog governing the data — the migration calculus is different from a greenfield or Synapse-migration scenario.

Fabric's Spark compute is capable. But it is not Azure Databricks. If your data science team has deep Delta Lake expertise in a Databricks environment and your ML pipelines are production-grade, the overhead of migrating to Fabric Spark for that specific workload is unlikely to be worth it in the short term. Fabric and Databricks can coexist — Databricks writes to OneLake via Delta Parquet, Fabric reads from the same tables. That is often the right architecture for a manufacturing business that has both an operational analytics need (Fabric) and a specialist ML need (Databricks).

The mistake is treating Fabric as a replacement for everything. It is a platform consolidation for the analytics and reporting layer. It is not a single answer to every data workload.

A mid-market FMCG business in India running SAP ByDesign for financials and a third-party WMS for distribution had a classic Synapse estate — built in 2021, expensive, fragile, and producing Power BI dashboards that were 24–36 hours stale by the time operations saw them.

The migration to Microsoft Fabric involved moving the ADF pipelines to land data in OneLake, replacing the Synapse dedicated pool with Fabric warehouse, and switching the primary Power BI datasets to Direct Lake mode. Scrap rate, OTIF, and fill rate dashboards moved from Import mode — with a 4 a.m. refresh dependency — to Direct Lake, updated as frequently as the ADF pipeline runs.

The cost reduction on Synapse dedicated pool licensing was 30–45% in the first three months. The bigger win was operational: the morning ops review now shows data that is current to within 90 minutes of the overnight ADF run, not 36 hours stale.

If you are currently on a well-tuned Azure Databricks lakehouse with production ML pipelines and Unity Catalog governance, and your primary pain point is ML performance rather than operational reporting latency, Fabric migration is not the immediate priority. The two platforms can coexist — prioritise Fabric for the operational reporting layer and leave Databricks for the specialist workloads.

If your ERP is genuinely on-premises and has no API or export capability, the ADF integration work required before Fabric becomes useful is a separate project — one that needs to be scoped and resourced independently.

Discover: audit the current Synapse and ADF estate, identify the two or three most operationally critical Power BI datasets, map the SAP S/4HANA or SAP ByD source queries. Prototype: migrate one dataset to OneLake in Delta Parquet, connect Direct Lake in Power BI, deliver one live operational dashboard — OEE, OTIF, or scrap rate — with no Import refresh dependency. By week six, the operations team has a real-time operational view and the CIO has the migration blueprint for the rest of the estate.