This article provides Ax technical consultants step by step procedure of executing Microsoft Dynamics Ax 3.0 to Microsoft Dynamics Ax 2009 SP1 upgrade. It also suggests some steps which can be followed for enhancing the upgrade performance.
If you are on an Ax version older then Ax 3.0 than you first need to upgrade Ax to Ax 3.0 / 4.0 only than you can take it directly to Ax 2009 / Ax 2009 SP1.
Although this article describes Ax 3.0 to Ax 2009 SP1 upgrade path but you can also find it useful if you upgrading from Ax 4.0 to Ax 2009 SP1. The procedure for upgrading from Ax 3.0 and from Ax 4.0 differ primarily in the amount of preparation required for data upgrade. Upgrading from Ax 3.0 requires additional steps.
It is divided in two parts, Code Upgrade and Data Upgrade. You can do both these steps in one go but I will say go one by one, starting with code upgrade first and then moving to data upgrade.
Security rights needed
User performing upgrade process must have Administrative rights.
Here in this process you upgrade your customizations that you have done over the standard Ax 3.0 system. A best Ax custom technical design is which affects standard Ax objects at minimum and keeps everything in itself. So, try not to modify Ax standard objects for your customizations, instead create your own objects for the purpose. This way your code will be less affected from a new Ax release. Ok, enough said, now let’s start the code upgrade.
Note: The layers mentioned here only exist if customizations have been made.
- Install Ax 2009 without starting the AOS.
We don’t want to start AOS after installation, so clear the Start the AOS instance after installation is completed check box.
- Install Ax 2009 SP1 without starting the AOS.
- Install latest Ax 2009 Role-UP if you want to, without starting the AOS.
- Install any other Microsoft Dynamics Ax 2009 solutions. For example if your Ax 3.0 instance uses Professional Services Automation (PSA) and you also want to upgrade this, than you need to install latest PSA for Ax 2009 SP1 now without starting the AOS. This also applies to any other third party solution you want to upgrade that have their Ax 2009 SP1 version ready.
- In order to compare Ax 3.0 application code with your modifications to the Ax 2009 application code, you must create a folder named “Old” in the current application folder of your upgrade environment, (Microsoft Dynamics AX50ApplicationApplInstanceNameOld). Copy all Ax 3.0 application files (*.aod, *.ahd, *.ald, *.add, *.khd) into the “Old” folder.
Note: In our case, folder OLD is automatically created when you installed Ax 2009 SP1. While copying files into OLD, select overwrite existing files if it is asked.
- Copy Ax 3.0 application files (*.aod, *.ahd, *.ald, *.add, *.khd ) from layers above the DIS layer (BUS, VAR, CUS, USR).
- Paste all these files in the standard Ax 2009 application folder (Microsoft Dynamics AX50ApplicationApplInstanceName).
- Start AOS. To start AOS, go to Windows–Start–Run, type services.msc and press enter, look for a service called Dynamics AX Object Server 5.0$InstanceName. We have specified the AOS name at the time of installation. Start this service.
You may receive one or two warning messages saying Service could not start in timely fashion. Please ignore these messages and wait for the AOS to start, it may take some time depending on your application size.
AOS will create index files (*.aoi) for standard and OLD application.
- Start Ax 2009 client. An installation checklist will come up on startup.
- Compile application. Ignore errors for the time being.
- Load Ax 2009 license.
- Synchronize etc, etc
- Now it’s time to detect and resolve code upgrade conflicts between Ax 3.0 and Ax 2009 SP1. An upgrade conflict exists when code in a previously installed version differs from code in the new version.
If you have modifications on more than one layer, upgrade layers one by one. You should start with the lower layer first. For example if you have customizations on BUS and VAR, upgrade BUS layer first then VAR layer.
- Close Ax 2009 and open it again in the layer you are going to upgrade first. For example, to upgrade VAR layer you need to have Ax client configuration setup with VAR development code.
- To resolve your code upgrade conflicts, you can use any of these.
Detect Code Upgrade Conflicts Tool (I prefer this for code upgrade)
Compare Layers Tool
- In Ax, run Microsoft Dynamics Ax–Tools–Development tools–Code upgrade–Detect code upgrade conflicts.
This tool analyzes customizations for code upgrade conflicts and creates one or more upgrade projects.
It will create a private project for conflicting objects, called *LayerConflicts. Inspect the conflicts in the Layer Conflict Project. Resolve some of the conflicts using the compare tool. Rerun conflict detection and check if the number of conflicts decreased.
- Compare Layer tool can be used as an alternative to Detect code upgrade conflicts tool. Run Microsoft Dynamics Ax–Tools–Development tools–Code upgrade–Compare layers, to compare any two layers and create a project with the objects that differ. The Compare layers tool can provide an overview of modifications made in a certain layer.
- After identifying objects with code upgrade conflicts, you can run Compare (Ctrl+G) tool on selected object to resolve code upgrade conflicts between two layers.
This tool is used to compare an object on two layers. For example, if you are upgrading BUS layer than compare your objects with the immediate lower layer and resolve conflicts. This tool always selects your current layer with red color drop down list and the immediate layer in blue color. Each layer modifications are shown in different colors. For more information about this tool, click here.
- After resolving code upgrade conflicts, compile your application and resolve compilation errors if any.
- Test your functionality.
- Start Data Upgrade.
Feel free to post your feedback / comments / queries here.