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.

The replace/not-replace list resolves to one principle, and holding it prevents most expensive mistakes: the line is between transaction and analysis. Systems that record what happened — the ERP booking a goods movement, the MES confirming a job, the WMS timestamping a pick, the CRM logging an order — are systems of record, and Fabric does not touch them. Systems that read across those records to inform a decision — the warehouse, the semantic model, the dashboard — are the analysis layer, and that is what Microsoft Fabric consolidates. Fabric reads from the transaction layer; it never becomes it.

Vendors blur this line because blurring it sells more, and the blur is where projects go wrong. Fabric is not an ERP, not an MES, not a master-data management tool — and an initiative that drifts into trying to make it one of those is crossing the line by accident. OneLake will faithfully store the 400 duplicate customer records the ERP never cleaned; the analysis layer surfaces the mess, it does not fix the source. Cross the line deliberately — decide what stays transactional and what becomes analytical — and the architecture stays coherent.

This is also why the OT/IT integration and the master-data stewardship do not disappear in a Fabric estate. The plant-floor protocol problem (OPC-UA, MQTT) is solved before Fabric sees the data, and the steward who owns ERP master-data quality is still required after Fabric is live. Fabric makes the analysis layer one platform instead of four; it does not absorb the transactional and governance work that sits on the other side of the line. Knowing which side a problem lives on is the whole discipline.

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.

The decision is a consolidation decision, not a rip-and-replace. If you are running a three-to-five-year-old Synapse estate — 40 to 200 undocumented pipelines, a dedicated SQL pool running 24/7, Power BI Premium failing silently when the 3 a.m. pipeline breaks — the case for collapsing that into one Fabric platform is strong: fewer moving parts, one billing relationship, one governance boundary, Microsoft Purview and Copilot native rather than bolted on. The 30–45% Synapse-pool saving in the practitioner example is real, but the bigger win is the morning ops review running on data current to 90 minutes instead of 36 hours stale.

The discipline is to scope it by the transaction/analysis line and to respect coexistence. Migrate the operational analytics layer to Fabric; leave a well-tuned Azure Databricks ML workload where it is and let it write to OneLake via Delta Lake so Fabric reads the same tables. Treating Fabric as the answer to every data workload is the mistake; treating it as the consolidation of the analysis layer, with the systems of record and specialist ML left deliberately on their own side of the line, is the architecture that holds.

And it starts as one dataset, not a big-bang migration. A six-week Discover-and-Prototype migrates the two or three most operationally critical Power BI datasets to Direct Lake on OneLake and hands the CIO a proven migration blueprint for the rest of the estate — first value on a live dashboard with no 4 a.m. refresh dependency, the legacy estate retired domain by domain as each Fabric equivalent is proven. Consolidate the analysis layer deliberately, keep the transactional systems where they belong, and the estate gets simpler and cheaper without an outage.