Business Central holds a huge amount of operational value, but its transactional database was never built to be a reporting engine. The moment your finance, sales, and operations teams start asking for cross year trends, blended datasets, and dashboards that refresh through the day, you feel the strain. That is where an Azure Data Lake comes in. By moving a governed copy of your ERP data into the lake, you get room to analyze, model, and run AI on that data without slowing down the system your business runs on.
This guide walks through what the integration actually involves, the two architecture paths available in 2026, a practical setup sequence, and how to reach genuine near real time analytics. If you want hands on help scoping any of this, our team does this work every week, but the walkthrough below is written so you can understand the moving parts yourself first.
What Business Central Azure Data Lake integration means
In plain terms, the integration replicates selected Business Central tables (customers, vendors, general ledger entries, sales orders, inventory transactions, and any others you choose) into cloud storage that is optimized for analytics rather than transactions. Business Central writes the data out incrementally, so only changed records move after the first full load. Analytics tools then read from that copy, which keeps heavy reporting queries off the live ERP database.
Two destinations dominate today. The first is Azure Data Lake Storage Gen2 paired with Azure Synapse. The second is Microsoft Fabric with its unified storage layer, OneLake. Both give you the same core benefit, a separate analytics copy of your ERP data, but they differ in setup effort, freshness, and where the future is heading.
Why offload Business Central data to a lake
Running analytics directly on the operational database creates two problems. Complex queries compete with live transactions for resources, and the normalized ERP schema is awkward for reporting. Many teams discover this the hard way when standard reports slow to a crawl during month end. If you have hit the ceiling of native reporting, our breakdown of explains the underlying reasons.
A data lake solves this in a few ways:
- It separates the reporting workload from the transactional workload, so dashboards no longer compete with order entry.
- It lets you keep long history in cheap storage instead of bloating the ERP database, which also supports archiving and audit needs.
- It creates a single analytics ready surface where Business Central data can be blended with data from CRM, e commerce, warehouse, and other systems.
- It becomes the foundation for machine learning and Copilot style AI on your own ERP data.
The two architecture paths in 2026
Path 1: Azure Data Lake Storage Gen2 with Synapse
This is the established approach, built around an open source tool commonly called bc2adls. A Business Central extension named Azure Data Lake Storage Export (ADLSE) pushes incremental data updates into a container on ADLS Gen2 in the Common Data Model folder format. Azure Synapse pipelines then consolidate those increments into a clean data folder that Power BI and Synapse serverless SQL can query.
One note on the tooling. The original Microsoft published repository is no longer receiving updates, and active development moved to a community maintained fork by Bert Verbeek. If you go this route, start from the maintained fork rather than the archived original.
This path suits teams that already run a Synapse based data platform, need fine control over transformation logic, or work with on premises Business Central.
Path 2: Microsoft Fabric with OneLake
This is the newer, more native option and where Microsoft is clearly investing. The BC2Fab Fabric workload, built on Open Mirroring, is generally available, and it replicates Business Central tables directly into OneLake as Delta tables. Because OneLake is the single storage layer for all of Fabric, that data is instantly available to Fabric experiences (Data Engineering, Data Warehouse, and Power BI) without creating extra copies.
The big advantage is that the core setup needs no custom middleware. Business Central writes selected tables straight into OneLake, and Power BI reads them back quickly through Direct Lake mode. Fewer moving parts means fewer things to break.
Quick comparison
| Consideration | ADLS Gen2 + Synapse (bc2adls) | Microsoft Fabric + OneLake (BC2Fab) |
|---|---|---|
| Setup effort | Higher, more manual pipeline work | Lower, largely native |
| Data freshness | Periodic to hourly by default | Near real time via Open Mirroring |
| Best for | Existing Synapse platforms, on prem BC | New analytics builds, cloud first teams |
| Custom transformation control | Very high | High, inside Fabric |
| Direction of Microsoft investment | Stable but legacy leaning | Primary future path |
If you are starting fresh, Fabric is usually the better long term bet. If you already have a Synapse investment, the bc2adls path still delivers.
Prerequisites before you start
Getting the groundwork right prevents most integration headaches later. You will need:
- A Business Central environment (cloud or on premises) where you have permission to install extensions and configure exports.
- An Azure subscription with the right resources provisioned, either an ADLS Gen2 storage account plus a Synapse workspace, or a Microsoft Fabric capacity. Setting up that environment cleanly is exactly the kind of work our team handles when internal Azure skills are thin.
- A registered Microsoft Entra ID (Azure AD) service principal with the correct permissions, since older username and key authentication methods have been deprecated.
- A clear list of which tables and fields you actually need. Exporting everything is tempting but wasteful.
One more prerequisite is often overlooked: data quality. A lake will faithfully replicate messy source data, so cleaning it up first pays off. Our field notes on apply here too.
Step by step setup
The exact clicks differ slightly between the Synapse and Fabric paths, but the logical sequence is consistent.
- Provision the destination. Create either your ADLS Gen2 storage account and Synapse workspace, or a Fabric workspace with a Lakehouse. Note the endpoints and workspace identifiers, since Business Central will need them.
- Register the service principal. In Microsoft Entra ID, create an app registration and grant it access to the storage or the Fabric workspace. Capture the tenant ID, client ID, and secret.
- Install the export extension in Business Central. Add the ADLSE extension (or enable the native Fabric export, depending on your path) through Extension Management, then confirm the installation status.
- Configure the connection. Open the export setup page in Business Central and enter the Azure or Fabric details you gathered, including the storage endpoint or Lakehouse target and the service principal credentials.
- Select your tables and fields. Choose exactly the entities you need for analytics. Start lean and add more later rather than exporting the whole database on day one.
- Run the initial full export. The first run seeds the lake with a complete copy. Depending on volume, this can take a while, so schedule it outside peak hours.
- Schedule incremental updates. Set up a Job Queue Entry so only changed records flow after the seed load. Many teams run this hourly, though the interval is yours to tune.
- Consolidate and model. On the Synapse path, run the pipelines that merge increments into the clean data folder. On the Fabric path, the Delta tables in OneLake are ready to model directly.
- Validate. Compare record counts and spot check key figures against Business Central before anyone builds reports on the new source.
How to reach genuine near real time analytics
Be clear eyed about the word real time. In an ERP analytics context, real time almost always means near real time, measured in minutes rather than milliseconds, and that is perfectly adequate for operational dashboards.
The classic scheduled export gives you periodic freshness, for example a refresh every hour. To get closer to live, the Fabric path with Open Mirroring is the strongest option, because it streams changes into OneLake continuously rather than on a fixed timer. Power BI Direct Lake then reads those Delta tables without an intermediate import step, so dashboards reflect new data very soon after it lands.
If you are on the Synapse path and need fresher data, you can shorten the Job Queue interval, but watch the impact on both the source system and your consolidation pipelines. There is a practical floor where running exports too frequently costs more than the freshness is worth.
Consuming the data once it lands
Getting data into the lake is only half the value. What you build on top is what your users actually see.
- Power BI. This is the most common consumption layer. With Fabric, Direct Lake mode reads OneLake Delta tables at speed without a separate import. If your team wants a governed, well modeled semantic layer, our cover the modeling and dashboard work.
- Copilot and AI scenarios. A governed lake copy of ERP data is the ideal grounding source for AI features. If you are curious what is realistic today, see our honest look at .
- Agentic workflows. Beyond dashboards, teams are starting to build agents that act on this data. Our piece on explores where that is heading.
- Data science and machine learning. With data in Delta format, notebooks and ML pipelines can train models on clean, historical ERP data.
Cost and capacity considerations
Two cost centers matter here. The first is storage and compute in Azure or Fabric. ADLS Gen2 storage is inexpensive, but Synapse compute and Fabric capacity (the F SKUs) carry ongoing charges you should size against actual usage. The second is the people time to build and maintain the pipeline.
The trap to avoid is over provisioning capacity before you understand your workload. Start with a smaller Fabric capacity, measure real consumption, and scale up only when the numbers justify it. If you are also weighing the total cost of your Business Central footprint, our guide to puts these analytics costs in wider context.
Common pitfalls and best practices
A few lessons that separate smooth projects from painful ones:
- Export only what you need. Every extra table adds load, storage, and maintenance. Curate deliberately.
- Watch schema changes. When you add fields or new extensions in Business Central, the export configuration and downstream models need updating too. Build a change process for this.
- Protect the source system. Schedule heavy exports for quiet hours and monitor the impact on Business Central performance.
- Govern access. A lake copy of your ERP data is sensitive. Apply proper permissions and, in Fabric, use its built in governance features.
- Document lineage. Keep a clear record of which tables feed which reports, so future changes do not silently break dashboards.
When to bring in a partner
You can absolutely run this yourself, especially the native Fabric path. But if your team lacks Azure or Synapse depth, the data volumes are large, or the analytics are business critical, expert help usually pays for itself in avoided rework. As a Microsoft Dynamics partner, our team can scope the architecture, stand up the pipeline, and hand you a maintainable setup rather than a fragile one.
Frequently asked questions
Is Business Central to Azure Data Lake integration real time? It is near real time in practice. The Microsoft Fabric path with Open Mirroring streams changes continuously into OneLake, giving freshness measured in minutes. The classic Synapse path is typically periodic, such as hourly, though you can tune the interval.
Do I need Microsoft Fabric, or can I use Azure Data Lake Storage directly? Both work. ADLS Gen2 with Synapse and the bc2adls tooling is the established route, while Fabric with OneLake is the newer native option and Microsoft's clear direction of travel. New builds usually favor Fabric.
Does this slow down Business Central? Done correctly, the impact is minimal. Exports are incremental and can be scheduled for off peak hours, and the whole point of the architecture is to move reporting load off the transactional database.
What can I do with the data once it is in the lake? Build Power BI dashboards, blend ERP data with other systems, ground Copilot and AI features, and train machine learning models, all without touching the live ERP.
How long does setup take? A focused native Fabric setup can be stood up in days for a scoped set of tables. Larger Synapse based platforms with heavy transformation logic take longer and benefit from experienced help.
Final thoughts
Connecting Business Central to an Azure Data Lake turns your ERP from a system of record into a genuine source of insight. The Synapse and Fabric paths both deliver a clean, separate analytics copy of your data, and the native Fabric approach with OneLake makes near real time reporting more achievable than ever. Start by scoping the tables that matter, choose the path that fits your existing investments, and build the consumption layer your teams will actually use. Do that, and your reporting stops fighting your operations and starts driving better decisions.