Fast and seamless upgrade to AX 2012

Each new version Dynamics AX contains a number of attractive features that you may be deprived of due to concerns about the complexity of the upgrade process. In this article, we want to describe how you can minimize the time and cost required to upgrade from AX 2009 to AX2012.

There are two approaches to upgrading to AX 2012: in-place and source-to-target. Only the second approach is suitable for large upgrades.

The aim of the whole Dynamics AX upgrade process is to be carried out quickly and without unnecessary costs and risks in order to be as transparent as possible for the user. That is , so that the user finishes his work in the current version of Dynamics AX on Friday and continues working on the new version of Dynamics AX on Monday. In this new version, the user will have unchanged settings and data.

There are two approaches to a successful Dynamics AX upgrade: In-place - The upgrade takes place in a single environment that changes from Dynamics AX 2009 to Dynamics AX 2012 (this is not recommended by Microsoft for large upgrades) and Source-to-target - A copy of the Dynamics AX 2009 environment is prepared for the upgrade, Dynamics AX 2012 is installed next to it and the code and data is transferred.

The theoretical upgrade procedure is as follows: The tool first migrates the code (custom modifications) and the programmers then resolve the conflicts. On the day of the upgrade, the tool then automatically transfers the data from the production Dynamics AX 2009 to the pre-prepared Dynamics AX 2012.

In practice, neither of the above steps goes completely smoothly and there are many problems to be solved. The upgrade has to be done "clean" until it goes smoothly (necessary to complete the upgrade within a predetermined timeframe).

Code transfer is a separate chapter. The ideal is to merge customization in Dynamics AX 2009 into one layer (not necessary, but it saves time).Unfortunately, the tool cannot transfer changes in some objects (they have to be implemented again) and even Microsoft documentation is not complete (but the right vendor has the know-how). Afterwards, conflicts in the target environment need to be resolved (their number can be reduced by preparing the code in Dynamics AX 2009). At the end of the process, further analytical work and development may be needed depending on how the custom objects are changed in the SYS layer.

Microsoft's documentation for code transfer is incomplete, so only an experienced vendor can perform a successful upgrade.

After the code has been transferred, the data must be transferred. Ideally, the data transfer is fully automatic. Realistically, however, the tool cannot cope with inconsistencies in the database, bad settings and other inconsistencies in the data. Some of these errors can be solved by programmers, others need to be consulted with the customer (business data). Unlike code, the data transfer cannot be done in advance and therefore only a test run is necessary. The whole process can only be started after the customer has shut down their system. During the upgrade you will face many problems, e.g.:

• Upgrading the system in a completely disastrous state (uncompiled custom modifications in all layers and inconsistent database)
• Solving snags that even Microsoft doesn't know about
• The need to create custom tools specifically for upgrades (e.g. a tool for reducing conflicts by preparing code in Dynamics AX 2009)

Upgrading to Dynamics AX 7 will soon become an important topic. Although ERP system Dynamics AX 7 is not out yet, so it is likely (according to information from Microsoft's community site) that a direct upgrade from Dynamics AX 2009 (and earlier versions) to Dynamics AX 7 will not be supported. Upgrading any older version to Dynamics AX 7 will likely only be possible by upgrading to Dynamics AX 2012 R3, which is the only version from which it will be possible to upgrade to the latest version. We know the first step, and we will learn the second step as soon as Dynamics AX 7 is released.