Business Central's Fabric Mirror Is a Second Set of Numbers. Someone Has to Sign Off Both.

What Microsoft has actually documented

Data mirroring connects Business Central online to an open mirrored database in Microsoft Fabric. An administrator picks companies and tables, Business Central sends an initial snapshot and then ongoing changes, and the data lands in OneLake as Delta Parquet for Power BI and the rest of the Fabric stack to read without calling Business Central APIs.

The operational detail is in the management article, worth reading before anyone demos this to a client. You can select up to 1,000 tables, of which the shipped MS-STD package preselects 256. Minutes Between Exports sets the sync interval. Max Consecutive Failed Runs accepts 1 to 5 and defaults to 2, after which synchronisation stops.

One behaviour deserves flagging before a go-live weekend rather than during one: Reset is destructive. It cancels in-flight work, removes the tenant's mirroring resources, resets every watermark and deletes the sync summary and detail records.

Two Microsoft pages, two preview dates

Both Business Central documentation pages are marked prerelease and say the feature is planned to become a production-ready preview in October 2026, subject to supplemental terms.

The Message Center and roadmap entry, RM574126, published on 20 October 2026, says something different. Status: in development. Preview: November CY2026. General availability: April CY2027.

These are differently scoped rather than contradictory, and the distinction matters because the secondary coverage has mostly collapsed it into "Business Central now connects to Fabric". It does not, yet. A production-ready preview carries supplemental terms rather than your normal support agreement. Announcement dates and shipping dates diverge routinely here, which is the same trap as the retirement of the twice-yearly release wave model, widely reported as a change to Business Central's update cadence when it was not. April 2027 is the date to plan a client's reporting cutover around.

The limits page points somewhere else

Here is the detail that should stop you promising a client a column list. For limitations, the Business Central article refers readers to Fabric's page on limitations in mirrored databases from Azure SQL Database. But Business Central writes into an open mirrored database, a different ingestion path, and open mirroring documents its constraints separately.

So the authoritative limit list for a Business Central mirror is not settled in the documentation yet. The Azure SQL page is still instructive about the shape of the risk: any DDL change on a mirrored table reseeds it; several column types are not mirrored at all, including xml, text and ntext, rowversion, sql_variant, geometry and computed columns; seven-digit datetime precision is lost to Delta Lake's six; and large object columns over 1 MB are truncated.

Treat those as questions for a sandbox, not facts about your tenant. The safe conclusion is narrow: some columns may not arrive, and the documentation does not yet tell you which.

A mirror is a second set of numbers

Most reporting an implementation team has tested had one property that made it safe: the report queried the system. If a number was wrong, it was wrong in Business Central, and that is where you went to find out why.

A mirror breaks that. The Fabric copy is read-only through the SQL analytics endpoint, so it cannot corrupt the ledger, which is exactly why it feels low risk. The risk is not corruption but divergence: from the first sync, a client's month-end figure exists in two places that can disagree without either being broken, and the one the finance director opens on Monday is usually the Power BI report.

Reconciliation between Business Central and its mirror is therefore a test script with an expected result, not an assumption. Your UAT sign-off record now needs to say which surface each report was signed off against.

The failure modes that look like success

Stale data renders identically to current data. A report built on a mirror that stopped syncing on Thursday shows Thursday's numbers in a clean dashboard with no error on it. With Max Consecutive Failed Runs defaulting to 2, two consecutive failures reach that state, and nothing in the report will mention it.

A missing column is worse, because a sum over partially mirrored data still returns a number. And if a DDL change reseeds the affected table, every release touching a mirrored table extension carries a data movement consequence — a line item for the regression plan, alongside the table extension storage changes landing in BC29.

What to put in the next cycle

A field-level arrival check. List the fields the client's reports depend on, not the tables, and confirm each arrived in OneLake with the value and precision the report assumes. A table count will not catch an unmirrored column type.

A reconciliation script with a tolerance and a timestamp. One agreed figure, read in both places, with the acceptable lag written down. If nobody will state a tolerance, the mirror is not ready to sign off against.

A deliberate sync failure. Stop synchronisation and confirm somebody is told. If the only way to notice is opening the monitoring page in Business Central, the client has a monitoring gap.

A named owner for the table list. Which tables a client mirrors is a scope decision with a cost and a sign-off, and the sort of thing that quietly becomes nobody's job across a portfolio of concurrent implementations.