Deciding to upgrade or re-implement NAV and Business Central

Dynamics NAV to Business Central – upgrade or re-implement?

Business Central has been around for about a year and a half, in which time we have transitioned a sizeable number of our existing Dynamics NAV customer base. We have long looked at Business Central as just a re-brand of Dynamics NAV, which until the 2019 Wave 1 release was largely the case. However, there have since been some fairly big changes in the way modifications are handled and the overall development methodology from Microsoft.

Changing the methodology does mean considering what to do with old systems. For the first year of Business Central, things were easy, as the old development style could be used in conjunction with the new extensions (which on the whole was still not complete), allowing for some transition. However, since the 2019 Wave 2 release, although it is possible to develop the base application, it is advisable only to develop through extensions. So, do you go for an upgrade, and re-develop the existing development, or do you go for a re-implementation?

However, this question is not new, and over the years we have always had to consider with any update to a system whether and upgrade or re-implementation is best for your business. Here, we will look at some of the key factors that are currently in consideration.

Old, clean and functional

The answer to the big question comes down to the following - if you answer yes to any of the following three questions, you should think about a re-implementation over an upgrade; certainly if you say yes to more than one:

• Is the version you are on old and unsupported?
• Is your data “Messy”?
• Is your system badly customised or contains obsolete development?

How old is your system?

The older your NAV system is, the bigger the changes needed to upgrade. There have been several major changes to the product, from 2009 classic client to the Role Tailored Client, to a change in code base with Business Central and the move to the web client. This means that upgrades from very old systems actually require multi-stage upgrades. All of this increases the amount of testing and the time to process an upgrade, which is not only expensive, but can cause disruption.

Cleansing Data

In many cases, businesses with 5-15 year old systems will typically have a lot of mess in their data – information in the wrong place, incorrect values or just data that is out of date. With a re-implementation there is the opportunity to make sure that the important data is cleansed whilst offloading irrelevant content, so that with your new system you can start afresh. This will mean that utilising modern reporting options will yield better results.

Technical Factors Affecting Upgrading

With Dynamics NAV, one of the beauties of the software is that it is possible to develop the base code of the product – this means that if a company needed changes to the way that the software works, we could do it. With some of the most respected developers in the industry at the helm, we have produced some extremely elegant customer solutions. However, we have also had to rescue systems that have ground to a halt, caused by development by less experienced partners. Furthermore, the more heavily modified a NAV system is, the harder it is to upgrade.

With the new 6 monthly release cycle and the Modern Lifecycle Policy reducing the mainstream support cycle, the change in development ethos to extensions has changed the way that Business Central is developed. Extensions mean that future upgrades will be a lot easier; in the most part they will just require “unplugging”, upgrading the core solution and “plugging” back in again. Changes to the core Business Central application may mean that extensions require tweaking, however in the main it will be a lot less arduous. Encouraging users to stay on the latest versions will help businesses stay up to date with the latest technology in an ever-accelerating capability race. This has a number of implications with an upgrade:

Updating the code base - Microsoft’s legacy bespoke developer tools for C/AL, the coding at the core of NAV, has been updated. AL, developed in Visual Studio is modernising the product, however old developments will need to be converted.

Structure Changes -Development tools such as dataports and the MenuSuite have both been retired. Dataports need to be converted to XML ports and require tweaking to work with the web and tablet clients. The MenuSuite, formerly the Classic Menu, also need to be converted, to what is now called Role Menus. These are not the only development objects that need to be updated, as forms in older versions need to be converted to the new pages and the old classic report layouts need to be converted to RDLC layouts, often proving easier to start again.

Unpicking old code - We find that a lot of older systems have had development from several partners, as well as in-house staff. Over 10-20 years, a lot of the development, even the reasons for doing it, get lost and are not necessarily well marked up or documented. A major factor in deciding which way to go is whether looking at the modern day functional requirements of the business and developing new tools around the modern functionality of the product is actually more cost effective than trying to pick apart and re-purpose old development.

New core functionality – it is worth considering that Microsoft have invested millions of dollars in the R&D of the products, and so many of the bespoke tools that were built are now obsolete. For heavily modified systems , these interwoven bespoke tools may only need much more simplified extensions to enhance the new features of the product.

Regression testing – the decision to upgrade typically means a lot more testing, to make sure that the updated code matches what the company is already working as a process. A re-implementation allows a fresh look at those processes and allows more flexibility. Furthermore, because of the move away from C/AL to coding in AL and from embedded modifications to events and extensions, all developments need to be converted and rewritten, so it’s not as simple as saying ‘the code hasn’t changed so it should work … because it has!’

Why re-implementation might not be right for you

As a customer, one of the main factors that will affect the decision to re-implement is the time involved for your staff. If you upgrade, most of the work will be between your key project team and our developers – the rest of your staff will only really be involved with the testing. For a re-implementation, there will be the additional work of collecting functional requirements and potentially considering the existing processes.

Another factor is data – a re-implementation will typically "lose" deep detail in the data. Typically, when implementing only the balances will be brought across. Although it is technically possible to transfer invoice values, and even invoice lines, this is so time consuming that the value of having the information is not worth the time or cost. However, the main reason for keeping this data is reporting. Because modern reporting makes it much easier to take data from various sources, there are ways to make use of the data, such as keeping a copy of the old database or exporting the data in an Excel "dump". 

So, to upgrade or to re-implement?

As you have probably guessed from what we have written, there is no definitive answer, it is very much based on your individual circumstances. Although this guide gives you an insight to some of the consideration, it probably leaves you none the wiser as to which way to go. With a more in-depth conversation with one of our experts we would be able to help you with this decision so why not talk to our team?

Contact Us