Business Central to Fabric in zero ETL steps: what the new mirroring preview means for BC customers

Mirroring is coming to Business Central, and it removes the hardest part of BC analytics: getting the data out. What is replicated, how fresh it is, what is not yet supported, and the questions worth asking before you switch from an existing pipeline.

The hardest part of Business Central analytics has never been the reporting. It has been getting the data out. Anyone who has built serious reporting over BC knows the ritual: API pages with throttling limits, incremental loads that need babysitting, or a third-party connector with its own licence and its own quirks.

Mirroring changes that equation, which is why it was one of the announcements we paid most attention to at FabCon Europe 2026. This post is written from the perspective of a consultancy that works with Business Central clients every week, not as a restatement of the announcement.

What is actually arriving, and when

Two things are true at once, and they get conflated.

• Native Microsoft mirroring for Business Central is coming as part of the 2026 release wave 2, with public preview expected alongside BC version 29.1. You configure mirroring in Fabric, connect it from a new setup page inside Business Central, then choose the tables and companies to synchronise. Data lands in OneLake as Delta Parquet, queryable through SQL and usable directly by Power BI. Microsoft is also rebuilding its standard BC Power BI apps on this foundation, including multi-company versions.
• The BC2Fab workload is generally available today. Built by Navida on Fabric's Open Mirroring architecture, it handles incremental change detection, schema updates and custom extension fields, and reads from APIs or read-only replicas to keep load off the live ERP. We have seen it running against tables in the hundreds of millions of rows.

So the position for a BC customer in late 2026 is: a native, Microsoft-supported route is close, and a proven workload route exists now. Either way the direction is clear. The ETL layer between Business Central and your analytics platform is disappearing.

What zero-ETL actually means in practice

Zero ETL does not mean zero work. It means the extraction and loading layer, the part that consumed most of the engineering effort and caused most of the failures, is handled by the platform:

• No scheduled pipeline pulling API pages at 2am.
• No watermark logic to maintain.
• No gap between what BC holds and what your lakehouse holds when a load silently fails.

What it does not remove is transformation and modelling. Mirrored tables are operational tables. They carry BC's table and field naming, option fields stored as integers, and a schema designed for transaction processing rather than analysis. Turning G/L Entry, Value Entry and Item Ledger Entry into a finance model the business trusts still takes the same dimensional modelling it always did. The difference is that you do that work inside Fabric, on data that is already there, rather than spending the first month of the project building plumbing.

In a typical architecture the mirrored database is bronze. Transformation into modelled silver and gold layers happens in the lakehouse or warehouse, a semantic model sits over the top, and Power BI consumes it. Our Business Central analytics page sets out the approach we use on client estates.

What to check before you switch

If you already have a working ingestion approach, this is not automatically a reason to replace it. These are the checks we run with clients first.

• Coverage. Confirm the tables you need are supported, including custom tables and extension fields. Preview capabilities typically start with core tables and widen over time.
• Freshness. Mirroring is near real time by design, but validate actual latency against your reporting needs, especially for intraday operational reporting.
• Deletes and renames. Understand how the mirror handles deletions, archivals and schema changes before month-end depends on it.
• Capacity. Mirrored data lands in OneLake and queries against it consume Fabric capacity. Check what your capacity has spare, or size it with our Fabric licensing calculator.
• Multi-company. If you consolidate across companies or environments, confirm how the mirror represents them and how your model will stitch them together.
• The existing investment. A stable, tested pipeline feeding a trusted model has value. The right moment to switch is usually when that pipeline next needs significant work, not the day a preview arrives.

When mirroring wins, and when a pipeline still does

Mirroring is the right default when the goal is analytics over BC data with minimal infrastructure: finance reporting, sales analysis, inventory and margin views, consolidated group reporting. It removes the most failure-prone layer and keeps data continuously fresh without scheduling.

A pipeline still earns its place when:

• Heavy transformation is needed on the way in.
• You are combining BC with sources that cannot be mirrored and want one consistent ingestion pattern.
• You need point-in-time snapshots the source system does not keep.

Plenty of estates will sensibly run both: mirroring for BC, pipelines for everything else.

Our view

For mid-market organisations running Business Central this is one of the most consequential Fabric announcements of the year. It collapses the cost of the first mile of analytics. The organisations that benefit most will treat the saved effort as budget for the parts that create value: the model, the definitions, the governance and the adoption.

Hopton is a Microsoft Solutions Partner working with Business Central and Fabric estates across the UK and Ireland. If you are weighing mirroring against your current approach, or starting BC analytics from scratch, talk to us. Our Microsoft Fabric page covers how we deliver the platform around it.