Code upgrade from Dynamics NAV 2009 to the Cloud

Code upgrade from Dynamics NAV 2009 to the Cloud

In my last blog post I went through the platform upgrade process for Dynamics NAV 2009 up to the cloud. Today I will follow up with the process for the code upgrade for the same versions.

Considerations before upgrade

A very important decision must be made prior to upgrade.

Do we want to convert all old data from when the company was started at all? The old data might utilize old customization or old add-ons that will be obsolete in the new version. Old inactive items, customers or vendors will be included in an upgrade and that means:

Shit in -> Shit out

Understood like this: if you do not take advantage of this upgrade to clean up the data in your ERP system, then it will never be cleaned up.

In Denmark the new Bookkeeping Act of July 1st, 2022, states that the details of the bookkeeping in a company should also be available digitally at an independent source up to 5 years (or as long as any contract obligations run), also in the event of bankruptcy. But this also means that a backup copy could be made available stored at a third-party company, and a new implementation made in a new standard Business Central with only the master data and open documents included.

But what about the statistics some might ask? Well, you can get a long way with Power Bi or another Bi system utilizing data from both the history database and the new live database.

Another reason to start from scratch is the database limit in the SaaS version of Business Central. Every production environment allows a database size of 82GB + 1GB per user, so if the ERP system has been running for 25 years in an SMB company with 50 employees, the database can easily amount to 350-400GB because of the accumulated data. This company will only be allowed 133 GB database, which hardly covers all historical data.

Also, as I wrote in my previous blog post you need to consider the following:

  1. Does a localization for my country exist in the cloud?
  2. Can all partner customizations be upgraded to cloud?

If they include some of these:

  1. Dot-Net code that is not covered in AL
  2. Custom DLLs
  3. File handling
  4. Control-Addin using Windows Forms

Then other solutions must be considered

  1. Can any of the partner customizations be replaced by new functionality, e.g. mail handling.
  2. Do all my add-ons provided by ISV partners provide conversion to the cloud?
  3. Do all my existing add-ons provided by ISV partners exist in the cloud?
  4. The report designer changed drastically from Dynamics NAV 2009 to RDLC and it is possible to convert directly from the classic design to RDLC using a free tool from ForNav, but there are still considerations to this:
    1. Customized reports or something similar could be added to the base application by Microsoft
    2. Maybe Cues or filtered lists can replace some of the customized reports
    3. The old reports might not have been used for years, so why convert them?
    4. The users can use Custom Report Layout to perform layout changes themselves
    5. Power BI provides much better statistics than RDLC ever could

My advice is to only convert the external reports and then later create custom reports only if the users can provide a justified need for it.

Why did companies get stuck in older versions?

As you can see from the above illustration, there have been many changes to objects over the years. Many of the object types are still active in the new development environment but others have been deprecated and are not backwards compatible.

Customers decided to stick with Dynamics NAV 2009 for many reasons:

  • The Classic client co-existed with its forms.
  • Forms could be edited directly from the client.
  • The report designer was a lot easier to use.
  • If web services were needed, then it was possible to utilize the service tier and thereby the web services alongside the classic client.
  • And of course, the number of customizations in the old version made it practically impossible to upgrade to a new version.

So, to keep the user interface and keep the users happy, it was the perfect solution.

However, there is a price to pay while upgrading to any version that is newer and even more going to the cloud. Much can be spoken for deciding to ditch all form customizations and starting all over again with the standard pages in the end version. There are conversion tools to convert from forms to pages but the technology of the pages versus the forms is so different that a lot will be lost in the conversion process anyhow, and there is most definitely new functionality in the new versions that would have to be manually added to the converted pages to utilize them.

Upgrading from Dynamics NAV 2009 to 2013

Normally there are a number if steps that can be omitted when the upgrade is only one step in the upgrade process, but in the case of Dynamics NAV 2009 to 2013 there are schema changes that must be applied to get a successful result. So, I will follow the upgrade guide as described here:

Upgrading to Microsoft Dynamics NAV 2013 | Microsoft Learn

The first thing to do is:

  1. Identify all customizations to keep and to discard the unnecessary ones by reverting to standard code
  2. Create a standard Dynamics NAV 2009 database with all the same localizations and add-ons as the Dynamics NAV 2009 database.

    Make as described here:

    Identifying Customized Objects | Microsoft Learn

  3. Catalog all Dataports so they can be recreated as XMLPorts
  4. Catalog all changes to forms so they can be recreated as Pages
  5. Delete all Forms and Dataports
  6. Then compile all objects to identify all objects with references to the forms and pages
  7. Fix the references
  8. Move all the customizations to a standard Dynamics NAV 2013

    To prepare for later refactoring of the code, a simple task of moving customizations that were previously placed on tables, forms, reports, etc. into codeunits. That way it will make the process easier later,

  9. Then, Import the upgrade codeunits

  10. Run the Data Conversion

    Task 11: Step 2 Data Conversion | Microsoft Learn

And you have ended up with an upgraded Dynamics NAV 2013 database.

Upgrading from Dynamics NAV 2013 to BC14

Now with the upgraded Dynamics NAV 2013, it is possible to upgrade to BC14 (Spring Release 2019).

This has been discussed in my previous blog Upgrading from Dynamics NAV 2009 R2 Classic to BC25 in the cloud – Peik’s Corner.

