Microsoft Dynamics NAV has been renamed Microsoft Dynamics Business Central. Along with the name change, there are several significant changes in the software. One of the most significant is the elimination of the C/SIDE development environment and the C/AL language as of the October 2019 Wave 2 Release. These have been replaced by the Modern Development Environment, which uses VSCode, and the AL language.
How Dynamics NAV Customizations Work
Through Microsoft Dynamics NAV 2017, changes were made inside the existing program. Microsoft Dynamics NAV 2018 and following use the concept of extensions. An extension is an add-on to the existing program which adds features without requiring changes to the program code. You might think of the old method as being “inside” the program code, and the new method as being “outside” the program code.
From a practical point of view, this means that once code is converted from the old method to an extension, upgrades become more straightforward. Since they are located in one or more “projects,” they can be tested quickly against a new version. And since they use triggers or events, they are compatible with future releases as long as Microsoft does not make changes to these “hooks.”
As Microsoft makes changes to Business Central, it may still be necessary to update the extension. However, it will not be necessary to extract changes from the program code and then merge them back into new program code.
Migrating Custom Code from Prior Versions
Microsoft has provided a number of tools to assist in migration. These include tools to convert C/AL code to AL code, and tools to create extensions from the changes made in prior versions (called Delta code). The newest version includes tools to migrate a custom database to the new format without having to write code.
In some situations, customization will translate to the new version with very little re-coding. In other cases, the technique used may have been eliminated and more extensive changes may be required. In all cases, some preliminary evaluation of your database will help a developer determine how to proceed.
Options for Upgrades
Until October 2020, existing Business Central / NAV users will have access to the Windows Client. This was called the “role-tailored client”) from 2009 forward. It has been eliminated for releases after the April 2019, but existing users can license it through 10/1/2020. Since this version supports C/SIDE, it is possible to move to it without converting code to AL. But that is just delaying the inevitable.
If you want to maintain the Windows Client look and feel, however, it may be a good option to move to the April 2019 release (14) while converting the code and database to AL.
The basic evaluation process extracts your customization to DELTA files, then converts the DELTA files to AL code and uses VSCode to evaluate the result. To do this, convert your base, unmodified current version and your modified version to 2018 or 2019 April release. This isn’t a full conversion, it just involves opening the databases with the new C/SIDE development tool.
Once they are converted, follow the instructions here to produce the AL code. A few technical notes: (1) the objects need to compile in the new version in order to export correctly, (2) You need the -ExportToNewSyntax in order to use the txt2al tool that produces the AL files, and (3) if you did not customize the object, it does not need to compile.
Things To Watch For
The Txt2Al tool does a fair job in that it will save you time. However, particularly when converting older reports, you will get files with errors. Watch particularly for the “Ambiguous reference,” error. Many of these seem to be produced by the fact that the Txt2Al tool sometimes does not surround fields with double quotes.
For example, the field Document No., needs to be written “Document No.” The conversion tool often omits this punctuation, which gives errors in VSCode: not just in the places the quotes are needed, but in other code that is not in error. Start at the top of the converted file and correct obvious errors; skip items that do not seem to be errors until you reach the bottom. Then begin another pass with the same heuristic. Doing this–particularly with reports–often caused errors that were not really errors to disappear. That is particularly the case with the “Ambiguous reference” error.
Good coding, and let me know how it comes out for you!