Dynamics AX 2012 Data Upgrade Introduction

In this post I will be introducing to the Microsoft Dynamics AX 2012 Data Upgrade, tasks involved in the Data Upgrade process along with some key points which must be considered before and during the upgrade process.

Before getting started I would first like to introduce you to few key terminologies which will be used throughout the series of these posts: 

Microsoft Dynamics AX 2012 Data Upgrade can be divided into two categories:

•  In-place upgrade
•  Upgrade from Older version i.e. AX 4.0 or AX 2009

Term In-place upgrade is referred to the upgrade from one version of Microsoft Dynamics AX 2012 to another i.e. AX 2012 R2 to AX 2012 R3. This type of upgrade requires no source-to-target workflow that is used when we upgrade from AX 4.0 or AX 2009.

In this post and further upcoming post we will be focusing on the Data upgrade in AX 2012 from older versions i.e. AX 4.0 or AX 2009 which follows the source-to-target model.

What is Source-To-Target Model?

Upgrades from AX 4.0 or AX 2009 to AX 2012 require two computer systems that operate in parallel:

• The source system, which remains in production for most of the upgrade process.
• The target system with the latest Microsoft Dynamics AX version.

In previous versions of Microsoft Dynamics AX, all upgrade tasks were performed on a single production system due to which the system has to remain offline throughout the upgrade process which was a major drawback because due to this the business processes and operations could not resume and all the issue have also to be resolved in order to complete the upgrade process and resume business operations.

Now, under the source-to-target model such issues involving the upgrade of business data are mostly resolved on the source system without interrupting the business operations and one the major Data upgrade tasks such as data preprocessing is done on the source system and the target system is also ready, at that point the source system is taken offline and the prepared business data is copied over the target system and upgrade scripts run, after testing the target system can go live. This results in a less down time of the production system due to source-to-target approach.

Source-to-target upgrade requires that the source system and target system be installed on separate server computers. Although side-by-side installation on a single computer is possible, we recommend that you use this approach only for testing purposes.

The following diagram shows the phases of an upgrade that follows the source-to-target model.

Tasks performed at Source and Target systems:

The brief introduction of the tasks which are performed at the source and target systems during the data upgrade process are as follows:

The high level tasks which are performed on the source system are as follow:

Source Data Upgrade check list:

The High level Tasks which are performed on the Target system:

Target Data Upgrade check list:

Key points to be considered before upgrade:

Analyzing Customizations:

Before starting data upgrade, one must analyze all customizations and create plans for code upgrade. All customizations should be evaluated to see whether they are still necessary in Microsoft Dynamics AX 2012, or whether a complete refactoring is required. Work with your value-added reseller (VAR) and independent software vendors (ISVs) to ensure that they have the necessary upgrade scripts in place for your upgrade.

As part of your planning, write the data upgrade scripts that are required to support your customizations.

Examples of the types of upgrade scripts required include:

·         Readiness checks – It is very important to consider data readiness checks for all custom tables that interact with core Microsoft Dynamics AX tables. Any type of ledger account or dimension, address information, or inventory dimension information should always have a readiness script written to check for the existence of the related data.

·         Preprocessing and delta scripts – These scripts are required to start to prepare the application data for upgrade by creating shadow tables to map any new fields, and to assign key relations to the new ledger, inventory, and address data that is required for custom fields and tables. These scripts also should be used to facilitate a change for most of the relationships between custom tables and core Microsoft Dynamics AX tables, so that these relationships use RecIDs instead of the typical string ID value.

·         Single-user steps and all target-side operations – The code upgrade should be fully completed by the time single-user processing and target-side processing starts. The only exception would be a test upgrade that is run for the purpose of migrating data for developer testing, but that can only occur after all data upgrade scripts are written. The data upgrade scripts on the target side must include all table and field mapping information in order to proceed.

Purging and archiving data with the Intelligent Data Management Framework:

Prior to upgrade, we recommend that you consider purging or archiving data from the production Microsoft Dynamics AX database. The Intelligent Data Management Framework for Microsoft Dynamics AX (IDMF) is a tool that you can download from Microsoft Dynamics Information Source.

Analyzing space requirements for databases:

Analyzing and adjusting the space available for your databases can significantly improve performance during data upgrade. If you do not increase the size of the databases, database re-sizing occurs during the upgrade and significantly slows down all operations.

·         Increase the size of the source database and transaction logs by at least 35 percent. It is recommend that you investigate the actual growth of the database on a test run to more precisely determine how much additional space to allocate.

·         Determine the appropriate size for the Microsoft Dynamics AX 2012 database. It is recommend that you increase the size by at least 30 percent. It is recommend that you closely monitor the actual growth of the database on a test run to more precisely determine how much additional space to allocate.

·         Increase and monitor the size of the TempDB database during a test run to determine sizing for the upgrade. A rough estimate for sizing your TempDB database is 20 to 25 percent of the expanded Microsoft Dynamics AX 2012 database. Optimal performance may require splitting the TempDB database into separate files.

Note: Microsoft Dynamics AX 2012 does not support Oracle. To upgrade an Oracle database, use the Oracle to SQL migration tool on the source Microsoft Dynamics AX 4 or Microsoft Dynamics AX 2009 Oracle database first, and then upgrade the SQL database to Microsoft Dynamics AX 2012.

Conclusion:

In this post I have tried to highlight the overall Data upgrade process in Microsoft Dynamics AX 2012 from AX 4.0 or AX 2009. The main purpose of this post was to build up a basic understanding about the Data upgrade process and the Upgrade framework tasks along with the basic understanding of Source-to-target model and also some key points which must be kept in mind before the upgrade. This post will be treated as a prerequisite for the further upcoming posts which will be covering the key steps involved in the upgrade process in detail.