Hello all - I wanted to give out a sample look at some additional documentation that we have recently released to help build understanding of the planning required to have a successful upgrade to Microsoft Dynamics AX 2012. This section talks about some of the core items to think about as you prepare to create a project plan for the data upgrade. The Microsoft Dynamics AX 2012 Data Upgrade Best Practices document has been released and can be found at (http://go.microsoft.com/fwlink/?LinkId=238709) has specific performance tuning information for the various phases of the data upgrade. In the near future, I will be posting other content around upgrade in more specific areas, such as issues commonly found with virtual companies. If you have specific topics of interest, drop me a mail or leave a comment and I'll do what I can to help build the knowledge around upgrade around our community.
Any project involving a data upgrade to Microsoft Dynamics AX 2012 is a very large and complex undertaking, regardless of the size of the source database being upgraded. Some of the primary variables that drive the complexity of the data upgrade include:
Many of the individual lessons that follow have specific performance suggestions that require changes to settings to improve efficiency. The following guidelines listed here are more general in nature, and help define a plan for the upgrade prior to beginning the process.
Start investigations required for code upgrade. Before you begin your data upgrade you must begin analyzing all customizations and create plans for your code upgrade. All customizations should be evaluated to see if they are still necessary in Microsoft Dynamics AX 2012, or if a complete refactoring is required. This includes working with your Value Added Reseller (VAR) and Independent Software Vendors (ISVs) to ensure they have the necessary upgrade scripts in place for your upgrade.
The planning must include writing data upgrade scripts required for your customizations in order to proceed with the various sections of the data upgrade. Examples of the types of upgrade scripts required for the various phases are:
Purge and Archive data with the Dynamics AX Intelligent Data Management Framework (IDMF). Prior to upgrade is an excellent time to consider purging and or archiving data from the production Dynamics AX database. Any data purging or archiving must be in line with your data retention policies. See CustomerSource for the tool download information. (https://mbs.microsoft.com/customersource/downloads/servicepacks/ax_idmf.htm?printpage=false)
Analyze space requirements for databases: Prior to running the data preparation and preprocessing scripts on the source version, the size of the source SQL database and transaction logs should be increased considerably (by at least 35%) in order to ensure enough space to prevent costly database resizing during these operations. Investigating the actual growth on a test run will give a much better idea of how much additional space should be allocated to the database and log files.
A similar investigation needs to be made to determine the proper size for the Microsoft Dynamics AX 2012 database. A rough estimate to use as a starting point for determining the size would be 30% over the expanded size of the source database.
The TempDB database size should also be increased and monitored during a test run for performance and recommended sizing for the upgrade. A rough estimate for sizing your TempDB database would be 20-25% of the expanded Microsoft Dynamics AX 2012 database. Optimal performance may require splitting the TempDB database into separate files. See the article Optimizing tempdb Performance on MSDN for more suggestions.
Microsoft Dynamics AX 2012 does not support Oracle. To upgrade an Oracle database, use the Oracle to SQL migration tool (on Microsoft Dynamics AX 4 or Microsoft Dynamics AX 2009) first then upgrade the SQL database to Microsoft Dynamics AX 2012. The migration tool can be found here on CustomerSource:
The key to having an optimal data upgrade experience is to plan well in advance, run multiple test cycles building on lessons learned, and then plan the live data upgrade in complete detail which builds in time for unexpected last minute issues.
Please note the Microsoft Dynamics AX 2012 Data Upgrade Best Practices document has been released and the link is now provided at the top of the article.
Thanks for the information and it's really useful for me when i am doing my upgrade.
I need little clarification Kevin,
When doing data upgrade from Ax4/5 to Ax6, Will it get all the setup's data also from source machine to target machine (like Dimensions, Chart of accounts). Since i am unable to see the setup's available in any module until i set manually. Because of this i am unable to get the information from Tables to Forms (Data is still available at table level).
If the setup's also need to come up with data upgrade what are the steps need to performed. Did i need to run the checklist again in Source machine?
If possible could you please help me
When doing the upgrade, yes all setup information should also copy from AX 4/2009 into AX 2012. However, several of these tables would have required you to make some choices in the AX 4/2009 upgrade checklist related to Preparing your data for pre-processing.
Another common reason for not seeing information inside AX 2012 is that the table had mapping errors that were not addressed - such as having a field that is not mapped from the source database to a field in AX 2012. If any mapping errors exist, the entire table is not copied. You can check the Generate Table Mappings window to find out what might have been missed.
Thanks for the response Kevin.
I already ran full checklist in both Target and Source.
I scenario i came across here is, in 'Release Order' form in Production module, the setup's like Storage, tracking dimensions, Item group and item model group are not set to particular items directly in upgrade.
I need to release the item to 'Release Order' form manually and set all these mandatory setup's manually while releasing. I have around 3000+ items in my inventory and all these are need to released to particular company manually..!
as per your suggestion, I will try to run the checklist in target machine to see the mappings errors.
My concern is, that the functionality of the 'Release order' form.. to release the items again newly & manually..?
If you are using Virtual Companies to share information such as the InventDimSetup or InventModelGroup tables, then there may indeed need to be changes made to your ugprade scripts to account for this information being shared among several companies. That is the most common reason for not seeing those fields set when you look at the products inside Dynamics AX 2012.
I have on my to-do list an idea to blog about what script/process changes are needed if the InventDimSetup table is shared, and I will try and prioritize that one a little higher. In the meantime, this type of question would be better managed through a support incident where an engineer can work with you to look at your system in more detail.
Thanks for the Responce.
I will try to implement your suggestion. Looking forward for the Blog.
One more similar issue i am facing here is, the 'MainAccounts' and 'offsetAccounts' of posting transactions of the 'GeneralJournels' are not upgraded to target machine.
We investigated the issues, we found that the few of the table data is missing i,e Dimensionattributevaluecobination Table. Few records are missing here.
The 'ledgerdimension' fiels of 'Ledgerjournaltrans' table’s records are not present in the 'dimensionattributevaluecombination' table.
i,e 'Ledgerjournaltrans' .Ledgerdimension == davc.recid
I tried to Crete the records manually, since the 'hash' key in that table is Unique, i am unable to insert the 'hash' key value in the table.
FYI: I am able to create one record manually and able to see the main account of the one particular posted transaction in Journals.
So tried to do the same for the second record but it's not allowing since the 'Hash' key 'NULL i.e. the value is system generated and it is unique.
Please suggest the best approach to resolve the main account and offsetaccount issue.
Thanks in Advance.
If you find a few very specific examples of this behavior after upgrading, the best method is to go into a transaction window and create a transaction using the same account/dimension combination. Then find the new row in the DimensionAttributeValueCombination (DAVC) table and get the RecID value. Then do an update of the original table that is pointing to a missing DAVC value and change its dimension field to be the RecID of the newly created record.
If you have many instances of this problem, then there is likely something wrong with your upgrade scripts that should be investigated and fixed.