Lifecycle Services: Upgrade Analysis
I’m continuing my tour through the Lifecycle Services capabilities – they keep releasing more good stuff every month, so it’s hard for me to keep up. Today we’re covering the Upgrade Analysis feature which (to me) is a must-use feature if you are considering an upgrade from 4.0, 2009 or an in-version upgrade to 2012 R3 from an earlier version of 2012. I’ll show the results from one of our customers who used the solution, and it gave us a great sense of what needed to be done for the upgrade to be successful.
Here’s how to use the tool. To take advantage of the Upgrade Analysis functionality within Lifecycle Services, create a new project with Upgrade as the Project Type. (This can only be done by Customers). To learn more about how to create a project, refer back to my Lifecycle Services overview page at https://stoneridgesoftware.com/lcs.
As you can see from the instructions here, on AX 2009, you would install the AX 2012 Rapid Data Collector in your environment as part of the process to collect the code. You’ll also need to upload your AOD files so the system can parse through them and provide feedback on what needs to be changed when you get to 2012.
For earlier versions of AX 2012, you’ll just upload a compressed model store. Generate that model store from your production or UAT environment.
Once you’ve uploaded the file (this example shows an AX 2012 upload), you’ll receive an Excel report which provides analysis on the amount of customizations that need to be upgraded. You can also see how long it takes a file to be analyzed as this was a fairly large (377 MB) model store.
When you click on the Excel spreadsheet, you’ll see 8 worksheets that provide information about the compilation errors that will occur (you’ll see Syntax errors and references to tables that don’t have fields you need, etc.). This report on the first page of the spreadsheet gives you an overview of how much effort will be going in to the customization upgrade:
You can see this customer had many ISV customizations that need to be reviewed (so we reached out to their various ISVs to get R3 compatible code), plus a few customizations in the VAR layer and quite a few in the CUS layer. Based on this, we were looking at 4-6 weeks to upgrade their code to the latest version.
The Upgrade Analysis tool is a great tool to give you a sense of the effort level associated with an upgrade. I highly recommend using it to gain more information before you proceed forward with the upgrade.
For more information, review the Upgrade Analysis article on TechNet. It’s a good article that explains some things I didn’t touch on here in more detail.
We’ve done a few R3 upgrades now and we’re working on a few more, so if you’re looking to make the move, let us know if we can help.