# BC data mirroring to Fabric: what changes this quarter > Business Central mirroring to Microsoft Fabric replicates any AL table into OneLake with no API pages. Who should move, what it costs, where it stops. Published: 2026-10-12 Author: Preetham Reddy Tags: Dynamics 365, Databricks, News Canonical: https://www.techfabric.com/blog/business-central-fabric-data-mirroring-what-changes --- At FabCon Europe in Barcelona on 29 September 2026, Microsoft announced data mirroring for Dynamics 365 Business Central into Microsoft Fabric, and the short version is that you can replicate any AL table, across companies, into OneLake without writing a single API page ([Demiliani](https://demiliani.com/2026/09/30/dynamics-365-business-central-data-mirroring-to-microsoft-fabric-announced/)). If you have been maintaining a custom extraction pipeline out of Business Central for reporting, this is the thing that retires it, provided you are willing to buy Fabric capacity. That is the announcement. The rest of this is what it means from the seat of someone who has to decide what to do about it before the end of the quarter. ## Who should care, and who can stop reading Custom extraction approaches exist because, for years, customers have asked how to get their data out of Business Central for BI and reporting. Mirroring moves that problem to Microsoft. Care also if you are mid-project on a Business Central analytics build. The design changes. You stop arguing about which fields to expose and start arguing about which tables and companies to mirror, because mirroring replicates every field in the tables you choose. Your selection happens at the table and company level, deletes are propagated, and the mirror behaves as a live copy of the SQL data instead of a curated feed. You can ignore it, for now, if you are on Business Central on-premises, if you have no Fabric capacity and no appetite to buy one, or if your version is behind. The feature requires 2026 release wave 2, version 29.1 (possibly 29.0), and it is available globally. On-prem customers keep doing what they are doing. And if your Business Central data has to land next to data from other systems in a Databricks lakehouse, read the Databricks section below before you conclude mirroring is the whole answer. It is a very good first hop, and it stops well short of being a platform decision. ## What it replaces, and the one line that tells you it is different The detail that matters most is in the plumbing. Mirroring uses an internal replication service instead of the Business Central APIs, so it doesn't consume API limits and doesn't load the production database. Every homegrown extraction approach before this paid a tax somewhere, whether that was API throttling, read-replica hints or a scheduled job competing with month-end close. Compare the setup. The community's existing answer, the BC2Fab workload, works by pulling through Business Central APIs with `DataAccessIntent = ReadOnly` so queries hit the read-only replica, and its install asks you for an app registration ID, a Key Vault URI, an environment name and a company list before it builds a mirroring database, a pipeline and a daily refresh schedule ([BC2Fab docs](https://docs.bc2fab.com/guides/install-bc2fab.html)). When you add custom tables or endpoints, the selected API must expose columns named `systemRowVersion` and `systemId` exactly, and its Set Default Setup task adds around 250 reporting-relevant tables automatically. That is a well-built product solving a problem Microsoft had not solved. Native mirroring removes the app registration, the key vault, the API contract and the daily schedule. Native setup takes three steps. You create a mirroring database in Fabric, point Business Central at it, then choose the companies and tables to mirror. Note the ordering quirk, because it will cost you twenty minutes otherwise. Business Central doesn't appear in the standard Fabric mirroring source picker, so you start from the mirroring database and Business Central's own setup page. Latency is currently measured in a few minutes and varies with how volatile the data is. The initial historical sync takes longer than the incremental runs that follow, which is the normal shape of any change-feed replication and worth saying out loud to whoever expects the first load to finish over lunch. No table, row or volume limits have been identified so far, and Fabric scales mirroring compute up and down on its own, so there is no tuning knob to get wrong. ```mermaid %% caption: Native mirroring replaces the API-based extraction pipeline, and Databricks reads the same OneLake Delta tables through Unity Catalog federation. flowchart TD A["Business Central SQL tables"] --> L["Custom API pipeline"] A --> C["Fabric mirroring database"] L --> D["Reporting store"] C --> E["OneLake Delta tables"] E --> F["Power BI Direct Lake"] E --> G["Unity Catalog federation"] class C accent class L legacy ``` ## What it costs, which is a Fabric question On the Business Central side, mirroring costs nothing. No extra licence, no consumption charge. The bill moves to Fabric, and mirroring requires Fabric capacity, meaning an F SKU, commonly F2 or higher, or an existing P SKU. Microsoft's own mirroring economics help here. For database mirroring, the background compute used to replicate data into OneLake is free and doesn't consume capacity units, and you get one free terabyte of mirroring storage per capacity unit purchased ([Microsoft Learn](https://learn.microsoft.com/en-us/fabric/database/mirrored-database/overview)). What you pay for is the querying, so SQL analytics endpoint, Power BI and Spark are all charged at normal rates. One more line from that page belongs in your runbook. A paused or deleted capacity affects mirroring and no data is replicated, and you pay for OneLake storage when the capacity is paused. Start at F2 and resist the urge to size for a peak you have not measured. F2 is the smallest fixed-capacity F SKU at which mirroring works, a fixed number is easier to budget than a usage curve, and you can scale up when mirrored tables, volume or report load actually demand it. The licensing trap sits in Power BI rather than Fabric itself. On F SKUs below F64, every user viewing Power BI content needs Pro, PPU or an individual trial; only on F64 and above can a user with a Fabric free licence and a viewer role read Power BI content ([Fabric licensing](https://learn.microsoft.com/en-us/fabric/enterprise/licenses)). So an F2 plus forty finance users who all need Pro licences is the real cost of the pilot. Price that before you quote a number to a CFO. Microsoft also announced a zero-provisioned F0 SKU with on-demand billing, pay-per-use with nothing upfront, which is listed as coming soon, in preview in the coming weeks, and should make standing up a proof of concept easier once it arrives. Both F0 and on-demand billing across Fabric are listed as coming soon, in preview in the coming weeks, prices unpublished, with Microsoft's own feature summary saying availability and timelines are subject to change ([Solv Systems](https://solv-systems.com/resources/fabric-f0-on-demand-billing)). Use a Fabric trial capacity to validate the idea today, and F0 once it reaches preview. Do not put a production reporting commitment on a preview billing model whose price list doesn't exist yet. ## The limits to plan around Mirroring gives you tables, and a model is still yours to build. What lands in OneLake is the AL table shape, with Business Central's own naming and its own ideas about dimension set IDs, posting groups and record-level flow fields. Anyone who has tried to explain `G_L Entry` plus `Dimension Set Entry` to a business analyst knows that a mirror is the start of a semantic layer and never a replacement for one. Budget the modelling work you were going to do anyway. It mirrors tables per environment, which means a group with several Business Central environments or tenants gets several mirrors and a consolidation problem. Nothing in the announcement does cross-environment conflation for you. There is no field selection. Every field in a mirrored table is replicated. If a table holds personal data or salary-adjacent fields you did not intend to publish to the analytics tenant, your control point is table choice plus Fabric permissions, since a column filter is not on offer. Review that list with whoever owns data protection before you flip the flag on employee or contact tables. And mirroring is a Fabric feature. If your analytics platform is something else, this is a landing zone inside somebody else's SaaS and not a general-purpose export. Which brings us to the part that matters if you run Databricks. ## Reading the mirror from Databricks Mirrored data sits in OneLake in Delta Lake format, and Databricks can read it in place. Unity Catalog's OneLake catalog federation lets Unity Catalog queries run directly against OneLake storage without copying, and access is read-only ([Azure Databricks docs](https://learn.microsoft.com/en-us/azure/databricks/query-federation/onelake)). Supported Fabric items are Lakehouse and Warehouse, compute must be Databricks Runtime 18.0 or above in standard access mode, and SQL warehouses must be 2025.40 or above. Authentication is an Azure managed identity via an Access Connector for Azure Databricks, which the documentation recommends, or a service principal when the Fabric workspace lives in a different tenant. The prerequisites live in Fabric instead of Databricks, and they are the part that stalls. A Fabric administrator has to enable three tenant settings. Service principals can call Fabric public APIs, apps running outside of Fabric are allowed to access data via OneLake, and short-lived user-delegated SAS tokens are permitted. Then in the workspace holding the data, Authenticate with OneLake user-delegated SAS tokens must be enabled under Workspace settings, Delegated settings, OneLake settings. Grant the identity Contributor at workspace level, or Viewer plus a Read all permission on the individual item, because the SQL-only Read all with SQL analytics endpoint permission is not sufficient for OneLake reads. It also goes the other way. Fabric can mirror an Azure Databricks Unity Catalog, synchronising only the catalog structure while the underlying data is reached through shortcuts, with no data movement and no replication ([Fabric docs](https://learn.microsoft.com/en-us/fabric/onelake/onelake-unity-catalog)). Materialized views, streaming tables and non-Delta external tables are not displayed, which trims what your Fabric users will see. A company that already runs Databricks has an architecture worth considering. Let Microsoft's mirror do the extraction, federate it into Unity Catalog, and keep the modelling, the forecasting and the AI work where your other sources already live. Business Central mirroring solves the extraction problem without touching API limits, since it relies on an internal replication service and bypasses the Business Central APIs. Joining Business Central data to other source systems stays outside its remit, so that modelling work remains yours to do on your own platform. Catalog federation reads directly against object storage on Databricks compute, which Databricks describes as more cost-effective and performance-optimized than JDBC query federation ([Databricks](https://docs.databricks.com/aws/en/query-federation/)). One correction to the common framing, because it causes real confusion on Business Central projects. The Lakeflow Connect Dynamics 365 connector doesn't reach Business Central. It reads what Azure Synapse Link exports from Dataverse, and Business Central keeps its data in its own SQL database. Before this announcement, Business Central reached Databricks through a built pipeline, either standard API pages read incrementally with a `lastModifiedDateTime` filter or tables exported by the open-source bc2adls extension. Fabric mirroring is now a third route, and for Fabric-adjacent estates it is the better one. ## Run the pilot on a trial capacity against one company Spin up a Fabric trial capacity, mirror one company and a short list of tables, and measure. G/L entries, customer and vendor ledger entries, item ledger entries, and sales and purchase documents cover most of what a finance team asks for first. Watch the initial sync duration, then watch steady-state latency during a busy posting day instead of on a quiet Sunday. Check capacity consumption in the Capacity Metrics app before you commit to an F SKU, and count how many Power BI Pro licences the reader population needs on a sub-F64 capacity. Then make the platform call deliberately. If Fabric is where your analytics live, mirroring plus F2 is the shortest honest path and you should plan to decommission your custom extraction in the same quarter. If Databricks is your platform, mirror into OneLake and federate, and keep the curated models under Unity Catalog. Either way, the custom API pipeline you have been maintaining for Business Central reporting is now technical debt with a sunset date, and the comparison of built-in reporting, Power BI and a lakehouse in [Business Central reporting: built-in, Power BI or lakehouse](/blog/business-central-reporting-built-in-power-bi-or-a-lakehouse) needs rereading with mirroring in the mix. ## Frequently asked questions ### Does Business Central data mirroring to Fabric use API limits? No. Mirroring relies on an internal replication service and bypasses the Business Central APIs, so it doesn't consume or affect API limits and doesn't affect production database performance. ### What does Business Central mirroring to Fabric cost? Nothing on the Business Central side, with no additional licensing or consumption charge there; you pay for Fabric capacity, which means an F SKU of F2 or higher or an existing P SKU. Fabric's background replication compute for mirroring is free and doesn't consume capacity units, and each capacity unit includes one free terabyte of mirroring storage, so your variable cost is querying and any Power BI Pro licences needed below F64. ### Which Business Central version do I need? Data mirroring requires Dynamics 365 Business Central 2026 release wave 2, version 29.1 and possibly 29.0, and it is available globally. ### Can Databricks read Business Central data mirrored into OneLake? Yes, through Unity Catalog OneLake catalog federation, which runs Unity Catalog queries directly against OneLake storage with read-only access to Fabric Lakehouse and Warehouse items. It needs Databricks Runtime 18.0 or above in standard access mode, SQL warehouses on 2025.40 or above, and three Fabric tenant settings enabled by a Fabric administrator.