<img alt="" src="https://secure.intelligent-consortium.com/791393.png" style="display:none;">

 NAV Upgrades 101 - Part 1

NAV Upgrades 101 - Part 1

Farmers Insurance uses the slogan “We know a thing or two because we’ve seen a thing or two.” At Innovia Consulting, we can say the same thing when it comes to Dynamics NAV upgrades. In this blog, I will discuss the different pieces of Dynamics NAV upgrades and talk about some real world examples of how things can go haywire. At Innovia Consulting, we use a systematic approach to performing Dynamics NAV Upgrades. The steps in this process include a pre-upgrade database analysis, the handling of add-ons and modifications, determining where to do the upgrade, handling security, testing and going live.

     1. Pre-upgrade Database Analysis

One thing we have learned at Innovia Consulting is that every upgrade is different. Some upgrades are simple and can be completed in less than a month. Other upgrades are more complicated and take a year or more to complete. But most of our upgrade projects take between 2-6 months to complete from start to finish.

The first step of every Dynamics NAV upgrade we do is to perform a detailed database analysis. This analysis provides us with a roadmap for the upgrade.

While Microsoft is taking steps to make future Dynamics NAV upgrades simpler, for now (pre version 2015), most of these upgrades are complicated. Some of the factors that affect the complexity of an upgrade that we include in this database analysis are:

a) Modifications – One of the strengths of Dynamics NAV is that it is simple to modify the Dynamics NAV source code to make it work the way your company wants it to work. However, when you upgrade to a new version of Dynamics NAV, we must merge each of these modifications into the source code for the new version.

b) Add-ons – There are many add-ons to Dynamics NAV that enhance the standard Dynamics NAV functionality. These add-ons involve modifications to the standard Dynamics NAV source code. When we upgrade your database, we must merge each of these add-ons into the source code of the new Dynamics NAV version.

c) Data – Over the years Microsoft has made many improvements to the way that Dynamics NAV works. Many of these improvements involve new fields or tables. When we upgrade your database to a new version, we must run a standard Microsoft data upgrade process. This process involves populating appropriate data in these new fields and tables based on existing data so that the new functionality works properly with the existing data.

In addition, many add-on vendors make improvements to their software with each new Dynamics NAV version. Since these improvements frequently involve new add-on fields and tables, we must also run the standard data upgrade process provided by the independent software vendors that created these add-ons.

d) Major changes in functionality – Over the last 10 years, there have been several major changes to Dynamics NAV functionality. Some of these include the introduction of the Role Tailored Client in 2009 and the introduction of Events in 2016. In addition, the standard Dynamics NAV code, tables and fields in certain areas such as Jobs and Kits have been completely rewritten in recent years. Finally, Microsoft regularly introduces new functionality that may make old modifications obsolete. While these changes have great benefits, they also complicate upgrades as many modifications must be completely rewritten. This is especially true for custom reports and modifications to standard reports that were not written for the role tailored client.

e) Microsoft code refactoring – Beginning in 2016, Microsoft has been systematically refactoring standard Dynamics NAV code. Code refactoring is the process of restructuring existing computer code to make it more robust, more efficient and simpler to understand without changing the functionality. This is a topic that computer programmers get excited about and everyone else’s eyes glaze over. While these are important improvements, they make upgrading modifications that were based on the pre-refactored code more complicated.

In the Upgrade Analysis, we determine the add-ons and the extent of modifications as well as a list of any classic reports, forms and data ports that must be transformed to work with the role tailored client.

     2. Handling add-ons and modifications

After completing the pre-upgrade database analysis, the next step in the upgrade process is to merge customer modifications and any desired add-ons with the standard code for the new Dynamics NAV version.

At Innovia Consulting, we use PowerShell to perform this merge as efficiently as possible. Specifically, we use three PowerShell cmdlets, Merge-NAVApplicationObject, Export-NAVApplicationObject and Split-NAVApplicationObjectFile. Microsoft provides these commands to its partners to partially automate the merge process.

To use these tools, we first create original, modified and target text files. These are text files that contain the original base Dynamics NAV code including add-ons, the modified Dynamics NAV code that our customer is currently using and the base Dynamics NAV code including add-ons for the version that we are upgrading to.

To create the original, modified and target text files, we must export all of the objects from these three databases as text files. One of the challenges with this is that some add-on objects are protected which means that we have to skip over them when we do the export. It used to be a time consuming process to figure out which objects were protected and had to be skipped. However, thanks to Microsoft, we are now able to use the Export-NAVApplicationObject PowerShell Commandlet to automate this step.

For the original text files, we merge the original version of the add-ons that are being upgraded into the original base NAV version that the customer’s current production database is based on.

The modified text file contains the Dynamics NAV code including modifications and any add-ons that are being upgraded from our customer’s current production database. If our customer has decided not to upgrade some of their add-ons, we make a copy of their production database and remove these unneeded add-ons from that copy then export the modified text file from this copy.

For the target text file, we merge the current version of the add-ons that our customer is using into the base NAV version that we are upgrading to.

Once we have these original, modified and target text files, we use the Split-NAVApplicationObjectFile and Microsoft Merge-NAVApplicationObject powershell cmdlets to partially automate the code upgrade process. The Split-NAVApplicationObjectFile cmdlet splits the object text files into separate files for each object. The Merge-NAVApplicationObject cmdlet identifies all of the differences between the original and modified objects then attempts to automatically apply those same differences to the target objects.

For the differences that the PowerShell cmdlet is not able to apply to the target database, we use the Beyond Compare tool to perform a manual three-way merge between the original, modified and target objects. These differences are frequently due to modifications to standard NAV code that Microsoft has completely rewritten in the new version. This makes it challenging to know how to do these modification in the new version.

When we run into these sorts of differences where Microsoft has completely rewritten the standard Dynamics NAV code, we create events to accomplish the same thing as the original modification. The event functionality is a feature that Microsoft introduced in 2016 that will simplify future upgrades. However, it will only do that if we take the time now to convert a given modification to an event. This is something that we as developers love to do but it is somewhat time consuming. At Innovia, we have decided that converting modifications to events will normally be done as a separate project from an upgrade except in the special case that I just mentioned of modifications to standard Dynamics code that were completely rewritten by Microsoft. Upgrades are complicated enough without adding the complexity of rewriting previous modifications to use events.

While these Microsoft PowerShell cmdlets help greatly in merging previous modifications into a new version of Dynamics NAV, we have discovered that they do not do an adequate job of merging the version lists that we use to keep track of which objects contain add-ons or custom code. For this task, we use the PowerShell program Merge-NAVVersionList created by Eric Wauters.

To learn more about NAV Upgrades, click here to view the corresponding webinar presented by Joseph Gress.

To continue on reading Part 2, click here.

 

Joseph Gress

Joseph Gress

Senior Development Consultant

Related Posts