What typically moves, and what does not
A Business Central migration needs a scope decision about history, and it is usually made on sound engineering grounds. What generally comes across:
- ✓Master data. Customers, vendors, items, the chart of accounts.
- ✓Open transactions. Outstanding receivables and payables, open orders.
- ✓A window of posted history. Commonly the current and prior fiscal year, sometimes two to three years, as balances and closed entries.
What generally does not:
- ✓Older posted documents. Beyond the agreed retention window.
- ✓Change logs and audit trails. Rarely worth the migration cost, frequently wanted later.
- ✓Data from add-ons being retired. If the ISV product is not coming to Business Central, its tables have nowhere to land.
- ✓Custom tables. These need matching AL extensions built in Business Central before anything can be loaded into them, which is often not justified for history alone.
There is a good reason for all of this. Pushing a full NAV history into Business Central inflates storage, slows the migration, and clutters reporting and audit work in the system your team now uses every day.
The gap this leaves
The engineering decision is right. The consequence still needs handling: Business Central cannot answer questions about data that was never loaded into it, and those questions keep arriving for years after go-live.
In practice the requests are always the same shape — a specific record, from a specific period, needed quickly, usually by someone who never used NAV:
- ✓The annual audit. A date range, a customer, and the supporting documents behind the numbers.
- ✓A tax review. Transaction-level detail from before the migration.
- ✓A customer dispute. One order from 2017, with its terms and its lines.
- ✓A new finance hire. Who has to answer a historical question and has never seen a NAV screen.
Where the rest of the history can live
Four homes are commonly proposed. They are not equally good, and the difference only shows up later:
| Option | What it costs to keep | What a non-technical person can do with it |
|---|---|---|
| A dormant NAV VM, read-only | Windows Server, SQL Server, the VM, backups, and an unpatched system that ages | Everything — if they have NAV access and know NAV |
| A SQL backup on a shelf | Almost nothing | Nothing. It has to be restored by someone technical before a single question can be answered |
| A database copy in Azure | A monthly cloud bill, indefinitely | Write SQL, or nothing |
| A purpose-built archive | One-time, then storage | Search by name and number, open the document, export it |
The distinction that matters is not storage. It is whether the person who receives the auditor's email in 2031 can answer it without a technical project.
Timing: extract before cutover, not after
This is the part that is genuinely hard to fix later. Preserve the history while NAV is still running and still verifiable:
- ✓Extract during the migration, not after it. A rehearsal extract while NAV is live lets the team inspect values, settle questions and agree what is in scope, with the source still available to check against.
- ✓Run the final extract from the frozen cutover state. The same state the migration itself was taken from, so the two data sets line up at a known boundary.
- ✓Reconcile against NAV account by account. Totals should tie before anything is switched off. Once NAV is gone, there is nothing left to compare against.
- ✓Decommission last. Run both in parallel for an agreed period, and retire the server only after someone has signed off that the history is complete.
Dates and what actually stops working are in Dynamics NAV end of life. The options above are compared in more detail in ways to keep NAV history.