Three reasons to upgrade from Dynamics NAV to Business Central 14 now

July 16 2020

While you don't need to upgrade your Microsoft Dynamics NAV system now, you really should consider locking in your plans for an upgrade to Dynamics 365 Business Central 14 before it is too late. (Keep reading to find out about the deadline and why you should care!)

I know everyone wants to get to the point in this type of article. The benefits. The bullets. What are the top 3 reasons you promised me, Rob?!

  • First: Testing an upgrade to Business Central 14, as compared to higher versions, will be much less work and much less costly. I like saving money, and so should you!  Why is it cheaper? That’s something I outline later.
  • Second: Business Central 14 is the gateway (literally) to the cloud.
  • Third: You get a 3:1 user boost (converting concurrent to named users) when you switch to Business Central. For 99% of businesses this is a lot of extra users for your Business Central environment. There are some caveats, but usually it’s a fantastic gift if you are even remotely considering adding more users.

This article will explore why the first of these three reasons is so important, and what NAV users should understand about planning an upgrade.

Dynamics NAV upgrades have always been expensive.

My colleagues in the Microsoft Dynamics NAV marketplace look at me as the “young whippersnapper.”  I started with the product for the first time in 2013, and really didn't hit my stride until 2014. Most of them started in the NAV space between 1998 and 2003. I am but a grasshopper compared to the masters.

When I saw NAV for the first time, I discovered something remarkable: the underlying and fatally flawed Dynamics NAV selling feature. You may have heard the adage:

The power of Dynamics NAV is its amazing ability to be customized in any way the customer wishes.

The biggest disadvantage of Dynamics NAV is its amazing ability to be customized in any way the customer wishes.

Before I became involved with NAV I was used to a very different kind of ERP model. The products I worked with could be upgraded in a few hours on a weekend. Mind you, they could not be customized and that caused all kinds of problems, too. Once I discovered NAV and realized that all the customizations we did in it ended easy upgrades, I realized the masters had been living in denial for years.

A reasonably small Dynamics NAV upgrade would cost companies upwards of $30,000. A few hundred thousand for an upgrade isn't unheard of. Why is it so expensive?


C/AL is the reason why it's so expensive.

All versions of NAV were written in a programming language called C/AL and used a programming environment (the software to do the programming) called C-SIDE. C/AL and C-SIDE were pretty awesome at the time of their release in the 90s. A non-programmer could use them to add custom fields, change labels and page designs, build reports, and even put a little code in for calculations. All kinds of cool and useful things.

But, as I already said, it made upgrades painfully expensive.

To upgrade from a customized version of NAV to a new version, a programmer needs to literally move your changed code, one line at a time, from the old version to the new version. There are over a million lines of code in NAV, and you don’t need to check them all, but more than once we have found some orphan code that wasn’t properly documented that caused total chaos for an upgrade.

Programmers have lots of tricks to make all this easier, but it absolutely is as painful as I make it sound. And that causes NAV upgrades to be (often) outrageously expensive.

Business Central 14 is the ideal upgrade path for NAV Customers

And this leads us to Business Central 14 (BC 14) and the current situation.

To understand what Business Central 14 is, it might help to look at the history of Dynamics NAV. Prior to the 2009 version of NAV, all the versions were given numbers:  NAV 1.0, 2.0, 3.0 etc. The last version numbered like this was 5.0. In 2008 Microsoft released Dynamics NAV 2009. This was a fairly radical change from version 5.0 in many ways, but by far the biggest change was the Role Tailored Client.

The last version officially called Dynamics NAV was the 2018 version, which was also called (hidden in the depths of the help screens) version 11.0.

Back to Dynamics NAV 2009. For end users, the practical impact of the Role Tailored Client was that they needed to learn a new user interface. This made the upgrades from NAV 5.0 to 2009 even more painful than the ones in the past. Not only did the developers have to move code “one line at a time” from the old system to a new system, but users had to test this code in a totally new user interface. The look and feel changed radically.

The costs to upgrade to version 2009 made the previously outrageous costs look downright cheap.

The Role Tailored Client ends after Business Central 14

 BC 14 is the last version with the Role Tailored Client. Since all NAV versions up to and including 2018 almost exclusively involve customers using the Role Tailored Client, upgrades between versions only involved customers checking that the “line by line” code transfer didn’t miss anything.

With the upgrade to BC 14, this is still possible.

But upgrading to BC 15 or higher, you would no longer have this benefit. Your users would be testing and confirming the upgrade in a new environment that presents much greater challenges.

All of this should be a call to arms for every NAV partner and customer to plan their upgrade to Business Central 14. The changes introduced in Business Central 15, including the elimination of the Role Tailored Client and other development updates represent the most important shift in Business Central since the product was introduced and the most important to NAV since the change from version 5.0 to 2009.

You have until Sept 25, 2020 to start your upgrade to Business Central 14

This brings me to the point.

There is a window of opportunity that ends about September 25th, 2020 to reserve your space on the Business Central 14 train. After that, you will not be able to request that version.

This does not commit you to completing your upgrade by September 25th. You would have about a year more to complete the transition with no real penalty to you.

My professional opinion is that this will be the most important decision you could make regarding upgrading Dynamics NAV.

How does this impact the cost of a Business Central upgrade?

For customers with any version from NAV 2013 to NAV 2018 written in C/AL: Imagine you have some staff who aren’t the strongest computer people, but they use features you’ve customized in NAV. I would take 10:1 odds that your users could not accurately point out what is “base” NAV compared to customizations. Even if those users were originally involved in designing the customizations it is exceedingly unlikely they could point out more than half of them.

