The Target Version: Making Dynamics NAV Upgrades Cheaper

Usually, after Microsoft Dynamics NAV has been installed at a customer site, customers will periodically update the installation and, over the course of time, will have their Microsoft partner apply several cumulative updates and/or version upgrades. What many customers don’t know is that they can save themselves time and money on each cumulative update or version upgrade in the future by asking for the base target version used by the partner during the update or upgrade. Here’s how it works.

In both cases—when upgrading or when applying a cumulative update—you need to perform a code merge. The code merge involves taking 3 separate versions of the code to create a new upgraded 4^th version that will be used in production going forward. (See https://docs.microsoft.com/en-us/dynamics-nav/upgrading-the-application-code for more details.)

The versions needed to perform the merge are:

• Original Version: the original base version.
• Modified Version: the version that you want to upgrade. Typically, this is the production version that includes your specific customizations that you want to upgrade.
• Target Version: this is the new base version that you want to upgrade to.

When doing the merge, the partner will typically create 1 database for each version and then will export each version’s application objects to text files, thereby creating 3 sets of text files, 1 set for each version. Using Powershell or other tools, the partner will then compare the text files from the modified version to the original version and will apply the changes to the target version.

If no third-party add-ons are involved, then things are relatively straightforward. The partner can usually find a copy of the desired original and target version databases on Microsoft’s PartnerSource. The older the version is, the more digging will be required to find the appropriate database to copy.

If add-ons have been applied to a database, then things are a little more complicated. When comparing the modified version to the original, the partner usually wants to isolate the customer-specific changes that were made in addition to the add-on(s) added to the database. So, the original version to use for the comparison is the standard Microsoft version with all the add-ons applied to the standard Microsoft version. For the purposes of this discussion, let’s call this database the “original version with add-ons”.

To recreate the “original version with add-ons”, the partner needs to look at the customer’s production database to identify the add-ons in use in the customer’s database. Then they need to start with the old standard Microsoft version, get the appropriate versions of those add-on application objects, and apply each one. Typically, each add-on will be developed by a different partner, so to get the objects, the partner performing the upgrade will need to contact each add-on partner. Further complicating matters is the fact that each add-on might be based on a slightly different build and might be supplied in a different way. Some add-ons are supplied in a NAV database, some in a base fob together with subsequent update fobs that all need to be applied, etc. In short, it can be difficult, frustrating, and time consuming for the partner’s developer to create the “original version with add-ons”.

The target version also needs to be created. That involves getting the new standard Microsoft version, then contacting each add-on Partner to get the appropriate objects, and applying each one. Usually, this is simpler than creating the “original version with add-ons” because the target version is more recent, among other factors. This target version will be used as the base for the new customer specific modifications.

Here’s the thing. A typical customer will go through several cumulative updates and/or version upgrades, and the target version from one update/upgrade can be used as the “original version with add-ons” for the next update or upgrade. The difficult task of creating “original version with add-ons” can be eliminated (or greatly simplified) if the upgrading partner had access to the objects from the target version of the previous update/upgrade.

Usually, a partner will try to keep a copy of the target version for use on the next update/upgrade. Things happen though. Partners can go out of business or get bought out; consultants and developers change, and objects can get lost; the customer might change to a new partner. So, it is in the customer’s best interest to request a copy of the objects that they can manage and archive.

Due to licensing reasons, the partner will not be able to supply you with a text export of objects, but, they will be able to supply you with a fob export of objects that a partner can use to create text exports.

So, if you are managing a NAV installation, when the partner is preparing to deliver your shiny new custom version, ask for the target version that they used for a base. In the next update/upgrade that you do, you can supply it, the partner’s developer will thank you, and you might save hours and hours of billable time.