Native Business Central mirroring to Microsoft Fabric: what it means for bc2adls users

At FabCon Europe in Barcelona, Microsoft announced native mirroring of Dynamics 365 Business Central to Microsoft Fabric. If you have ever spent time getting Business Central data into a data platform, this is very welcome news: a first-party, standardised way to replicate Business Central tables to OneLake.

The feature is expected as a Public Preview in Business Central 29.1 (2026 release wave 2). It lets you replicate any table in the Business Central database to OneLake in Delta Parquet format, including tables from extensions and ISV solutions. Synchronisation is incremental, supports deletes and handles schema changes. Latency is described as "a few minutes".

Under the hood, it is built on Fabric Open Mirroring: Business Central pushes changes to an open mirroring database and Fabric processes them itself. The sync reads from the SQL change log instead of running in Business Central sessions. As a result, it does not put load on the NST (the Business Central server tier) and does not count against your API limits. Only committed records are sent.

A few practical details:

• Setup starts in Fabric, where you create an open mirroring database, and continues in Business Central, where you choose the workspace, companies and tables.
• You can select up to 500 tables, due to a limit on the Fabric side. You select whole tables, not fields.
• Everything can be started from the UI, but it can also be fully managed through APIs, including adding tables and starting exports.
• Logging and automatic retries are built in, and you can apply standard table packages.
• There are no additional costs on the Business Central side. You do need Fabric Capacity: F2 is usually sufficient, and the new F0 on-demand SKU (in preview) is an easy way to run a proof of concept.
• Microsoft is also rebuilding the nine standard Business Central Power BI apps on Fabric, in a single-company and a multi-company version.

Until now, bc2adls has been the standard way to export Business Central data in bulk: the open-source extension that started at Microsoft and is now maintained by Bert Verbeek of 4PS and the community. It does its job well, but it runs inside Business Central sessions. That makes it hard to balance with other processes when you need high-frequency replication.

Bert helped build the native integration, together with Microsoft, Navida and 4PS. So it is not so much a replacement as the same ideas now finding their way into the product itself. He has announced that bc2adls is going into maintenance mode: no new features, only fixes on AppSource for a few more releases (until roughly BC30 or BC31). His advice: if you are on BC29, test the new integration and move over at your own pace. He is also looking at ways to migrate both the table setup and the Fabric side, so keep an eye on his blog.

• No field selection: native mirroring replicates whole tables, whereas bc2adls lets you choose fields. If you mirror tables containing personal data, you need to handle data minimisation under the GDPR on the Fabric side, for example with OneLake security, column-level security or masked views. Don't forget to update your record of processing activities as well.
• Same tenant only: the Business Central environment and the Fabric workspace must be in the same tenant, whereas bc2adls can also write to a different tenant. If your organisation runs Business Central in multiple tenants, you need Fabric Capacity in each of them. Also check whether the region of your capacity meets your data residency requirements.
• Fabric becomes a dependency: bc2adls could write to plain ADLS Gen2; native mirroring writes to Fabric. If you use the data in Databricks, Qlik, TimeXtender or something similar, you read it through OneLake shortcuts or the SQL Analytics endpoint, and Fabric Capacity becomes part of your architecture.
• Latency in practice: "a few minutes" sounds good, but we have yet to see how it behaves with large, frequently changing tables.

1. Make sure you are on BC 29.x and try the feature in a sandbox as soon as the preview is available.
2. Run it alongside bc2adls and compare the results.
3. Check the naming: table and field names in the mirrored data may differ from what bc2adls produces. Plan a mapping layer (views, for example) to keep your downstream models, reports and pipelines stable.
4. If you are not on Fabric yet, set up capacity in the same tenant as your Business Central environment.
5. Wait for General Availability before moving production. With bc2adls in maintenance mode until roughly BC30/31, there is time to do this properly, and bc2adls remains your fallback until then.

Getting data out of Business Central has always required more engineering and complexity than it should. A native, low-impact route to OneLake removes much of that, and the fact that the bc2adls knowledge has been built into it is a good sign of its maturity. It is still preview territory, though, so test first before you commit to it.

Would you like to know what this development means for your organisation, or how to approach the move from bc2adls to native mirroring? E-mergo is happy to help you set up your Business Central data in Microsoft Fabric. Feel free to get in touch.

• Bert Verbeek: Native connection with Fabric in Business Central
• Stefano Demiliani: Business Central data mirroring to Microsoft Fabric announced
• Microsoft Fabric blog: What's new in Fabric Data Factory (FabCon Barcelona 2026)
• MSDynamicsWorld: Microsoft is adding mirroring of Business Central data to Fabric