Three Ways to Get Business Central Data Into Microsoft Fabric (And Which One You Actually Need)

Your finance team wants better reporting. Operations wants Business Central data combined with information from the warehouse, CRM, e-commerce platform or another company. IT wants a data architecture that will still make sense three years from now.

Someone suggests Microsoft Fabric.

That does not automatically mean you need to move your Business Central data into a lakehouse.

There are several ways to handle a Business Central Microsoft Fabric integration, and the right choice depends on what you are trying to accomplish. Before you buy Fabric capacity or start building pipelines, decide which problem you actually have.

What Fabric actually is, if you own a P&L rather than a data platform

Microsoft Fabric is Microsoft’s end-to-end analytics platform. It brings together data integration, engineering, data science, real-time analytics and business intelligence on one platform.

At the center of it is OneLake, Microsoft’s organization-wide logical data lake. Fabric stores structured tabular data in Delta Parquet format so different Fabric workloads can work with the same underlying data.

For a CFO or VP of Operations, the useful distinction is simpler.

Business Central runs the business. Fabric gives you somewhere to bring Business Central data together with data from other systems, prepare it and use it for broader analytics, reporting and AI scenarios.

That distinction matters because Business Central already has reporting options. Microsoft specifically points to financial reporting, Excel, analysis mode and Power BI reports built from Business Central APIs as existing options. It positions Fabric for more advanced scenarios requiring richer data engineering or data integration.

For example, if your requirement is a handful of Power BI reports against Business Central, adding Fabric may give you architecture you do not need.

If you need to combine ERP data with POS, CRM, manufacturing, logistics or other operational data, Fabric starts making considerably more sense.

There are three practical paths.

Path 1: Pull the data through OData and APIs

The simplest approach is to retrieve the Business Central data you need through its web services and load it into your reporting or Fabric environment.

Business Central supports REST APIs and OData V4 web services. Microsoft’s current recommendation for integrations is to favor REST APIs; its API stack is optimized specifically for this purpose.

This approach works well when the scope is controlled.

The advantage is obvious: you do not need to replicate the entire Business Central database just because someone wants a gross-margin dashboard.

The disadvantage appears when the requirement grows.

APIs are application interfaces, not unlimited bulk extraction pipes. Business Central Online applies throttling to web-service traffic, and Microsoft specifically tells developers to handle HTTP 429, 503 and 504 responses appropriately.

How the endpoints are built matters too. Microsoft recommends API pages or API queries rather than exposing normal Business Central UI pages, because UI pages can contain logic and calculations that make them inefficient as web-service endpoints.

The same principle applies on the receiving side. Select the columns you actually need, filter the records at the source and use server-driven paging. Pulling every field from every record and deciding what matters later is usually poor design.

Use this path when: the number of datasets is limited, the refresh requirement is reasonable and Business Central is primarily feeding reporting rather than becoming one source in a much larger enterprise data platform.

Do not turn an API solution into a homemade data replication platform. Once you find yourself maintaining extraction logic across dozens of large tables and multiple companies, you should be looking at the other two paths.

Path 2: The community lake-export pattern

The second approach came from a problem Business Central customers had for years: getting larger quantities of Business Central data into a data lake efficiently.

Microsoft originally developed an experimental open-source project called BC2ADLS. It used a Business Central extension to export incremental data changes to Azure Data Lake Storage and included Synapse components to consolidate those changes for analytics.

Microsoft later archived its repository in September 2023 and explicitly stated that it would not receive further updates. Development continued in a community-maintained fork.

That distinction matters.

This is not a current Microsoft product feature with the same support model as Business Central itself.

The community version has continued to evolve and can export incremental Business Central data to Microsoft Fabric or Azure Data Lake Storage.

For organizations that adopted this pattern before newer Fabric options became available, it can still be a legitimate architecture. Replacing something that is stable simply because a newer option exists is not automatically good engineering.

But we would not start here by default for a new Fabric project in 2026.

You are taking responsibility for an open-source component in the middle of your data architecture. That means someone needs to understand the extension, deployment, permissions, updates and what happens when either Business Central or Fabric changes.

While this approach is reasonable for an organization that has a technical team, it’s much less reasonable if the finance department thinks it is buying a standard Microsoft integration without having to maintain it.

