Upgrading NAV customizations to Business Central: standard first, extensions second

Most companies still running Dynamics NAV have years of customizations built into it: extra fields, modified posting routines, custom reports, integrations nobody fully remembers. Moving to Business Central forces a question NAV never asked: what do we do with each of them?

In NAV, customizations were usually made by changing the base application's code directly (C/AL, in the base objects). Business Central works differently: your changes live in extensions, written in AL, which sit on top of the base application instead of modifying it. On Business Central online, modifying the base application isn't an option at all.

So an upgrade isn't just moving data to a new version. It's a review of every customization. Here's how I approach it.

1. Make the list

Before any code, list every customization: what it does, who uses it, and whether anyone would notice if it disappeared. You'll be surprised how many exist for a process the business stopped following years ago.

2. Standard first

For each customization, the first question is: does Business Central do this out of the box now?

Business Central has gained a lot of functionality since the NAV versions most companies are upgrading from. A customization written years ago to fill a gap may now be covered by a standard feature. When it is, I'd always choose the standard feature:

• less work now: nothing to rewrite;
• less maintenance later: Microsoft updates it, tests it, and keeps it working across releases;
• fewer surprises: every Business Central partner and user knows the standard behaviour.

Sometimes the standard feature works a little differently from the old customization. It's usually worth adapting the process to the standard rather than rebuilding the old one.

3. Rewrite what's left as AL extensions

What standard Business Central doesn't cover gets rewritten as an AL extension. The key shift is from modifying code to extending it:

• Fields on standard tables become table extensions.
• Screen changes become page extensions.
• Logic changes become event subscribers: instead of editing a posting routine, you subscribe to the events it raises before and after its key steps.
• New functionality gets its own tables, pages, codeunits and reports.

There are tools that convert old C/AL code to AL syntax (Microsoft's Txt2Al converter, for example), and they help with the mechanical part. But converted code that modified base objects still needs to be redesigned around events, and that part is real work. If the event you need doesn't exist, Microsoft accepts requests for new events; in the meantime there's usually another way in.

4. Move the data

Customizations come with data: the values in those extra fields, the records in custom tables. They have to land in the new extension's tables. Microsoft provides upgrade tooling and a cloud migration path for moving to Business Central online; which route fits depends on the version you're coming from and whether you're going online or on-premises, so check Microsoft's current documentation for your case before planning this step.

5. Test, and then test again

This is where the time goes. Testing was, by far, the hardest part of these projects.

Every customization that was rewritten, and every one replaced by a standard feature, has to be checked against how people actually work: the real documents they post, the real reports they print, the edge cases only one person in accounting knows about. A few things help:

• Test with real data, copied from production, not with a clean demo company.
• Have the people who do the work do the testing. They know the edge cases you don't.
• Write down what "correct" looks like before testing: the totals a report should produce, the entries a posting should create.
• Automate what you can. Business Central has a test framework for AL, and a few automated tests on the critical routines pay for themselves on the next upgrade.

6. Back up everything, and start small

If there's one piece of advice I'd give a company about to do this: back up everything, and start small.

• Keep full backups of the NAV database and of every step along the way, so you can always go back.
• Don't move everything at once. Start with one company, one module, or one group of users. Learn from that, fix what breaks, then expand.
• Plan for the old system to stay available, read-only, for a while after the switch. Someone will need to look something up.

The payoff

Done this way, the upgrade leaves you with fewer customizations than you started with, each one written as an extension that survives Business Central's regular updates. That's the real benefit: not the new version, but never having to go through a painful upgrade like this again.

Planning a NAV upgrade? Let's talk.