From Business Central to Fabric: the medallion architecture blueprint

Bronze, Silver, Gold: how the medallion architecture turns raw Business Central data into Fabric-ready analytics, and when Fabric is the right call at all.

Why Business Central needs a medallion, not just a mirror

Many Business Central customers still treat Fabric as a mirror: point Power BI at BC, copy the data across, call it done. The results are usually messy joins, inconsistent naming, and reports that quietly drift apart from each other within months. A medallion architecture, Bronze, Silver, Gold, treats that copy as the start of the job rather than the end of it. Each layer earns its place.

Bronze: the raw copy of BC

Bronze is the landing zone: BC’s data extracted and stored exactly as BC represents it internally, before any transformation. It looks unfamiliar to anyone outside the BC team, full of internal codes and table structures built for transaction processing rather than reporting. That’s fine, Bronze isn’t meant to be queried directly by end users. It exists so nothing is lost and everything downstream has a dependable source to rebuild from.

Silver: where BC actually gets cleaned up

Silver is where the real engineering work happens. Item ledger entries get joined to items, customer ledger entries to customers. Internal codes are resolved into descriptions a finance director would recognise. Dates are normalised, currencies converted where the business reports in a single currency, and history reconciled across the BC version changes that happen over a multi-year deployment. Skipping this layer is the most common mistake we see: it feels faster to jump straight from raw BC data to a report, until the second report defines “customer” slightly differently to the first.

Gold: the certified, business-ready layer

Gold is business-ready facts and dimensions: a Sales Fact table with one row per transaction at a proper, consistent grain, a Customer dimension with the attributes the business actually cares about, a Product dimension, a Date dimension. Each fact and dimension is the certified definition. Power BI semantic models point at Gold, so new reports inherit the same definitions as old ones instead of re-deriving revenue from scratch for the fifth time. Gold is what makes everything above it consistent.

How BC data actually reaches the lakehouse

There are three practical routes in. Microsoft’s Lakehouse Connector is the native option for BC SaaS, running periodic full and incremental loads straight into Fabric. Power Query refresh against BC’s APIs works for smaller volumes or specific entities that don’t need the full connector. And for on-premises BC, or edge cases the connector doesn’t cover, custom extraction via BC’s standard APIs or direct database access fills the gap. Most current BC SaaS implementations lean on the Lakehouse Connector for the bulk of the data and use Power Query to patch specific gaps.

Microsoft has also shipped analytics extensions and connector improvements that make this build smoother. They reduce effort, but they don’t change the underlying decision about whether Fabric is the right architecture in the first place. They just make it cheaper once you’ve decided.

Do you actually need Fabric for this?

Often, no. If a business is BC-only, modest in data volume, and isn’t chasing analytics beyond standard reporting, Power BI direct on BC is genuinely enough, and the integration effort of Fabric won’t pay for itself. The signal that it’s time to build the lakehouse is usually one of three things: a second material data source that needs to sit alongside BC, a data volume problem BC’s own reporting can’t handle gracefully, or a clear ambition to do analytics that goes beyond standard reporting.

Where BC reporting is actually heading

Operational reporting, invoices, statements, the documents BC generates natively, isn’t going anywhere; it stays in Native reporting. Analytical reporting is a different story: that’s shifting to Power BI on Fabric, and the direction is clear even if the timeline varies by business. The reports in between, finance packs, BC-centric analytics, split across Jet, Power BI direct, and Power BI on Fabric depending on the specific case. The realistic long-term picture for most BC estates is two or three reporting tools, each doing the job it’s actually good at, rather than one tool trying to do everything.

SaaS or on-premises: does it change the architecture?

Not fundamentally. Whether BC is SaaS or on-premises, the architecture is the same: extract into a lakehouse, build certified Silver and Gold models, expose them through Power BI. What changes is the extraction mechanism, Lakehouse Connector and BC APIs for SaaS, direct database access or scheduled extracts for on-premises, not the outcome. Most new BC implementations are SaaS-first, but the medallion approach holds regardless of which BC you’re running.

If you’re currently pointing Power BI straight at BC and starting to feel the strain, that’s usually the signal to have this conversation, not a sign you’ve done anything wrong. The FAQs below cover the layer-by-layer detail; if you want to talk through what Bronze, Silver, and Gold would actually look like for your own BC data, that’s exactly the kind of conversation Hopton has regularly.