In the previous post I introduced to the Microsoft Dynamics AX 2012 Data Upgrade process, tasks involved in the Data Upgrade process along with some key points which must be considered before and during the upgrade process, which can be referenced by the link below:
In this post I will be covering the data upgrade process in the Source Environment (i.e. AX 4.0 or AX 2009) from technical point of view, and share some experiences which I faced during the Data upgrade at a client who was moving from AX 4.0 to AX 2012 R3 along with the common issues and fixes which are required during the Data upgrade process specially related to data readiness, virtual companies along with some tricks to handle and fix the upgrade readiness issues etc…
Starting Data Upgrade on Source System
The common practice is to start the upgrade process on a test system first by setting up a test machine with AX 4.0 or AX 2009 and once the environment is ready then Restore Production backup over AX 40 or AX 2009 test environment database and Set the test system database Recovery Mode to SIMPLE.
Once the Test system has become the exact replica of the production system install the Upgrade Framework XPO in the source AX system
The Microsoft Dynamics AX 2012 upgrade process requires manual installation of three files on your source Microsoft Dynamics AX 4.0 or Microsoft Dynamics AX 2009 system. An XPO file provides the forms and scripts that are required for data preprocessing, an ALD file provides user interface labels, and a CHM file provides user Help.
More details about how to install upgrade framework files can be found on the below link:
Once the Upgrade frame work is all set up you can proceed with the Preprocessing upgrade check list in the Source system:
Open the Pre-processing upgrade checklist
After all of the needed XPO files have been imported, open the Pre-processing upgrade checklist as follows:
- Click the Project icon on the toolbar and navigate toProjects> Shared.
- Expand Shared and locate either Ax40PreUpgradeFramework or Ax50PreUpgradeFramework, depending on the version that you are upgrading from. Right-click it, and click Open.
- Locate SysChecklist_preupgrade40 or SysCheckList_PreUpgrade50, depending on the version you are upgrading from. Right-click it, and click Open to start thePreprocessing upgrade checklist.
Note: To improve performance during the database-intensive upgrade preprocessing tasks, it is recommend that you apply the following parameter to the Microsoft Dynamics AX database before you begin:
Update RELEASEUPDATECONFIGURATION set NoCompanyDependency = 1
This setting prevents the execution of scripts from being delayed due to company interdependencies.
Starting up the preprocessing upgrade check list:
The first step in the source preprocessing upgrade checklist is Prepare for upgrade:
The first step in the source preprocessing check list it Prepare for upgrade, this step includes some performance improvement steps, data clean up, configuration of partitions along with the major task which is Check upgrade readiness.
Check upgrade readiness:
The check upgrade readiness step is basically the step in which the data readiness upgrade scripts are executed which validates the data in the source system and point out the issues which are there in the data which may cause trouble in the further upgrade process, the issues/errors identified by the check upgrade readiness must be resolved before moving forward in the upgrade check list.
The common validations which are performed by the readiness scripts are related to the missing data, illegal references, Virtual company considerations etc.
View and fix upgrade readiness issues:
The View and fix upgrade readiness issues task opens the Upgrade validation results form. Use the Upgrade validation results form as a starting point to resolve issues that are discovered when you used the Upgrade readiness form to run the upgrade readiness scripts.
Resolving upgrade readiness issues helps prevent failure of the upgrade later in the upgrade process.
The Upgrade validation results form and the Upgrade validation details form provide the information and tools that are needed to resolve readiness issues.
- In the Upgrade validation results form, in the Validation results grid, review the scripts that ran. Each script has a status of Incomplete, Pass, Error, or Advisory.
- Select a job that has a status of Error or Advisory in the Validation results grid to view diagnostic information in the Log grid.
- For more information about a record that appears in the Log grid, click the Details button, if it is available.
- To fix an issue for a record, click the Fix button and then enter any information that is required in the form that opens.
Fixing Readiness issues Manually :
If the Fix button is not available, you must either resolve the issue manually or write an upgrade script that resolves the issue. In order to manually resolve the issues the best approach to start is by opening the script by clicking on the open script button as seen in the below screenshot:
This will open the corresponding Readiness script which runs behind that particular validation, now simply modify the logic of the script or run it in your X++ job with the modified logic which will fix the issue.
For example: During an upgrade I got an issue as follow which was required to be fixed manually:
- Readiness error : The LedgerJournal Trans table contains a reference to an invalid VendTable record.
- Resolution: Create the corresponding VendTable table record.
To resolve this issue by running the same script logic with my custom logic to fix through a X++ job:
while select LedgerJournalTrans
notexists join vendtable
where vendtable.AccountNum == LedgerJournalTrans.AccountNum
//My Custom Logic to fix – Begin
vendtable.AccountNum = LedgerJournalTrans.AccountNum;
vendtable.Name = ‘*Temporarily created to resolve readiness error*’;
//My Custom Logic to fix – end
NOTE : The above code is just an example which demonstrates the approach which can be taken to manually fix the readiness issues, the logic to fix the issues may differ and in most scenarios also require functional decisions.
Virtual companies consideration:
Virtual companies are used to share data, such as setup and master table data, between multiple companies in the system. For a successful data upgrade it is very important to understand the virtual companies scenarios and their impact on the business processes because while upgrading from earlier versions i.e. AX 4.0 or AX 2009 to AX 2012 there are many architectural and process changes which can be effected if the Virtual companies are not handled properly,
For example : During an Upgrade from AX 4.0 to AX 2012 R3 at a client we found that their Inventory was Virtualized through virtual companies which was not recommended and may cause issues in AX 2012 functionality such as in their case the functionality of released product would be of no use if they keep their inventory virtual therefore after analyzing their inventory it was suggested to un-virtualize their inventory and related tables and of course it was a challenging task since the production system was required to be hit to fix such issue and to make sure that there is no functionality impact on the business processes.
Similarly there could be also different scenarios related to virtual companies which must be considered and some are covered by the standard upgrade scripts which are mentioned below:
The following list outlines the different areas where the upgrade readiness scripts handles the virtual companies:
- Upgrade Readiness Checks:
- Will identify all tables shared in a virtual company, and will suggest which Shadow tables need to also be shared
- Uses a built in table list to help signify which areas of the upgrade code already handle virtualization and which tables might need to be investigated for additional coding in the upgrade scripts.
- The same data may be processed more than once because of the shared tables
Before you upgrade, if you are using virtual companies you must make the following changes to their configuration:
- Make sure that the inventory dimensions table is not shared.
- Make sure that tables that contain inventory dimension fields are not shared.
The upgrade readiness scripts also validates the above scenarios related to shared inventory dimensions in case of virtual companies and identifies such tables and prompt to remove the specified tables and there corresponding shadow tables from table collection.
Once such tables are un-virtualized it is required to duplicate the data in all the legal entities which were part of that particular Virtual company in which that table was before removing from table collection because when those tables are removed from table collection and are un-virtualized then their data would be no more available in their relevant companies so to resolve this issue and to make sure that the data and business processes are not effected it is required to duplicate the data in all the legal entities which were part of that particular Virtual company.
Once the readiness issues are resolved then rerun the readiness scripts to verify that the issues are resolved.
At this point we have an option to use the state transfer tool, The preprocessing upgrade state transfer tool helps you minimize downtime during upgrade. The tool also helps you avoid putting an additional load on your production Microsoft Dynamics AX system while you prepare to upgrade it.More details can be found on the link below: