Dynamics NAV to Business Central Across 6 Legal Entities for a 1,600-employee Logistics Group
A freight and contract logistics group ran Dynamics NAV 2016 on separate databases per country, with a consolidation that took two weeks. We staged the mandatory version hops, converted C/AL to AL extensions, and cut over 6 companies in one weekend.
About the Client
The Challenge
Every month the finance team exported a trial balance from each of 6 separate NAV databases, pasted them into a workbook, and spent days chasing the difference. Intercompany charges — fuel recharges, shared warehouse costs, cross-border linehaul — were raised as sales invoices in one company and keyed by hand as purchase invoices in the other, usually in a different period. Nobody trusted the group numbers until week three.
The root cause was structural. Dynamics NAV 2016 had been installed one country at a time over 3 years, each rollout copying the previous database and then diverging. Charts of accounts differed, posting groups were named inconsistently, dimensions existed in two companies and not the others, and there was no intercompany partner setup at all, so the manual process had hardened into policy.
On top of that sat 740 modified objects. Some were genuine logistics requirements: consignment tracking on sales orders, a fuel surcharge calculation, a rate card lookup. Most were not. Three report modifications produced the same aged debtors listing in different column orders, an item journal change had been dead code since 2014, and nobody could explain the Codeunit 1 change. Because these were base application changes, every cumulative update had been skipped for years.
The trigger was end of support. NAV 2016 was past mainstream support, the SQL Server under it was approaching the same cliff, and the hosting contract was up for renewal. The brief: Business Central online, keeping only the logistics functionality that earned its place.
Our Approach
A NAV migration of this age is two projects wearing one name: a technical database upgrade and a functional re-design. We ran them in that order, and would not start the second until the first produced a clean trial balance.
Version Path and Customisation Triage (Weeks 1-4)
No NAV version cloud-migrates directly. Every NAV customer lands on Business Central on-premises first, so a NAV-to-cloud programme is always at least two projects. The chain is longer than most collateral admits: since the 2025 release wave 1 version, direct upgrade from v14 is no longer supported and v25 is a mandatory intermediate hop. NAV 2015 through 2018 and BC v13 route through v14, then v25. We planned against v25 or later as the on-premises source, and flagged the documentation conflict — the cloud migration FAQ still names v15 and later — before anyone committed to a date. Each hop runs its own schema synchronisation and data upgrade codeunits. In parallel, 740 modified objects went through a four-way triage: now standard, keep as an extension, replace with an AppSource app, or drop. Half were dropped because nobody could name a user.
Staged Database Upgrade (Weeks 3-8)
Ran the version hops against production copies until the sequence was repeatable, reconciling each one on three controls: trial balance, customer and vendor ledger totals, and item ledger quantity and value.
C/AL to AL Conversion (Weeks 6-14)
The txt2al tool rewrites C/AL syntax as AL and nothing more. The conversion is syntactic, not semantic: it produces something that nearly compiles, not something that works. Assembly version attributes had to be stripped by hand and the ten legacy debugger objects deleted outright. Everything touching the base application was re-expressed against published events and table extensions, because online permits no base app changes. We kept C/AL as the source of truth and re-ran the conversion as the legacy system changed, rather than converting once and forking. Four categories did not convert at all: .NET interop, direct file system access, a COM call into a legacy rating engine, and RDLC layouts bound to dataset columns that no longer exist. 740 objects became 11 extensions.
Group Design, Data and Dry Runs (Weeks 12-20)
Rebuilt the group as one environment holding all companies, on a harmonised chart of accounts and a dimension design fixed inside the platform's two global and eight shortcut dimensions. Intercompany partners, an intercompany chart of accounts and intercompany dimensions replaced the manual recharge process, so a sales invoice raised in one company lands in the other's inbox as a draft purchase document. Replication ran in batches of ten companies or fewer, under the 30 GB per run Microsoft recommends. Two things sat outside the tool: users and permissions do not replicate, and data in code-customised tables only moves once that customisation is an extension — which makes the AL conversion a prerequisite for data completeness, not a parallel workstream. Master data moved through configuration packages across three dry runs.
Cutover Weekend and Hypercare (Weeks 20-24)
The cutover ran to a timed script: stop posting in NAV, clear the document queues, run the final delta replication, execute the data upgrade, reconcile the three control totals per company, post opening balances, verify number series continuity, release posting rights. 52 hours from stop to release. Job queue entries stayed disabled until the first day's postings were checked by hand, with hypercare through month-end for 340 users.
Solution Architecture
Environment: One production environment holding all 6 companies, with a sandbox refreshed from production for change testing
Customisation model: Per-tenant AL extensions subscribing to published events, with table extensions for added fields. No base application changes, so updates apply on schedule. Built with our Business Central consulting team
Intercompany: Intercompany partners, chart of accounts and dimensions, with documents flowing through inbox and outbox rather than being rekeyed
Consolidation: A consolidation company pulling each entity as a business unit, average rate for the income statement and closing rate for the balance sheet
Reporting: Financial reports on the harmonised dimension set, with Power BI reading through the standard API
Results
Client identity withheld under confidentiality. Figures are representative of engagements of this scope.
Technologies Used
Key Takeaways
If your organization is facing a similar challenge, here's what we learned:
Check the supported path this year, not the one in the old blog post. Direct upgrade from v14 stopped being supported at the 2025 release wave 1 version, so v25 is a compulsory hop that much partner collateral still omits. Budget the hops rather than discovering them in week six.
Triage customisations before you convert them, not after. Converting C/AL to AL costs the same whether the code is used or not. The cheapest object to migrate is the one you delete. Ask who uses each modification; accept silence as an answer.
txt2al gives you syntax, not an extension. .NET interop, file system access, COM automation and base application changes do not survive the move online. Those four categories are rebuild work, not conversion work — find them in week one.
Reconcile inventory value, not just the trial balance. A data upgrade that balances the general ledger can still corrupt item ledger costing. Check quantity and value at every hop, or find out at the first stock count.
Harmonise the chart of accounts during the migration or never. Once entities are live with divergent accounts and dimensions, fixing them means reposting history. Do it while the data is already moving — our Dynamics 365 consulting practice treats it as cutover work.
Still Running Dynamics NAV?
Every year on an unsupported version adds a hop to the path and another modification to convert. We scope the real path and the real customisation inventory before anyone commits to a date.