// Source System
Dynamics NAV to Dynamics 365 Data Migration
We've moved Customer, Vendor and G/L Account data out of Dynamics NAV into D365 F&O — cleanly, completely, on time.
DYNAMICS NAV — Entity Mapping
// The Challenge
Why Dynamics NAV migrations are hard.
Dynamics NAV (and Business Central) organises finance around the G/L Account table combined with Dimension Sets, which is conceptually close to D365 F&O's own dimension model — the good news is the mapping is usually more direct than from other legacy systems. The complexity comes from how dimension combinations were used in practice, which often drifts from how they were originally designed.
Customer and Vendor tables carry ledger entries (Cust. Ledger Entry, Vendor Ledger Entry) that hold the open item history — these need to migrate with their application (payment matching) intact, not just as flat balances, or reconciliation will fail immediately after cutover.
Item tables and their associated Item Ledger Entries can carry years of costing history using average, FIFO or standard costing methods, which needs to be reconciled against D365's inventory costing model before the item master moves.
// Mapping
Dynamics NAV entities, mapped to D365.
| Source entity | D365 entity |
|---|---|
| Customer table | CustTable |
| Vendor table | VendTable |
| G/L Account + Dimension Sets | MainAccount + Financial dimensions |
| Cust./Vendor Ledger Entry | CustTrans / VendTrans |
| Item table | InventTable |
// Pitfalls
Where Dynamics NAV migrations go wrong.
- Dimension Sets often drift from their original design over time — audit actual usage before mapping to D365 financial dimensions, not the original design document.
- Ledger Entry application (payment matching) must migrate intact, or AR/AP reconciliation fails immediately after cutover.
- Item costing history (FIFO, average, standard) needs reconciling against D365's costing model before item masters move.
- NAV and Business Central versions differ enough in schema that discovery should confirm the exact version before scoping.
// Domains
Domains we most commonly migrate from Dynamics NAV.
// Methodology
The same six phases, every time.
01
DISCOVER
Profiling, volumes, quality scoring across every source system in scope.
02
DESIGN
Source-to-target mapping and the cleansing plan, agreed before build starts.
03
BUILD
DMF templates, KingswaySoft packages, SQL staging tables.
04
TEST
Two mock migrations, full reconciliation, and UAT sign-off.
05
CUTOVER
Final load, balance reconciliation, go-live clearance.
06
STABILISE
Corrections, closure report, retainer option for what follows.
// FAQ
Questions about migrating from Dynamics NAV.
Yes — the table structures are closely related, though Business Central's extension model can introduce custom fields that need discovery first.
Planning a Dynamics NAV to D365 migration?
Start with a Health Check to see exactly what needs cleansing before it moves.