If you are currently supporting a NAV of any version, chances are that you are considering how you should upgrade your solution to Business Central, so in this blog post, I will try to cover some of the ways that are available to you.
There are three paths that many people consider, which are:
Runtime upgrades – This is where you just open your database in the newest version and you are done, now while this might seem like an easy solution it is really a very bad idea 🥴 because this way of “upgrading” is like if you have an old bike that is rusty and needs Maintenace, and instead of fixing the bike all you do is give it a paint job and slap a new serial number on it. This means that it might look like a new bike, but it is still an old broken bike 😞. When you do a runtime upgrade, then all the code will not be upgraded so you are left with the same system just with a new user interface, which really is not an upgrade, and chances are that you will spend a lot of time afterward trying to clean up and trying to make things work 😨. And on top of the reasons above then this way of upgrading can only take you to Business Central 14 and after that, you will have to upgrade all your code to AL, and believe me trying to upgrade code that might be from a NAV 2009, 2016, 2017 or even 2018 to AL code will be a nightmare 👻 because your base code will not be ready to be moved to AL. So, to sum up, don’t do it.
One to one upgrade – This is where you do not clean up your code but you upgrade it as is, this is properly one of the most used ways because it is the least time consuming, and it is much better than the runtime upgrade, however, there are some limitations to this approach, because it much like the runtime upgrade can only take you to Business Central 14 because once you have to move your code to AL you must clean up your code, and move everything to events 🤷♂️, but you are still in a much better place than with a runtime upgrade, and this path is for sure a valid option, as long as you know the limitations.
Reimplantation – This is the most expensive path, however, it is also the path that will leave you with the best solution in the end, in this version you would upgrade all the tables the old way to Business central version 14 move all your table and table fields to AL, and move all your custom data to extensions in Business Central 14, and upgrade until the newest version, where you will have rewritten all your code to AL 💪. This is by far the best way to go, however, it can also be very time consuming, and you might feel that you do not know where to start, but luckily that is exactly what I am going to cover in this post.
So, as you can see there are only two options when it comes to upgrading, depending on the budget and the desired result, so let us dive into the reimplantation, on a side note many of the steps required for a reimplantation can also be used in a one to one upgrade 🤓.
Upgrade Application
The first thing you must do is, you must analyze your current solution, and figure out which workflows you are currently using, and write them all down, next you have to figure out how many of your workflows might be supported out of the box, with little to no change.
Once this is done, it is time to start designing your extensions, at this moment it is important that you should not feel that you have to do everything the same way as it was done in your current solution, remember one of the great strengths of a reimplantation is that you have an opportunity to start from the ground up designing everything right 🤤. Once you start coding you should target the latest (or whatever version of Business Central that you wish to land on), your application code does not need to be created for all the versions that you might have to go through in your upgrade process.
Upgrade Data
There are a couple of ways to upgrade data, you can either copy data using rapid start, or a self-developed file transfer, either by files, web services, or SQL. Or you can upgrade the data using Microsoft upgrade tools. The choice on how to move data really comes down to, if you want all your data or not 🤔. If you can live with only upgrading some of your data then using rapid start can be a good solution however if you wish to upgrade all your data, then the only really way is doing it the old fashioned way, which is the way that we will go with.
The first thing you need to do is to find out just what changes has been made to your tables, now we only care about the tables, and not any of the other objects.
The reason is if the table structure is the same across all the versions your data will follow, and the rest of the changes, for example, codeunits need to be rewritten in AL. So, the first step is to figure out which versions you need to go through to get to Business Central 14, let us say that you are coming from a NAV 2009 then you must go through NAV 2013, NAV 2018 and then to Business Central, you can find a list of the versions that you need to go through here: https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/upgrade/upgrading-to-business-central-on-premises
So, for our example, you create a delta list of all the new fields and tables that have been added to your NAV 2009 and then create all these fields and tables in a NAV 2018 and in a Business Central 14 Crouns database and export all the objects so that you have two clean object packages that contain all standard objects including all your table modifications and new tables. You then import the upgrade tool kit from your product DVD into your NAV 2009 and follow the upgrade guidelines in the PDF 🤓. Once you have followed all the steps in Microsoft upgrade guides and you are on a Business Central 14, C/AL you must create a simple table extension which holds all your custom fields and tables, here it is important to note that your fields must not have the same name or number as your current fields and tables in C/AL. Once your extension is done, you must create a codeunit that you can use to move all your data from your C/AL tables and fields to your AL tables and fields, once all your data has been moved, you then force delete all your custom C/AL tables and fields, and procced with Microsoft upgrade guide. Once you get to the desired version of Business Central, you then install your new extensions with all your customizations, and just like earlier, you then must create a codeunit that will move all your data from your data upgrade extension to your real extensions, and you’re done. You have now successfully reimplemented your current solution 🤩.
Now I know this all sounds easy on paper, and in real life, it won’t be that easy 😉, but it is important to note that doing a quick and dirty upgrade is not a good idea, unlike back in the day, where it was “easy” to upgrade your application one to one, with the move to Business Central I feel that you should more see it as you are implementing a whole new system and not just a new version 😇. And I know this is a costly task, and due to that fact many people will land on the last version that supports both C/AL and AL which is Business Central 14, and your customers might be stuck on that version for many years to come, and hopefully, down the road, we will get some tools that will make it easy to go from a Business Central 14 to the newest version, but no matter what once you move past Business Central 14, you are moving away from our old and beloved NAV and into a whole new world of both possibilities and limitations 🙃.
Well, that was it for this time, until next time stay safe. 😷