Business Central Mirroring in Microsoft Fabric: How It Works and When to Use It

In Short: Business Central Mirroring Puts ERP Data in OneLake Without a Pipeline

At FabCon Europe 2026 in Barcelona, Microsoft announced data mirroring from Dynamics 365 Business Central to Microsoft Fabric. You choose the companies and tables, and Business Central replicates an initial snapshot and then ongoing changes into an open mirrored database in OneLake, stored as Delta Parquet. Power BI, Data Factory, Fabric IQ and the rest of Fabric can then use the data without reading it again and again from the Business Central APIs.

It is not generally available. Microsoft Learn describes it as prerelease and says it "is planned to become available as a production-ready preview in October 2026", while the Microsoft release roadmap lists preview for November 2026 and general availability for April 2027. At the time of writing (27 October 2026) we could not confirm that the extension is listed on Microsoft Marketplace yet. This post explains how it works, how it compares with the routes in our Business Central to Fabric guide, what is still unclear, and when we would still choose API extraction.

What Business Central Mirroring Is

Mirroring in Fabric is a managed way to keep a copy of a source system in OneLake, in Delta format, without building an ETL pipeline. Our guide to mirroring in Fabric covers the general idea. Business Central uses the open mirroring flavour: Fabric provides the mirrored database and its landing zone, and Business Central itself writes the changes into it.

That design matters. You do not pick Business Central from Fabric's list of mirroring sources. You create an empty open mirrored database in Fabric, then point Business Central at it from inside Business Central.

According to Microsoft Learn, the integration supports:

• Multiple Business Central companies
• Up to 1,000 selected tables
• An initial snapshot followed by incremental synchronisation
• A Microsoft configuration package, MS-STD, containing 256 standard tables for analytics
• Monitoring in Business Central, through APIs, and from Fabric

Microsoft also plans versions of the standard Business Central Power BI apps that read from Fabric, in single-company and multicompany versions. Microsoft notes that availability "can change during the preview".

How It Works

The documented setup runs in five steps:

• Create an open mirrored database in a Fabric workspace.
• Connect Business Central to the workspace and database through the Connect to Microsoft Fabric assisted setup.
• Grant the mirroring service principal access. Business Central adds it to the workspace as a Contributor.
• Select the companies and tables to synchronise, individually or through a configuration package.
• Start synchronisation and monitor each run.

The prerequisites are specific. Business Central must be online, on 2026 release wave 2, version 29.0 or later, with the Microsoft Fabric Mirroring extension installed and data encryption enabled. For the preview you also need a dedicated app registration in Microsoft Entra ID, with a client secret and the Power BI Service Workspace.ReadWrite.All delegated permission. On the Fabric side you need an active capacity and a workspace in the same Entra tenant.

Synchronisation runs on an interval you set in Minutes Between Exports. A Max Consecutive Failed Runs setting, from 1 to 5 with a default of 2, decides when synchronisation stops after repeated failures. Data lands in a `BusinessCentral` schema, and operational logs in `BusinessCentral_log`, so you can query sync history alongside the data itself.

The monitoring is better than most hand-built pipelines. For each run and each company and table, Business Central records whether it was an initial or incremental run, the inserted, updated and deleted record counts, and the change-tracking watermarks.

How It Compares With the Existing Routes

Until now, getting Business Central into Fabric meant one of the three routes in our Business Central to Fabric guide: the Dataverse link, Fabric pipelines calling the Business Central APIs, or Azure Data Factory. Microsoft's own guidance on extracting data from Business Central is blunt: for Business Central online, "the only supported option for reading data is using APIs".

Mirroring changes that. Here is how the routes compare:

• Dataverse link - useful if Business Central is already connected to Dataverse, but not every Business Central table is surfaced there, and Dataverse throttling applies.
• API extraction with Fabric pipelines or Data Factory - generally available, fully under your control, and able to shape data on the way in. You build and maintain the incremental logic, deletion handling and throttling yourself. Microsoft documents a parallelism of 5 concurrent API calls in Business Central online.
• Mirroring - no extraction code, deletes tracked, monitoring included, and the replication compute is free. But it is preview, online only, and table-level rather than shaped.

On cost, Fabric's mirroring documentation says the background compute used to replicate data into OneLake is free and does not consume capacity, and that you get 1 TB of free mirroring storage for every capacity unit you buy. Querying the data with SQL, Power BI or Spark is charged at normal rates, and mirroring needs a running capacity. If the capacity is paused, nothing replicates.

