How do you migrate reporting when moving from Dynamics NAV to Business Central? Keeping the numbers through the upgrade

NAV 2018 support ends in January 2028. How to move reporting to Business Central without losing history, SQL reports or the month end, in one model.

You migrate reporting when moving from Dynamics NAV to Business Central by building one reporting model that reads NAV history and Business Central current data together, replacing the direct SQL queries that NAV reporting relied on with Business Central's APIs or a lake extraction, and running the old and new reports side by side until the first month end closes on the new system. The reason it needs planning is that the two things NAV reporting took for granted, direct access to the SQL database and a stable table layout, both change: Business Central online has no SQL access, and the extension model moves custom fields out of the base tables. With extended support for NAV 2018 ending on 11 January 2028 and NAV 2017 a year earlier, most NAV customers are planning this now. This post sets out what changes, what to keep, and how to do it without losing the numbers.

What changes for reporting

No SQL. NAV reporting in most businesses means SQL views, SSRS, Jet Reports over SQL, or Power BI connected straight to the database. Business Central online exposes data through APIs, OData web services and Power BI connectors, not SQL. Every direct-SQL report needs a new source. Business Central's OData and API pages explained describes the options.

Customisations become extensions. Custom fields and tables that lived in NAV's base objects move to extensions in Business Central, which means they appear under new names in the APIs and need to be exposed deliberately. A reporting migration is the moment to list every custom field a report uses and decide whether it survives.

History stays behind unless you carry it. Most NAV to Business Central migrations bring opening balances and open items, not years of ledger entries. If finance wants five years of trend, the NAV history has to be extracted before the server is switched off and held somewhere the new reports can read it.

The tables you know are mostly still there. The good news is that the data model is recognisably the same: general ledger entries, customer and vendor ledger entries, item ledger entries, dimensions and dimension set entries all carry over, so a model built properly for NAV can be remapped rather than rebuilt.

The pattern: one model over both

The approach that works is a single Power BI semantic model, or a Fabric lakehouse with one on top, that holds NAV history and Business Central current data in the same tables with a source flag. NAV data is extracted once from SQL into the bronze layer before decommissioning. Business Central data arrives through the API, bc2adls or, once Microsoft's announced mirroring reaches preview, directly into OneLake. Silver conforms the two: the same chart of accounts mapping, the same dimension handling, the same customer and item keys. Gold presents one set of facts and dimensions, and the report does not care which system a row came from. We built exactly this for a distribution business moving from NAV to Business Central while retiring QlikView, with no loss of reporting during the move.

The order of work

First, inventory the reports and the fields they use, and retire the ones nobody opens. Second, extract NAV history to the lake while the server is still running, and reconcile it to the trial balance by period. Third, build the conformed silver layer and the gold star schema, and connect Business Central as it goes live, usually in a test company first. Fourth, run old and new side by side for a month end, reconcile, and switch. Fifth, decommission NAV reporting on a date. The whole sequence fits inside a typical Business Central implementation if it starts when the implementation does, and becomes a scramble if it starts at go-live.

Jet, Power BI apps and the other shortcuts

Jet Reports over NAV SQL does not carry across unchanged; Jet Analytics and Cosmos have Business Central versions that provide a pre-built model and are a reasonable route for a single-company business with standard reporting, as our reporting options post sets out. Microsoft's free Power BI apps for Business Central give a fast first set of finance and sales reports after go-live, but they are one company per workspace and know nothing about NAV history. For a group, or for anyone who wants the trend to survive the upgrade, the one-model pattern is the answer, and Business Central analytics in 2026 explains how to choose between the routes.

Where to start

If your NAV to Business Central project has a go-live date, the reporting workstream should start now with the report inventory and the history extraction, because those two tasks depend on the NAV server being available. Our free audit reviews a NAV reporting estate and produces the migration order, and our Business Central analytics page describes the model we build.

Related reading

Business Central to Power BI: the complete guide to reporting beyond the built-in tools

How long does a BI migration take, and how do you keep reporting running meanwhile?

Consolidating multiple Business Central companies in one model