Business Central Data Migration: What Crosses From NAV, and What Shouldn’t
In a NAV to Business Central migration, data only crosses into tables that exist on both sides with the same shape. Microsoft says it plainly: data from tables with code customizations can’t be carried forward unless those customizations are handled by extensions installed on both the on-premises and the online side. So the data project and the code project are two projects, and the second one decides what the first one is allowed to move.
That has a budget consequence most migration plans miss. You cannot estimate the data work until you know which customizations survive as extensions, and the data work does not end at go-live.
What does Microsoft’s tooling actually move from NAV?
There is no direct jump from NAV to Business Central online. Both documented paths start the same way: upgrade NAV to Business Central version 14 on-premises.
Full migration. Convert every C/AL customization to AL extensions, upgrade on-premises to at least version 25, then run the cloud migration. Everything that has a matching table online can come across, history included.
Reimplementation. Use the Business Central 14 reimplementation tool, currently in preview, which skips the extension conversion and the on-premises upgrade beyond 14. It moves master data, open documents, opening balances, setup, and a defined subset of posted history. Legacy customizations and their data stay behind, unless you extend the tool for specific custom tables.
Whichever path you take, the cloud migration engine works table by table and tracks success or failure per table. A table fails if it can’t be found online or if its schema doesn’t match; the error is logged and the run moves on to the next table. A run that finishes is not a run where everything arrived.
Some things never cross, by design: most system tables, users, and permissions. Plan to rebuild security in the cloud, not to inherit it. Record links and notes are a separate case: they wait in a buffer table during replication and only reach the real table when you run the Migrate Record Links and Notes action on the Cloud Migration Management page, before you define user mappings.
Why can’t the data land before the code?
Because the landing spots are code. Every custom table and every field you added to a standard table in NAV is, in Business Central, an object in an extension. If that object is not installed online, the data has nowhere to go.
Here is what that surface looks like on a real NAV code base we migrated to Business Central SaaS and still maintain, across all the apps of the solution (1,037 committed .al files):
- 164 custom tables carrying 2,787 fields;
- 74 table extensions adding 1,545 fields to existing tables;
- one standard table extended by eleven separate table extensions.
That is the surface the solution declares today, about 4,300 fields, not a count of what existed in NAV: some of those fields and tables were added after go-live, and a few objects exist only to serve the upgrade itself. But every one of them that already existed in NAV is a place where NAV data either lands or gets lost, and none of them exists in Business Central until someone has converted, compiled, and installed the extension that declares it. That is why the Microsoft customization guide, as its second step, right after the inventory, asks you to separate data-carrying customizations (custom tables, added fields) from behavior-only ones (page layouts, report logic). The first group gates the data migration. The second group does not.
What changed moving that code base from Dynamics NAV to Business Central, from the C/AL syntax to the .NET dependencies, is a story of its own. For the data, the only question is simpler: is every field that holds something you need covered by an installed extension, with the same shape on both sides?
Which extension settings decide whether data replicates?
Two conditions, both documented. The extension must be installed in the online environment, and its ReplicateData property must be true. True is the default, so most installed extensions replicate without anyone deciding it.
The traps sit in the mismatches. An extension installed online but not on-premises produces warnings, and its related tables don’t migrate. An extension that extends a base table can make that base table look empty online; Microsoft provides a Repair Companion Table Records action on the Cloud Migration Management page for that case, and recommends comparing record counts on-premises between the base table and its extension.
None of this is visible in a project plan written in phases. It is visible in a list of tables with a status column, which is exactly what the Cloud Migration Management page gives you. Read that list table by table after every dry run, not the overall status.
What shouldn’t cross at all?
Microsoft’s own preparation guidance is to use the migration to reduce technical debt: archive obsolete history, shrink oversized transaction and log tables, check that schema changes are intentional. The engine will happily move everything you point it at, within storage limits (80 GB by default per tenant, plus allowances per licensed user and any extra capacity bought).
The useful question is per table, not per database: will anyone in the new system read this, and does the new system need it to compute something? A custom log table that served an integration you are retiring answers no twice. Its extension doesn’t need to exist online, and its data doesn’t need to cross. Converting it anyway means converting, testing, and maintaining an object for data nobody will open.
The reimplementation path makes this choice for you, and makes it brutally: it brings the essentials and leaves the rest. The full path leaves the choice to you, which is better only if someone actually makes it.
How many companies, and in what order?
For multi-entity groups, the company dimension matters as much as the table one. The cloud migration is optimized for batches of up to 10 companies; past 250 companies, Microsoft recommends planning smaller batches. Per-database tables are always migrated, whichever companies you select.
The rule that matters most for a group: move all companies before going live. Microsoft warns that moving companies into a live tenant can lead to data loss in the companies already live. A plan that brings subsidiaries over one by one, after the first goes live, is fighting the tool.
Migration runs can be repeated. The first run moves everything and takes the longest; later runs move only what changed. If people keep working in the on-premises system, you need at least one more run before transacting online.
Does the data work stop at go-live?
No, and that is the part almost nobody budgets. On the same code base, the solution’s upgrade folders hold twelve codeunits whose only job is to reshape data that is already in Business Central. Some run through the upgrade engine when a new version is installed; others run as job queue entries, launched once another table they depend on is in place. Three patterns cover most of them.
Backfilling a field that didn’t exist. A new field is added to lines that already exist. The migration replays the same lookup the live code now uses, but only for records from a cutoff date forward and only for the relevant part of the business. Not all history gets reshaped. That is a decision, made in code.
Correcting what old logic stored. A date was stored as the posting date where the document date was meant. The fix in the live code is one change; the existing rows still carry the wrong value. The migration recomputes each one from the posted document and skips rows that are already right.
Re-keying a table. An old table is replaced by a new one with a different primary key, resolved through another table. The migration can only run after that other table is synchronized, so it runs as a job queue entry with a parameter, not as upgrade code. It is idempotent: records already migrated are skipped, so it can run again safely.
How we keep those migrations from silently not running is covered in our discipline for Business Central extension upgrades. Here, two details matter for anyone budgeting data work.
How do you avoid losing records quietly?
The re-keying migration does something the cloud migration engine doesn’t do for you at record level: it refuses to finish quietly. Each record is migrated inside a try function. Failures are collected, the first 100 are listed, the rest are counted, and the run ends with one error that names them. A record that couldn’t be matched becomes a line in a report, not a gap someone discovers at month end.
The loops over large tables commit in batches, typically every 1,000 records, so one long transaction doesn’t hold locks across the whole table. Even there, read the code and not the comment: in one migration the comment says 1,000 and the code commits every 10.
The second detail is smaller and more common. In March 2026, a generic routine that converts incoming text into typed field values was raising runtime errors whenever the source text was longer than the target field. The fix is one line: cut the value to the field’s length. It keeps the import running. It also cuts data. Every migration has dozens of these choices between failing and truncating, and each one should be made on purpose, by someone who knows which field it is.
How should you budget the data side?
As its own project, sized from the field list, not from the table count or the database size. The Dynamics NAV to Business Central migration scope we work on starts from which customizations carry data, because that list sets the order of everything else: what gets converted first, what gets tested with real data first, and what can simply be left behind.
If you are instructing a migration budget and the data line is a single figure with no table list behind it, the clarity form is the shortest way to put the question to us.
FAQ
Can I migrate from Dynamics NAV directly to Business Central online?
No. Both documented paths start by upgrading NAV to Business Central version 14 on-premises. From there you either run a full migration, after upgrading to at least version 25, or use the Business Central 14 reimplementation tool.
Are users and permissions migrated?
No. The cloud migration does not migrate most system tables, users, or permissions. Security has to be set up again online. Record links and notes are kept in a buffer table during replication; run the Migrate Record Links and Notes action before defining user mappings to move them into the real table.
What happens to a custom field if its extension isn’t installed online?
Its data doesn’t migrate. Extension data only replicates when the extension is installed in the online environment and its ReplicateData property is true, and a table whose schema doesn’t match fails while the run continues.
When is the Business Central 14 reimplementation tool the better choice?
When converting customizations to extensions isn’t practical, you can work with a tool that is currently in preview, and you accept starting with master data, open documents, opening balances, setup, and a defined subset of posted history. Legacy customizations and their data are not carried over unless you extend the tool.