Should I go from 2013 to 2015 and from 2015 to BC14, or should I go from 2013 directly to BC14, both are possible. Converting reports from Dynamics NAV 2013 to BC14 will require the SQL Report builder to be downgraded to version 2016, but coming from Dynamics NAV 2009 the report will need to be refactored anyway, and the that would be then a moot point. Playing it safe, I decided to go from 2013 to 2015 and from 2015 to BC14.

Regarding the external documents like:

  • Report 205 Sales Confirmation
  • Report 206 Sales Invoice
  • Report 207 Sales Credit Note

And a lot of other external reports they are all deprecated in the future versions replaced by:

  • Report 1305 Sales Confirmation
  • Report 1306 Sales Invoice
  • Report 1307 Sales Credit Note

Which by the way are much easier to customize than the previous versions.

The result is the same we end up with an upgraded BC14 database.

Moving customizations from C/Side to an extension

Now we have an upgraded BC14 database, but we are still stuck with customizations in C/Side.

What does that mean?

In C/Side, all objects were stored in the Object table in the SQL server. This meant that any object that was created was stored in a record in this table. If the object was a table object, then the Schema Synchronization would mirror the table to the SQL Server database. So, if a new field was created to the Customer table for example, then the field would be synchronized to the equivalent table in the SQL database. Hence the changes to the Base Application. This also meant that upgrading to a newer version, it was necessary to create the same customization in the Customer table in the new version before conversion. In AL all Objects are stored in the NavApp table and any table objects are synchronized to the SQL server with the Schema Synchronization process. Any table extensions are stored as “Shadow” tables which only consists of the primary key and the added fields.

In order to move to the cloud, it is no longer allowed to make changes to the Base Application and all customized data must reside in a table in an App. Therefore, I have to prepare my solution to move the data from the C/Side table to a new table or table extension in my new app.

This is called Side by Side development, explained here: Running C/SIDE and AL side-by-side – Business Central | Microsoft Learn

Since it is not possible to have two fields with the same name and the same object number in the same database, I have to be a little creative:

  1. First, identify all C/Side customized objects in the 50.000-99.999 object range that are modified
  2. Then it is necessary to export all these objects using PowerShell and the Txt2AL conversion tool, as described here:

    The Txt2Al Conversion Tool – Business Central | Microsoft Learn

  3. That will create AL objects for all the objects that were previously in the C/Side objects, but the data still resides in the C/Side objects.
  4. The AL objects can then be included in my new extension

C/Side Object

Converted AL Object

  1. Then I export all customized table and page Base Application objects to a text file. This is not done with the Txt2AL tool.
  2. Having all customized objects, we now need to find the exact same objects in the same version and with all the same Add-ons, only here they need to be from a standard database.
  3. Then the Txt2AL tool can be used to create Delta files, which can be made into Table Extension and Page Extension files to include in my new extension.

C/Side Object

Converted AL Object

  1. So, now I have the same tables and the same fields in both C/Side and in my extension as an AL object. This is not possible, and it is apparent that Visual Studio Code agrees with me with all the red lines in the objects.

 

  • Therefore, I need to do four things:

 

  1. Rename the field names in the C/Side table in the Base Application (here Customer)
  2. Renumber the object numbers in the AL table extensions
  3. Rename the object numbers and names in my AL tables
  4. Create an Install codeunit in my AL extension to copy the data from C/Side to the new tables and table extensions in my new app.

C/Side Object

Corrected AL Object

  1. And the Install Codeunit can look like this:

  2. Check if the data were copied from C/Side to the AL table and fields
  3. Delete all customized C/Side tables in the object number range of 50.000-99.999 with Schema Synchronization = Force.
  4. Then Import all standard Base Application objects into C/Side and replace with Schema Synchronization = Force, that will remove all the customized fields from the C/Side tables.

 

 

 

In the above example, I have used the “old” naming convention, and I therefore had to prefix all new object and field names with my “BAC” prefix. This also means that I need to find all references in the extension ode and rename the fields there. Had I instead used Namespaces then I could have avoided that, however namespaces are not available in runtime 3.0. I could have kept the original object and field names and then implemented namespaces later. Then I would not have to rename the AL fields.

Converting existing code from the base application to AL

Now that we have moved all the fields from C/Side to AL, it is time to check the customizations that were made in the base application.

A customization could look like this:

That needs to be refactored to a more modern approach. Therefore, next thing is to identify, where in the code a future customization could be “hooked in” and I am therefore looking in BC14 for Integration Events or Business Events that I can hook into. Especially which events that will provide the necessary data to provide the same functionality without changing the Base Application:

Looking in the BC14 Codeunit 80 Sales-Post, I need only the Sales Header and the Sales Shipment No. and looking in a standard Codeunit 80, I find this:

This is perfect, all I need to do is to create an event subscription in AL that consumes this event:

This will later need to be refactored because file handling is not allowed in the cloud, and since sending documents as mail are standard in the later versions, it will look something like this:

Moving forward from BC14

When all C/Side customizations have been moved to AL and all C/Side objects have been reset to standard, it is possible to convert to BC24 or later and from there on to the cloud.

There might still be code changes as some of the events have been changed, procedures in the base application have been deprecated or new functionality have been introduced. Usually these are publishes in the Deprecated Features in the Base App – Business Central | Microsoft Learn site.

These are my experiences, and I hope that they can provide help for others.

Leave a Reply

Your email address will not be published. Required fields are marked *