Migrating Customer Data to Dynamics NAV 2013

Data migration is an important part of the upgrade process, arguably the most important apart from upgrading the application code. And the more legacy data the customer database has, the more difficult this process is. Usually, when upgrading large in volume data, it would be reasonable to optimize the data. This can be done in the following ways:

  • Compress the ledger data. Dynamics NAV provides several tools for compressing general ledger and sub-ledgers.
  • Review and clean unnecessary data. This usually concerns the Change Log Entry table which stores user activity within the database. Sometimes, this data can be cleared when not being used in reporting.

The following considerations make data upgrade within the Dynamics NAV system more challenging and should be taken into account during estimating the project risks:

  • Big difference between NAV versions. Upgrading from Navision 2.0 to NAV 2009 is not the same as upgrading from Navision 4.0 to Navision 5.0. Later in the article, we will have a look at the different steps needed to successfully overcome this challenge.
  • Migrating from Native to SQL platform. Dynamics NAV provides a set of tools to facilitate the process. These tools will be reviewed as well.
  • Upgrading add-on data. If the customer has add-ons installed in the database, e.g. Serenic Payroll, EDI, etc. – the data which resides in custom tables should be migrated using custom tools. Dynamics NAV standard upgrade toolkit will not handle it. Most of the well-known add-on manufacturers provide data migration tools along with their product. However, if it’s not the case – moving data from/to custom tables becomes the responsibility of the developer. Time which is required for developing such tools should be estimated separately in the upgrade quote.

During the upgrade process in Dynamics NAV, data migration is usually performed twice:

  • Test Data Upgrade
  • Live Data Upgrade

Let’s look at the activities performed during each of these stages and their differences:

As we can see, to avoid any issues during migrating the live customer data, it is highly recommended to perform a test data upgrade first.

Now let’s look at the process of data migration within the Dynamics NAV system. There are manuals along with the Upgrade Toolkit which describe the process in detail; so, we will discuss the main points only. In the course of our discussion, we will assume that the upgrade is done from Navision 3.6 to NAV 2013. This example will show the basic challenges and steps required for a smooth process.

(1) Preparation

In order to prepare the database for data migration, we must ensure that the following is done:

  • Object/code upgrade. This process merges the old customized objects with the new version of these objects, so that any custom code is transferred to the new Dynamics NAV version.
  • If upgrading from a Native to SQL platform, the special check tool needs to be run. This tool is provided along with the Upgrade Toolkit. It checks the data in the database for consistent and SQL-compatible values. If these values are incompatible (e.g. the customer might have occasionally entered year 0008 instead of 2008) – it is recorded in a separate table. After the process checks all the data, you will receive the list of incorrect values and suggestions on how to change them. You must apply the suggestions before proceeding.
  • A number of batch jobs should be run prior to migrating data. This list depends on the modules being used and is documented in the Upgrade Manual. For example, if the customer is posting inventory costs to a general ledger the Post Inventory Cost to G/L” batch job should be run to update the costs.
  • At least one SUPERUSER should be identified in the database in order to perform the required upgrade activities.

(2) Data Migration Steps

When upgrading from Navision versions 3.6 or earlier, the process requires an additional step – upgrade to Navision 3.7. This means you cannot directly upgrade from 3.6 to 4.0, due to a major functional re-design which occurred in Navision 3.7.

So, the following steps are required in order to upgrade from Navision 3.6 to NAV 2013:

  1. Run the upgrade toolkit for upgrading from Navision 3.6 to Navision 3.7. This is a two-step process: moving necessary data to temporary tables, then moving them from temporary tables to the tables from the new version.
  2. After that, when our database has the data migrated to Navision 3.7, we can attempt migrating directly to NAV 2009. Some development experience is required here in order to adjust the Upgrade Toolkit code.
  3. The last step would be to run the Upgrade Toolkit for migrating data from NAV 2009 to NAV 2013.

As we can see, data migration is quite a complex procedure, and each of the migration versions requires running the Upgrade Toolkit in two steps (uploading the upgraded objects is not the work of toolkit):


After the data upgrade is completed, your developer should update the database with new roles and permission sets. The Dynamics NAV Upgrade Toolkit has the necessary utilities for this.

After the work is completed, the toolkit and other auxiliary objects should be removed from the database, and the final object compilation should be done.

Upgrading customer data or moving it to the new system has always been a challenge both for the customer and partner. This process should be carefully planned and tested, and the backups should be performed after each stage of the migration. That is why it is really crucial to entrust this process to an experienced development team with skillful project planning and risks management resources.

October 18, 2013


Email [email protected] with any questions you have pertaining to this course.

New CPE Accredited Courses Now Available for Dynamics AX, GP, and NAVEARN CREDITS TODAY