Fast and Seamless Upgrade to AX 2012

Every new version of Dynamics AX includes a range of attractive functionalities that you might be missing out on due to concerns about the complexity of the upgrade process. In this article, we explain how to minimize the time and costs required for upgrading from AX 2009 to AX 2012.

There are two approaches to upgrading to AX 2012: In-place and Source-to-target. Only the latter is suitable for major upgrades.

The goal of the entire Dynamics AX upgrade process is to complete it quickly, without unnecessary costs or risks, and to make it as transparent for users as possible — so that a user can finish work in the old Dynamics AX version on Friday and continue seamlessly in the new version on Monday, with all settings and data unchanged.

A successful Dynamics AX upgrade can be achieved in two ways: In-place – the upgrade is performed within a single environment that changes from Dynamics AX 2009 to Dynamics AX 2012 (Microsoft does not recommend this for large upgrades); and Source-to-target – a copy of the Dynamics AX 2009 environment is prepared for upgrade, Dynamics AX 2012 is installed alongside it, and then code and data are transferred.

The theoretical upgrade process runs as follows: the tool first transfers the code (custom modifications), and developers then resolve any conflicts. On the upgrade day, the tool automatically transfers production data from Dynamics AX 2009 into the preconfigured Dynamics AX 2012 environment.

In practice, none of the above steps go completely smoothly, and many issues need to be addressed. The upgrade must be rehearsed repeatedly (“dry runs”) until it runs flawlessly — this is essential for completing the upgrade within the planned timeframe.

A separate chapter concerns the transfer of code. The ideal approach is to merge all customizations in Dynamics AX 2009 into a single layer (not mandatory, but time-saving). Changes in certain objects cannot be transferred by the tool and must be reimplemented manually. Microsoft’s documentation in this area is incomplete, but an experienced vendor has the necessary know-how. Conflicts in the target environment must then be resolved (the number of conflicts can be reduced by preparing the code in Dynamics AX 2009). At the end of the process, further analysis and development may be required depending on how customized objects changed in the SYS layer.

Microsoft’s code transfer documentation is incomplete, so only an experienced vendor can execute a successful upgrade.

After code transfer, data migration must occur. Ideally, data transfer should be fully automated. In reality, however, the tool cannot always handle database inconsistencies, misconfigurations, and other irregularities. Some of these can be fixed by developers, while others require consultation with the client (business data). Unlike code, data transfer cannot be done in advance — it can only be tested in a trial run. The process begins only after the client shuts down their production system. During the upgrade, you may face several challenges, such as:

• Upgrading a system in a poor state (uncompiled customizations in all layers and an inconsistent database)
• Solving issues that even Microsoft has no documentation for
• Developing custom tools specifically for the upgrade (e.g., a tool for conflict reduction through code preparation in Dynamics AX 2009)

In the near future, upgrading to Dynamics AX 7 will become an important topic. Although the ERP system Dynamics AX 7 has not yet been released, it is likely (based on information from Microsoft’s community site) that a direct upgrade from Dynamics AX 2009 or earlier versions to AX 7 will not be supported. Upgrading any older version to Dynamics AX 7 will likely require an intermediate upgrade to Dynamics AX 2012 R3 — the only version from which the latest upgrade will be possible. We already master the first step and will learn the second as soon as Dynamics AX 7 is released.