If your company runs Dynamics NAV, the code that makes it yours is probably the part you worry about most. Years of modifications to posting routines, extra fields, custom reports and integrations. The good news is that almost all of it can be carried into Business Central. The catch is that it can’t be carried over as it is.
This article explains why, and how an upgrade project decides what happens to each customisation.
Why C/AL code can’t move across unchanged
In NAV, developers customised the system by editing Microsoft’s own objects in the C/SIDE development environment, using the C/AL language. A change to the sales posting routine meant changing Microsoft’s sales posting codeunit directly.
Business Central works differently. Since Business Central version 15 (the 2019 release wave 2), C/SIDE is gone and all development happens in AL, in Visual Studio Code. Customisations are delivered as extensions: separate apps that add to the standard system instead of rewriting it. They plug in through:
- Table and page extensions for new fields, actions and page changes
- Event subscribers that run your logic when something happens in standard code, such as a document being posted
- New objects of your own: tables, pages, codeunits, reports and APIs
Business Central online goes further: you can’t modify the base application at all. Everything custom has to be an extension.
That is also the main benefit. Because extensions sit beside Microsoft’s code instead of inside it, monthly updates and twice-yearly release waves install without overwriting your changes.
Sorting your customisations into four groups
The first real step of an upgrade is an inventory of every modified object. Each customisation then lands in one of four groups.
1. No longer needed. Business Central has gained a lot of standard functionality since older NAV versions. Some customisations were built to fill gaps that no longer exist, and some support processes the business stopped using years ago. These are simply dropped, which is often the cheapest part of the project.
2. Replaced by standard features or settings. Some modifications can be replaced by standard configuration, a standard report layout, or a feature that now exists out of the box. These need a decision from the business, not code.
3. Rebuilt as extensions. Most genuine business logic falls here. New fields become table extensions. Changes to posting become event subscribers. Custom documents become reports with Word or RDLC layouts. The behaviour stays the same; the structure changes.
4. Redesigned. A few customisations change standard code so deeply that there’s no clean event to hook into. These are redesigned around the extension model. Where Business Central is missing an event that would make a clean solution possible, Microsoft accepts requests for new events through its public extensibility process on GitHub.
What happens to your data
Custom fields don’t disappear when the code changes. During the upgrade, data in custom fields and tables is moved into the matching table extensions and new tables, so history stays intact.
Older versions usually can’t jump straight to the current release. Very old databases, such as NAV 5.0 or NAV 2009, typically pass through one or more intermediate versions before reaching current Business Central. That sounds alarming but is routine: the steps are scripted and repeated on test copies until they run cleanly.
If you’re moving to Business Central online, the final step uses Microsoft’s cloud migration tooling to bring the on-premises data into your online environment.
Reports and integrations
Reports written for the old client are converted or rebuilt as Business Central reports. This is a good moment to move document layouts to Word, so finance and sales staff can adjust wording and branding without a developer.
Integrations built on file exports or older web service setups are usually rebuilt on Business Central’s REST and OData APIs. That tends to make them more reliable, and it opens the door to tools like Power BI and Power Automate.
How to keep the project under control
- Start with the inventory. You can’t estimate an upgrade honestly until every customisation is listed and grouped.
- Challenge every customisation. Each one you drop saves build and test time now and maintenance later.
- Test with real processes. Run your actual daily work in a sandbox copy, not just a checklist of screens.
- Plan the cutover. Pick a quiet period, rehearse the data migration, and agree who signs off before go-live.
Thinking about an upgrade?
Dynorbit has delivered more than 15 NAV and C5 upgrade and migration projects, from NAV 5.0 onward. If you’d like a straight answer on what your upgrade would involve, see our NAV to Business Central upgrade service or book a free call.