A Dynamics AX implementation is a big investment. Post implementation, organizations spend thousands of dollars on maintaining and extending the system on business process improvement projects to gain the real ROI of the new platform. At the same time, Microsoft invests millions of dollars on its research and development organization by using leading-edge technologies for platform and functionality improvements, which enable new features within their core product.
An upgrade enables the customers to get these functionality and technology improvements by moving to the latest versions. At the same time, upgrading to new versions can be overwhelming and can cost significantly high in terms of dollars, critical resource time, and potential business disruptions.
Dynamics AX or any ERP upgrade is not like a Windows upgrade where you start the upgrade and your system backs up on the new platform in a few hours. Upgrading of an ERP system requires extensive planning, preparation, and resources. It can take a few months to several years for this project, which largely depends on the number and type of customizations, changes in the core product (difference in the versions that you are upgrading), and the volume of data that you have.
The decision to upgrade is not easy. On one hand, you want to keep up with technological improvements and utilize the new features; on the other hand, Microsoft keeps releasing new versions (with major changes) of the product every 2-3 years. The change in operations and functionalities so often makes it hard for the business to adapt.
In this chapter, we will cover the following topics:
- When to upgrade
- The upgrade options
- The Dynamics AX upgrade process
Upgrades aren't necessarily a good or bad idea in general, but it's important to carefully examine and evaluate the pros and cons before embarking on an upgrade project. The following sections mention a few considerations to keep in mind before an upgrade.
You should not just upgrade or implement a new technology platform. Instead, there should be a clear benefit to the business by upgrading to a new version. A thorough analysis of the new features that can be useful for the business needs to be done, and a vision scope for the upgrade should be put together. Some of these features may be new for the business while some could replace your existing customizations or third-party systems. The benefits could include new features and functionalities, increased efficiency and productivity, and transparency through better reporting. The benefits should also justify the time and cost required to execute the upgrade project. A proper roadmap to realize the benefits and returns on the investment should be established.
Change is not easy. Upgrades often bring new user interfaces, functionalities, and processes with them and it's not easy for the business to tackle these changes. The following are some key considerations:
- Identify the competing business projects that would have to be reprioritized or delivered as part of the upgrade. Opportunity cost needs to be evaluated (as you would have to redeploy the IT/business resources and run into code freeze as part of the upgrade project).
- Upgrade is not a technology project and needs good involvement from the business. The business should be ready to commit resources for the upgrade project.
- Conduct an independent post-implementation review, and scope out what you would want to fix from the initial implementation as part of the upgrade like redoing specific customizations, redefining the product structure, redefining the legal entity structure based on business needs (like splitting sales and distribution companies), and so on. The lessons from the previous project should be defined to ensure that you are doing things differently this time for a better outcome. Changing only the VARs is not going to fix the fundamental issues.
Our friends at Microsoft are not going to like this section. However, in reality, it takes a few months for any new release to stabilize. You wouldn't want to get burned with early-on product issues as part of the project, or let the business be affected due to the issues in production.
- If you choose to be early adaptors, ensure you have enough support and blessings from your partner and the Microsoft team, in case you run into issues.
- We would strongly recommend getting a BRAP support plan. This would allow you to open an unlimited number of tickets to resolve issues. These issues may be due to bugs in the product, undocumented settings, or features that are causing noise, learning curve for the consulting and implementation team, and so on). However, getting help from Microsoft would help reduce the implementation team's time on such issues, and ultimately, help deliver the project on schedule.
- For newly released modules, try to defer the implementation post upgrade until it is mature/stabilized enough. For example, when Dynamics AX 2012 R2 was released, the budgeting module was released as well. I would have planned to implement it post upgrade rather than along with the upgrade.
- You shouldn't wait too long either, and upgrade in the later part of the product lifecycle when Microsoft is about to release the next version.
For many organizations, this is one of the key reasons for upgrade. It's important and critical for the customer to have continued vendor support and assistance if something goes wrong. For Dynamics AX, Microsoft provides mainstream support for five years or two years, whichever is longer, after the successor product is released. Microsoft also provides extended support following the mainstream support for five or two years, whichever is longer, after the second successor product (N+2) is released. The customer can go for extended support but you must know that upgrading to the latest version gets more and more complicated if you skip many major versions.
Sometimes, it might be better to plan a fresh implementation of the latest version than upgrading from the old version. The following are the scenarios where reimplementation can be a better approach rather than upgrade:
- There is no direct upgrade path if you missed upgrading to several of the last version releases. For example, a customer using Dynamics AX 3.0 or 4.0 cannot directly upgrade to AX 2012 R3. They need to upgrade to AX 2009 first, and then they can upgrade to AX 2012.
- Structural changes between versions and lost opportunity due to upgrade: For example, AX 2012 had major structural changes in the Dynamics AX data models as compared to the previous versions; a lot of normalizations and improvements were made to support the scaling and performance improvements. The customers upgrading from the previous versions could not take full benefit of some of the features such as, the shared chart of accounts and dimension structure. Considerations need to be made for any potential limitations due to the current data and upgrade process.
- When you have heavy customizations, several of the customizations can be eliminated and replaced by the standard features.
- If the data quality of the current system is bad and it would require too much effort to clean the data to prepare for the upgrade.
- If there are changes in the fundamental master-data elements. For example, moving away from smart product numbers or implementing the product structure differently using product dimensions, changes in inventory costing, changes in the legal entity structures due to business reasons like splitting distribution, manufacturing, and sales companies.