If you are preparing to upgrade to a newer version of Dynamics AX, it may be helpful to review some best practices, which can streamline your project and avoid problems. Microsoft and its partners have developed a body of knowledge and tools that can be helpful. The following points to consider are outlined as follow:
- Analyzing Customizations
- Purging and Archiving Data
- Analyzing Database Space Requirements
- Creating Project Plans for Testing
- User Acceptance Testing and End User Training
- Downtime Window Project Planning
- Upgrade Execution Planning
- Preparing Source Database and Application Object Server (AOS)
- Using a State Transfer Tool
- Preparing Targets—Database and AOS
- Inheritance Table Considerations
Analyzing Customizations
Many companies have expanded the capabilities of their AX instance with customizations. Whether created by you or a Microsoft partner, these customizations should be evaluated in relation to the functionality of the latest release you are upgrading to. New releases can include new capabilities, which can override or eliminate a custom application. In the event your AX customization functionality is required after the upgrade, make sure upgrade scripts exist, or now is the time to plan for their creation. These should include readiness tests, preprocessing and delta scripts, and data upgrade scripts.
Purging and Archiving Data
Prior to upgrade, we recommend that you consider purging or archiving data from the production Microsoft Dynamics AX database. The Intelligent Data Management Framework for Microsoft Dynamics AX (IDMF) is a tool that you can download from Microsoft Dynamics Information Source.
Analyzing Database Space Requirements
Analyzing and adjusting the space available for your databases can significantly improve performance during data upgrade. If you do not increase the size of the databases, database resizing occurs during the upgrade and significantly slows down all operations. You should increase the new database by at least 35% and monitor the temp database during testing as optimal performance may require splitting the database.
Creating Project Plans for Testing
A detailed project plan should be created and include tasks, planned time, and actual time required. This should include all tasks for source and target systems and can provide a performance change history log. This plan should be a controlled document with review and approvals for each change, and include the capture of reasons for revisions. Your organization may have a template as a starting point or your Microsoft partner may be able to assist.
User Acceptance Testing and End User Training
Be sure to build sufficient time for user acceptance testing as it may require troubleshooting and project plan adjustments. Functional changes, whether through new AX core capabilities or to the custom applications, may require additional time for end user training before cutover.
Downtime Window Project Planning
A step-by-step sequence of tasks for the actual downtime period of the upgrade will assure there are a minimum of surprises. It should include security testing, end user acceptance testing, data transfer and validation, and process transfer and validation. All scheduled processes (daily, weekly, monthly) should be captured within your reports and dashboards.
Upgrade Execution Planning
The most important factor in a successful data upgrade is to create a detailed plan and run multiple test cycles. Make sure to validate data transfers, and adjust the upgrade process as needed as well as taking database backups for each step of the upgrade process. Monitoring performance and identifying bottlenecks should also be incorporated into your plan.
Preparing Source Database and Application Object Server (AOS) Instance
For this step, consider reviewing the available best practices for configuring and installing SQL server with Dynamics AX (available from Microsoft). Also, consider implementing trace flag 4199 as this will enable several Dynamics AX performance enhancements. Plan to increase the frequency and size of the transaction logs and use the performance analyzer for Dynamics to identify points of index tuning or changes to code. Creating frequent database backups before and after making database configuration changes should reduce recovery time should errors be encountered. A separate AOS instance is highly recommended. Setting buffer and thread values should be evaluated for each distinct instance.
Using the State Transfer Tool
The state transfer tool is designed to reduce the amount of upgrade preprocessing on a production system. The state transfer tool is useful to offload the live upgrade preprocessing task to a test server. It is important to note that the use of the state transfer tool requires integration into the project plan and is not an ad hoc utility.
Prepare Targets—Database and AOS
Common points to consider at this stage are database sizing for the target and TEMPDB (usually 30% larger), impact of network latency, and the impact of separate servers and rebuilding indexes as the end of result of this stage they are likely to be a highly fragmented.
Inheritance Table Considerations
With the release of AX 2012, table inheritance was introduced and the base and derived tables were physically separated. In AX 2012 R2, derived tables were removed from SQL server. These are now stored in the base table and may affect how to upgrade customizations.
Contact us for more information about how OnActuate can support your Microsoft Dynamics AX upgrade .
