Every technological system should be used in its best state. The decision and timing can be deferred but you should always try to be using the latest version. At the same time, the decision to upgrade is not easy; it's important to carefully examine and evaluate the pros and cons before embarking on an upgrade project. The following section mentions a few considerations to keep in mind before an upgrade:

• Benefit to the business operation: 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 to the business while some could replace your existing customization or third-party systems. The benefits could include moving operations from on-premises to the cloud, 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.
•  Are operations ready for the change?: Change is not easy. Upgrades often bring new user interfaces, functionalities, and processes with them, and it's not easy for a 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).
  • An upgrade is not a technology project and needs good involvement from the business. The business should be ready to commit resources to 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, such as redoing specific customizations and doing the customization through extension.
• Stabilization of the newer version: 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 that you have enough support and blessings from your partner and the Microsoft team, in case you run into issues. For newly released modules, try to defer the implementation post upgrade until it is mature/stabilized enough.
• Continued technical support: For many organizations, this is one of the key reasons for the 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. You 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. For existing customers of Dynamics AX, it would be good to know the maximum support duration from Microsoft across their version. The following are the various AX versions and their primary support deadline dates: