// article
A Dynamics NAV migration is not a code-conversion project with a cloud deployment at the end. It is a business-process redesign, data migration, application upgrade, and extension-architecture program. Carrying every historical customization forward can reproduce years of complexity in a platform designed around standard application code plus AL extensions.
The useful question for each customization is not "how do we convert it?" It is "does the target business still need this outcome, and what is the cleanest supported way to provide it now?"
Microsoft's current Business Central upgrade documentation explains that C/AL was replaced by AL and the application is extension-based. The exact intermediate versions required depend on the NAV or Business Central starting version and the current target release. Microsoft also documents that the route to Business Central online runs through on-premises Business Central: upgrade the solution to Business Central Spring 2019 (version 14) or later, convert non-standard functionality to apps and per-tenant extensions, then run the cloud migration tool.
Do not hard-code an old version path into a multimonth plan. Recheck the current compatibility matrix and cloud-migration prerequisites when the project starts and before each rehearsal.
Inventory modified objects, add-ons, reports, integrations, job queues, automation, permissions, control add-ins, external files, and data stored in custom tables or fields. Map each technical item to a business owner, actual usage, compliance need, and operational dependency.
Usage evidence matters. A modified report that nobody has run for two years should not receive the same treatment as a posting rule required by contract.
| Decision | Use it when | Target |
|---|---|---|
| Retire | The process is unused, duplicated, or no longer required | No replacement; archive documentation/data as required |
| Adopt standard | Current Business Central now provides the outcome | Configuration, training, and process change |
| Replace | A supported Microsoft or Marketplace app meets the need | App evaluation, data conversion, and support contract |
| Rebuild | The requirement is differentiating and not covered safely | Customer-owned AL extension or integration |
| Defer | Value is uncertain and the first go-live can operate without it | Prioritized post-go-live backlog with an owner |
Direct base-application modifications do not move into Business Central online. Required logic must use supported AL objects and extensibility points: table/page/report extensions, events, APIs, permission sets, and upgrade code. If a required event is missing, redesign the boundary or pursue the supported contribution/event-request path instead of recreating a fork.
Separate shared product behavior from customer-specific code. Declare dependencies and minimum versions explicitly. Use access modifiers and interfaces to keep the public surface small enough to evolve.
Microsoft's cloud migration can transfer data from customization extensions when requirements are met, but custom fields and tables require aligned schemas and, in some cases, migration table mappings. Users and permissions are not simply copied into the online tenant, and some system-linked data needs separate treatment. Microsoft also states that data from tables with code customizations cannot be carried forward from Dynamics NAV, so those tables need a conversion decision before replication rather than after it.
For each custom dataset, define:
A technical data copy is not a rehearsal. Run the sequence from source freeze through replication, data upgrade, extension installation, permissions, integrations, reports, user acceptance, reconciliation, and go/no-go decision. Time every step and record manual interventions.
Repeat until the team can meet the downtime window and explain how to recover from a failed stage. The on-premises system remains authoritative until cutover; after final migration, users must stop entering transactions there.
Validate custom extensions against preview environments, monitor upgrade and performance telemetry, and keep the retired/rebuilt inventory as permanent architecture documentation. A successful migration is one that can accept the next Business Central update without restarting the modernization project.
Bitta Apps can lead a NAV customization assessment, rebuild approved gaps through AL development, execute Business Central implementation and migration, and own the stabilization period through managed support.