On load, Microsoft says Fabric can use the data "without repeatedly reading it from Business Central APIs". Community testers in the private preview, including Microsoft MVP Stefano Demiliani, report that mirroring uses an internal replication service rather than the public APIs, so it does not count against API limits. Microsoft's documentation does not yet state that in those words.

Limits and What Is Not Yet Clear

Several things are documented. Mirroring is for Business Central online, so on-premises environments are not covered. You can select up to 1,000 tables, and activating a configuration package cannot take you past that limit. The Fabric workspace and database cannot be changed while export is enabled; you have to reset the integration first, which removes the mirroring resources and resets all watermarks.

Other details are unpublished or come only from early testers:

• Field selection. Testers report that you choose tables and companies, not fields, so every column of a selected table is replicated. Microsoft's documentation does not say either way.
• Extension tables. Testers report that tables from extensions can be mirrored as well as standard ones. Check this against your own customisations in the preview.
• Multi-company layout. Microsoft has not documented whether each company lands as its own set of tables or as one table with a company column. That decides how much consolidation work stays in your Silver layer.
• Latency. Testers report a few minutes behind Business Central, depending on how busy the data is. Microsoft has published no latency figure, and the interval you set also applies.
• Pricing after preview. Testers report no extra Business Central licence charge. Microsoft has not published pricing for the feature itself.

Treat it accordingly. Production-ready previews are subject to supplemental terms, and Microsoft says delivery timing and functionality might change.

Multi-Company and History

Most Business Central tenants hold several companies, and mirroring handles that directly: you add each company you want, and Microsoft's guidance is to synchronise per-company tables for each enabled company and shared tables once. A company can be temporarily skipped by clearing its Enabled flag without losing its configuration.

History needs more thought. A mirror is a copy of the current state of each table, kept in step with inserts, updates and deletes. It is not a history of changes. Fabric mirroring runs vacuum automatically, and the default retention for new mirrored databases is one day, so you cannot rely on Delta time travel for audit or trend reporting unless you change that setting deliberately.

If you need slowly changing dimensions, period-end snapshots or a record of what a customer's credit limit was last March, build that downstream. Mirror into OneLake, then snapshot or merge into a Silver layer you control, following the medallion architecture.

Historic companies are a related case. In our Business Central API extraction case study, a wine group had merged three companies into one live company and kept the old ones as read-only history. Because they still sit in Business Central as companies, mirroring should be able to include them. If your history lives in a separate environment, or in an older NAV database, mirroring will not reach it, and a one-off load is still required.

When to Use Mirroring and When to Use API Extraction

Choose mirroring when you are on Business Central online version 29.0 or later, you want standard and extension tables in Fabric with as little pipeline code as possible, and you can accept preview terms for now. It is a strong fit for new Fabric builds, for replacing fragile hand-built API pipelines, and for teams that want Business Central data in OneLake for Power BI and data agents quickly.

Keep or choose API extraction when you need a production-supported route today, you are on-premises or on an older version, you need data shaped or filtered before it lands, or your history sits outside the environment. API pipelines are also the safer choice where a go-live date cannot wait on a preview whose timing has already moved between October and November.

Expect to combine them. Many estates will end up mirroring the bulk of Business Central tables and keeping a small number of pipelines for other sources, historical loads or edge cases. Whichever route lands the data, the hard part is the same: resolving dimensions, conforming companies, and modelling finance logic that people trust. In our Jet Enterprise to Fabric case study, the real work was carrying 142 measures across from seven cubes, not moving the rows.

How We Approach Business Central to Fabric

We do not rebuild working pipelines just because a new feature exists. Our approach is:

• Inventory first. List the tables, companies and history you actually report on, and check them against MS-STD and your extensions.
• Prove it on preview. Once the extension is available, mirror a non-production environment into a separate workspace and compare row counts and totals against your current pipeline.
• Keep the layers. Treat the mirrored database as Bronze. Dimensions, company consolidation and history belong in Silver and Gold, whatever the source.
• Switch with a fallback. Move tables across in stages, keep the API pipeline available until general availability, and watch the logging tables.

Our Microsoft Fabric data platform team builds Business Central estates on Fabric, from extraction to Direct Lake semantic models. If you are deciding between waiting for mirroring and building pipelines now, we can help you plan both routes.

Sources and Further Reading

• Data mirroring to Microsoft Fabric from Business Central
• Set up Business Central data mirroring to Microsoft Fabric
• Manage Business Central synchronisation with Microsoft Fabric
• Monitor and troubleshoot Microsoft Fabric synchronisation
• Extract data from Business Central
• Mirroring in Microsoft Fabric
• FabCon and SQLCon 2026 in Barcelona: Building the data foundation for Microsoft Copilot and agents