AX2012 – The Complexities of an upgrade

Project managers and clients don’t really understand the complexities of upgrading an environment to a new Roll-up / CU version.  Well, how difficult can it be?  And why can’t it be done right now?

Well, usually it is not a problem.  As a developer you compare your code, if changes were made on existing objects and make sure you merge the new code with your code.  And everyone is happy.

However, what happens when you have other partner products on your AX Environment.  What if those products were build for a different Roll-up / CU version.  Now suddenly it becomes a whole lot more complicated to do the upgrades.

At some of our clients, we have had to merge code over 4 to 5 layers.  You can easily lose your head with a merge, especially with methods that are quite large.

Let me explain this with an example:

On the Class: \Classes\CustVendCreatePaymJournal we’ve create a new variable in the Class Declarations on the CUS Layer.  We’ve also installed a partner product (on the VAR layer), which  also created a new variable in the Class Declarations.  As part of the normal merging process, we made sure we merge the Variable back into the CUS Layer.  Microsoft also created some methods on the class both on the SYS and SYP layers.  All of these changes were done on AX2012 R3 CU8.  Everyone is happy…

We received a request from the client to upgrade to the latest CU version (CU10) ASAP.  We notified the client that not all of the partner products are available on CU10.  Our client told us to still continue with the upgrade.

With the upgrade, Microsoft made some changes the the SYP layer.  As part of the merging process, a developer usually compare the first layer in our case the CUS layer, and the layer just above it, i.e. VAR layer in this example.  However, by doing this we are missing out on any changes that might have occurred on the SYP layer, thus causing compile errors, because the variable for the SYP layer was never linked in the code.

Well, what is the problem then.  Well, in some environments we have code changes in methods that have 100s of lines of code.  You then have to compare your custom code with the changed layer (SYP), compare it with the changes on the ISV, ISP, VAR, VAP layers (and yes we do have clients with these setups).  And finally you have to apply the combined merge on your CUS Layer, which can get quite complicated, especially when the changes were not property commented in code.  remember now, the ISV, ISP, VAR and VAP layers also contain their own code custom code, which was created for an older CU version.  You can not easily identify the SYP changes, because it might actually changes on top of the SYP layer, which will not provide you will a clear indication of the change.

Lesson learned:

Wait for all products / to be upgraded before you try to upgrade your own code to the new Rol-up / CU version.  That way you will not have to try and figure our code changes over multiple layers.


About Johan Groenewald

I'm a Microsoft Dynamics AX Developer, working at Axnosis in Pretoria, South Africa, with over 15 years experience as a software developer and working for the past 5 years on Dynamics AX 2009 and 2012.
This entry was posted in Microsoft Dynamics AX 2012. Bookmark the permalink.

Leave a Reply

Your email address will not be published.