We have a customer who is currently working with a previous version of Microsoft Dynamics NAV. They know that a new version of the product is about to come out and they always want to be up to date, so they asked about migrating to the latest version.

We said: "Well, that is something that cannot be done in 5 minutes. Upgrading is a project! Let's take a look at it and we will come back to you with a project proposal and quotation."

We prepared the skeleton of the project, evaluated its implementation of Dynamics NAV to determine the effort required to upgrade to the current version, and presented to him the quotation.

The first thing the customer said after they had the quotation in their hands was: "Have you gone nuts? Do you really need all this time to upgrade my implementation of Microsoft Dynamics NAV? How is that possible? Every once in a while automatic updates are installed in Windows through Windows Update, and many other applications check online for the existence of available updates and install them themselves. Why does Microsoft Dynamics NAV not work that way? Why do we have to pay for this project?"

That is definitely a good point. But Microsoft Dynamics NAV doesn't have automatic updates, and there is a reason for that.

Customization is actually the reason.

Microsoft Dynamics NAV is an application that can be customized. Some companies do customize their implementation of Microsoft Dynamics NAV a lot. Some others, just a little bit.

Microsoft Dynamics NAV could be used with no customization at all—sure, but the truth is that we don't know of any implementation of the application that has zero customizations. At least, the printing of documents such as Sales Invoices or Sales Shipments have some customizations, but we have not seen any implementation with only those customizations. Customizing Microsoft Dynamics NAV is so easy that usually many customizations are done; there is no need of other applications to edit the application code since Dynamics NAV has its own code editor; no need of full compilations of code projects; no need of deployment of the new solution since modifications can be done on the fly and they get to end users right away, and so on.

They can be minor customizations such as adding an existing field to a page or creating a new field in an existing table. They can be mid-size customizations such as modifying some minor standard behavior. Or they can be major customizations such as developing a whole new functionality or changing the way major standard functionalities behave.

Some applications do have different code layers. The standard application code is in a base code layer and customizations are done in other code layers that are built on top of the base code layer. That way, the base code layer could be updated, for example, and customizations will still apply.

Unfortunately, that is not the case in Dynamics NAV. The layer concept in Dynamics NAV does not exist, although you could think of it as a single code layer on which both the standard application code and the customized code are written. It is not just the customized code that is written in the same layer as the standard application code. The standard application code can actually be modified or even deleted.

When you get a new version of Microsoft Dynamics NAV and a new standard application code file, a merge process has to be done to ensure that customizations done in a specific version of Microsoft Dynamics NAV are carried out into the new version of the application. That process cannot be done automatically (although we will explain in this chapter some tools that will make the process easier). Some steps in the merge process will have to be done manually by a Microsoft Dynamics NAV developer. Some others will have to be done manually by a Microsoft Dynamics NAV implementer.

An upgrade project in Microsoft Dynamics NAV can be an easy task or a large project. It really depends on how customized the Dynamics NAV application is and which previous version of Dynamics NAV you are coming from:

Summarizing the processes that have to be completed for an upgrade project are:

Keep in mind that the processes to upgrade data into Microsoft Dynamics NAV 2013 are intended to upgrade data only from the previous version of Dynamics NAV – Microsoft Dynamics NAV 2009 (including SP1 and R2). If your old implementation of Dynamics NAV is in any earlier version, some extra steps will have to be taken.

Imagine you have a Microsoft Business Solutions–Navision 4.0 SP3 implementation. To upgrade to Microsoft Dynamics NAV 2013, data will have to be upgraded firstly from Version 4.0 SP3 to Version 5.0 SP1, then from Version 5.0 SP1 to Version 2009 R2, and finally from Version 2009 R2 to our final version, 2013.

That means that steps 2, 3, and 4 will have to be done as many times as versions that exist between your old implementation version and the latest version of Microsoft Dynamics NAV.

In the following section, we will do a checklist of detailed steps that have to be taken to upgrade to Microsoft Dynamics NAV 2013 from every version since Navision Attain 3.60. We will do that in the reverse order, though. That is, we will first expose the checklist of actions to upgrade from Microsoft Dynamics NAV 2009 (also SP1 and R2), which is the immediate previous version that will have the least number of steps to upgrade; and then from Microsoft Dynamics 5.0 (also SP1), which will have all steps to upgrade from 2009 plus some extra steps; and so on.

After that, we will explain every single step with all kinds of details.