When completing an upgrade of your system, including converting your C/AL code to AL (more on that later), I would suggest the next step would be to give your users a second monitor so they can do a side-by-side of the old NAV vs Business Central.

It would look like this (click image for larger view):

Dynamics NAV to Business Central 14 comparison

Which one is Business Central?  Hint – the one on the left says “Microsoft Dynamics NAV client – connected to Dynamics 365 Business Central.”

For a user who has no idea what is part of base NAV and what is part of their own customizations, these first two screens offer a really easy way for them to check. They can open each screen side by side and compare. They can look for differences. They won’t be distracted by the changes.

If you were to upgrade them to Dynamics 365 Business Central 15 or higher, they would have this for testing (click image for larger view):

Dynamics NAV to Business Central 15 comparison

Is it radically different? Not really – not once you're used to the new system. But your users won't be used to the new system. They've memorized the old system. They have muscle memory that helps them find their action buttons and fields.

Most of the fields and pages and actions are laid out in a similar way. But not exactly the same. Muscle memory won't find the button they want.

If they are not strong computer users, they will report false positives (i.e., bugs). That means they'll report all kinds of testing issues as things for programmers to fix. In reality, many of these are really things that were changed legitimately in the new version. Combine this with the (small but real) risk of an extension not moving all the code over, and you have a significant risk to the cost of your upgrade.

I am all about reducing risk.

False positives still need to be investigated and debugged. The users need to be validated, and there will definitely be additional training and often “proving” that the issue isn't a bug. In addition, the users might get lost in the new look and feel and miss things that are legitimately wrong.

My best guess is this type of challenge will add 25 to 50 percent to the cost of an upgrade, especially for a small or medium business without any internal IT team to help.

Converting “average” NAV customizations to AL

I would describe most NAV customers as having “average” levels of customization complexity. They may have a lot of customizations, but not too many of them are really complicated or radical. The vast majority of this can be moved to the newer AL language fairly easily.

But there are definitely a few things that can’t easily be done in AL – and C/AL might be required to make those customizations work. Luckily, in BC 14 you can have a hybrid environment using both AL and C/AL.  You can leave a small number of things that are “problematic” in C/AL as a bridge or a stop gap while you figure things out. This will mean more costs for the next upgrade, but if you can move the vast majority of your code to AL, then you will have very little to worry about next time.

Some partners are quoting quite a bit more for upgrades that move a NAV customer's customizations from C/AL code to AL. I don't think this should be the case most of the time. If you have reasonably standard Business Central customizations, the tools in the market to transition code are now so good that we believe it might be slightly less work to upgrade C/AL to AL. It's not a huge difference, but AL has some nice features that make programming easier.

AL also has a huge advantage in testing: you can turn it off.

If your users are encountering an issue with Business Central 14 after upgrading, they can turn off an extension briefly. This lets them test the system without custom code. If they still have the problem, it’s most likely data or a user error. It's why we don’t think partners should add much (or any) more time to the project to convert from C/AL to AL. What added time there is can be offset by easier testing.

Highly Customized

This leaves the highly customized customers. The customers that really went to town on their version of NAV and rewrote big parts of Microsoft base code. The earlier reasoning about "average customizations" breaks down with these customers, and we generally think they should be looking at a reimplementation, but that is for another post.

Migrating to Cloud


If you haven’t been hiding under a rock or trapped in a cave-in for the last few years, you’ve heard of the cloud. If you are a user of Microsoft Dynamics NAV (and escaped the cave), you've heard that your path to the cloud leads through Business Central.

Getting your code into AL is a prerequisite to move into the cloud. Business Central 14 is also the “lowest” version of the product that has a “direct to cloud” migration path.


You have about 15 months from today (I’m writing this in July 2020) to make the transition to Business Central and use version 14. But you only have about 3 months to commit to that upgrade (not finish it) and be eligible to move to Business Central 14 as your stepping stone.

As I have outlined, I think using the BC 14 path will minimize upgrade risks and, likely, costs. Your testing will be much easier with BC 14 than it will be with future versions. The ability to “side by side” test your customizations in the Role Tailored Client is critical even if you plan to move to the Modern (web) Client right away. Once your AL extensions are debugged, future upgrades become easy and much, much cheaper.

Finally, there might be the odd customization that will be hard to move to AL. In this case you might want to leave a small amount of customization as C/AL code.  This will give you and Microsoft time to figure out how you will upgrade in the future. Microsoft is constantly improving the AL programming language and adding new features. Eventually you can find an add-on or work around, or the AL language will catch up to your needs and give you a path to the cloud.

Moving to BC 14 now is the best possible first step in that journey.

FREE Membership Required to View Full Content:

Become a MemberLogin
Joining gives you free, unlimited access to news, analysis, white papers, case studies, product brochures, and more, and it’s all FREE. You’ll also have the option to receive periodic email newsletters with the latest relevant articles and content updates. Learn more about us here
About Robert Jolliffe

Robert Jolliffe graduated with a Bachelors of Engineering from University of Toronto and practiced briefly as a production and industrial engineer before transitioning into IT and ERP in his 20s.  He is President of Sabre Limited (, a Microsoft Dynamics Business Central VAR in Ontario, Canada. Sabre has pioneered and is well known for their remote and fixed fee implementations anywhere in North America, with an exclusive focus on the manufacturing industry.  Robert has taught supply chain at Conestoga College in Kitchener, Ontario; Collects music and owns almost all the top 500 albums as chosen by Rolling Stone magazine (he needs about 35 more); has three children and an almost magical ability to kill plants.

More about Robert Jolliffe


robert-jolliffe's picture

Microsoft has extended the dates for Business Central 14 to the late summer of 2021. Good news for people who missed the original deadline.