Path 3: Microsoft’s native Business Central link into OneLake

This is where the Business Central and Fabric story changed.

In March 2026, Microsoft announced the BC2Fab Fabric workload for integrating Dynamics 365 Business Central with Microsoft Fabric. BC2Fab replicates Business Central data into OneLake using Fabric’s Open Mirroring capability and incremental change detection.

The important part is the architecture.

Instead of repeatedly querying Business Central whenever an analyst wants data, the pattern creates an analytical copy in OneLake. Microsoft describes BC2Fab as allowing analytics teams to build reporting, AI and Copilot solutions on ERP data without affecting Business Central’s transactional workloads.

That is a better fit for organizations whose requirement is broader than a few reports.

Once Business Central data is in OneLake, it can participate in the wider Fabric environment alongside information from other systems. Fabric workloads can then use that data for analytics and downstream scenarios without making Business Central itself do all the analytical work.

It’s important to note that just because Microsoft now provides a cleaner path into Fabric, doesn’t mean every Business Central customer needs Fabric.

They do not.

Moving data into OneLake does not fix unclear KPIs, inconsistent dimensions, duplicate master data or a chart of accounts that was never designed for the reporting the business now expects.

Fabric can give you a better data platform. It cannot decide what “gross margin” means in your organization.

Choosing between them

The decision should come from the reporting and data requirement, not from the technology you want to buy.

For a relatively contained reporting requirement, start with Business Central APIs. Keep the architecture small until there is a reason to make it larger.

If you already have a BC2ADLS-based architecture that is stable, documented and supported internally, there may be no immediate business case for rebuilding it. Evaluate the newer Fabric approach against the cost and risk of changing what you already have.

For a new project involving significant Business Central data, multiple companies, other source systems or a broader Fabric analytics strategy, BC2Fab and OneLake deserve to be the starting point for the architecture discussion.

There is also a fourth answer that gets ignored too often: do not use Fabric yet.

If the real requirement is better financial statements, a sales dashboard and a cleaner month-end reporting process, first determine whether Business Central’s reporting capabilities and Power BI can solve it.

Microsoft itself positions Fabric for the more advanced data engineering and integration scenarios.

Maybe You’re Not Ready Yet…

There are cases where these three paths are not the right starting point.

If you are running Business Central on-premises, have significant custom data architecture outside the standard application, require a specialized external warehouse, or have regulatory and data-residency constraints dictating where information must live, the architecture needs to be evaluated separately.

The same applies if Business Central is only a small part of an existing enterprise data platform. In that situation, the question is not “How should we connect Business Central to Fabric?” It is “How does Business Central fit the data architecture we already operate?”

Do not redesign an established data platform around one ERP application without a business reason.

Three questions to ask a partner before you sign for capacity

1. Why does this need Fabric?

The answer should describe a data requirement, not a Microsoft product. Multiple systems, large analytical datasets, reusable enterprise data or advanced analytics are reasons. “Fabric is where Microsoft is going” is not an architecture.

2. How will you extract Business Central data without hurting Business Central?

Ask whether the design uses APIs, incremental replication, Open Mirroring or another approach. If APIs are involved, ask how filtering, paging, retries and throttling are handled. Microsoft documents all of these as real considerations for Business Central web services.

3. What will this cost when it is running normally?

Do not accept an estimate based only on getting the first dashboard working.

Ask what Fabric capacity is required, what workloads will consume it, how usage will be monitored and what happens as data volume and refresh frequency increase.

Where To Go From Here?

If you are planning a Business Central Microsoft Fabric integration, start with the data requirement, not Fabric.

Map what you need from Business Central, how often it needs to change, what other systems it needs to join and who will consume it. Then choose the smallest architecture that meets those requirements.

At Qixas Group, we work across Business Central, Power BI and Microsoft Fabric, which means our recommendation does not have to begin with selling you Fabric capacity.

Sometimes the right answer is an API.

Sometimes it is OneLake.

And sometimes the right answer is to leave the architecture alone and fix the reporting you already have.

Qixas Group implements Business Central, Power BI and Microsoft Fabric integrations, and we also support and tune Business Central for teams who are not sure yet whether they have a Fabric problem or a reporting problem.

Talk to Qixas Group before you build the data pipeline.