A NAV upgrade is not an upgrade; it is a conversion of C/AL modifications into AL extensions, and then a data migration. How to inventory the customisations, what txt2al does and does not do, the "retire, replace, rebuild" sort, the version 14 stepping stone, and the sequence that gets a heavily modified NAV 2013 onto Business Central online.
The history post explains why: NAV customers are on a fork of the base application, and Business Central online runs one code base. So the "upgrade" is really three projects: convert the code, migrate the data, re-implement what the business actually needs. This is the code one.
Export all objects from the NAV database as text and diff them against a clean copy of the same version (the partner should have one; Microsoft's DVD objects). The diff is the customisation. Classify every change: a new object, a modified base object, a new field on a base table, a modified report. Count them. A typical mid-sized NAV 2013 system has 200 to 800 changed objects, and the number sets the project's size more than anything else.
Every item in the inventory gets one of three labels, with the business owner in the room (the fit-gap post is the method):
Microsoft's txt2al converts exported C/AL text to AL files: objects become AL objects, modified base objects become table/page extensions with the delta. It is a mechanical start, not a result: it produces code that compiles against the version it was exported from (14), with the old patterns (direct SQL-era loops, no events, modified base procedures turned into copies), and it cannot convert a modification inside a base codeunit into an event subscription; that is design work. Use it for the "rebuild" pile as a reference, and write the extension properly.
For a heavily modified system, the supported path is: technical upgrade of the NAV database to Business Central version 14 (the last with C/AL), so the data is on a modern schema; convert the rebuilt customisations to extensions and install them on 14 alongside the remaining C/AL; then upgrade 14 to the current version, where only extensions survive; then cloud-migrate to online if that is the destination. Each step is testable. For a lightly modified system, or where history is not needed, skip all of it: fresh implementation on the current version, opening balances migrated, NAV kept read-only.
Custom fields on base tables carry data. Their new home is a table extension with the same field IDs (txt2al keeps them), so the upgrade carries the data across in the 14-to-current step. Custom tables likewise. If you renumber or restructure in the rebuild, you need an upgrade codeunit to move it.
Inventory and sort: two to four weeks. Rebuild of the kept quarter: the development phase, sized by the count. Technical upgrade and data: a few days per rehearsal, rehearsed twice. The whole is a normal implementation with a conversion in the middle; budget it as one (costs), and do not let anyone call it an upgrade in the project plan, because the business will expect an afternoon.
