Prepare for go live

  • 5 minutes

The go-live phase is the final step in your upgrade journey. This phase is when your new system officially becomes the one that your organization uses daily. To ensure a smooth transition, you need to lock down any last-minute changes, confirm that everything works as expected, and have a clear plan in place for handling issues that arise.

This section goes through key go-live readiness steps, such as freezing code and configuration changes, categorizing bugs, and running a final cutover test, so that you can go live with confidence.

Code freeze

At the code freeze stage, you should put all code changes in your AX 2012 environment on hold. To handle critical issues that occur, put an escalation process in place. As a rule, new code updates should go into the new system, not AX 2012.

If someone suggests a code change in AX 2012, management should discuss and approve it. Additionally, if a change goes into AX 2012, you need to apply it to the new system to keep both environments aligned. Keep in mind that you might need to run another round of cutover and functional testing.

Application configuration freeze

Similar to the process with code, you should also freeze application configuration changes in AX 2012. The reason is because even small changes can impact how the new system works or can interfere with your data upgrade scripts. Usually, these types of changes involve how the system functions and behaves.

Because system administrators or a few trusted super users often manage configuration changes, you don't need to lock down anything through security roles. Instead, make sure that everyone involved understands the freeze and follows the agreed-on business process. Also, security access changes (such as updating roles or reassigning users) can count as configuration changes and might affect the upgrade.

Final cutover test

When you're confident that no more code or configuration changes will occur, you can run the final cutover test. This test is your chance to confirm that all your upgrade steps, including data and code, still work as expected.

Make sure that you run functional testing on the most recent copy of the upgraded environment. This step helps confirm that everything is still working as expected after the latest code and configuration changes.

As you go through testing, you should sort any bugs that you find into two categories:

  • Blocking bugs – These bugs are serious obstacles. If you find one, the upgrade project needs to pause until it's fixed. Also, you need to rerun the cutover test afterward. A bug falls into this category if:
    • It stops a critical business process from working.
    • No workaround or temporary fix is available.
  • Non-blocking bugs – These bugs areless urgent. The upgrade can move forward, and you can fix these issues later, directly in the upgraded system.