First of all: This is not about updating from AX 2012 to AX7 (though there are a lot of similarities). I might well cover that sometime. If you’re interested in that particular topic in the meantime you might want to have a look in the official Wiki and visit the tutorial Prepare to migrate to Microsoft Dynamics ‘AX 7’.
This article is about bringing custom code and artifacts from one AX7 version to another. Just before Christmas we finished upgrading our ISV solution named gevis ERP | AX from CTP7 to CTP8. CTP is short for Community Technical Preview and therefore, of course, everything I show still might be changed until the official release of the new Microsoft Dynamics AX. So here is how it works.
Connect LCS project to VSTS
You need to have a LCS project (that relates to an ‘AX 7’ methodology) and make sure it is connected to your Visual Studio Team Services (VSTS – formerly known as Visual Studio Online / VSO) properly. Authentication recently was changed from something called Alternate credentials to Personal access token. If you have an existing AX7 LCS project you might have to update. You can generate a token in VSTS by moving to your profile (click your name on the upper right and then My profile) and switch to Security. Use the Add control to create a new personal access token.
You have to provide the Visual Studio Online site URL first, besides the token (which is text that needs to be copied there) and choose the right project then.
Use the Code Upgrade Service
In your LCS project there’s a tile called Code upgrade. First you need to create a new code upgrade project by using the Add button at lower left. Give it a useful name and add a description if you want. For minor upgrades you have to chose Microsoft Dynamics AX 7 as Version.
There’s an option for Estimation Only. If you select this the tool does all the analysis etc. but does not commit anything to your version control’s repository. So this would help you to get an estimate on the effort that needs to be spent.
The tool always works against your /Trunk/Main branch, therefore you do not need to specify the version of AX7 you’re using more specifically. Actually the tool uses the file $/YourAX7Project/Trunk/Main/ax7.version to identify the current build.
After the code upgrade service connected successfully to your VSTS you have to start the processing by clicking Analyze code in the lower right corner.
Now the tool does all the magic and needs quite some time for that (approximately two hours for our last run). It comes with a progress bar that sometimes gets updated. If it seems like nothing happens at the beginning stay calm – if the service is busy you might be in queue still, or the progress simply is not reflected yet.
When the Code Upgrade Service finished
The code upgrade provides you with detailed Excel reports right away. The MigrationSummary.xlsx_ExcelReport contains information about overlayered objects, auto-merged objects and conflict counts plus form pattern coverage information and details about objects that were converted to extensions automatically. The TaskList.xlsm_ExcelReport contains all the tasks that were committed to your VSTS (if you didn’t check Estimation Only) and a summary that tells you even an overall estimate of the manual effort in hours. As a matter of fact, from our experience the tool’s guess is not too bad.
In addition there’s a .zip file that contains all the upgraded metadata and two more very small text files, one containing the build version information (here: AX7 metadata version 7.0.1186.16043_ExcelReport) and one that lists the models (Models upgrade_ExcelReport).
Work items in VSTS
The Code Upgrade Service does not just upgrade your code but also helps you with the work that needs to be done afterwards. It creates task work items in your VSTS project that point to the objects that need to be handled manually. There’s information about what needs to be done exactly and the estimated effort for it as well.
Merge the Branch
The Code Upgrade Service didn’t change anything in your /Trunk/Main branch but created a new one under $/YourAX7Project/Releases/. To bring your Main branch development to the new version you need to merge the branch manually. You can do so by right-clicking the branch folder (in case of our CTP8 upgrade $/YourAX7Project/Releases/7.0.1186.16043_CTP8_2015-12-18T14.33.06, for example) and select Branching and merging / Merge…. You’ll want to include All changes up to a specific version and use /Trunk/Main as target branch. The following steps can be left to their default values. As a result you’ll get pending changes that need to be checked in to version control.
Tips and tricks
Ongoing work on the older version
In a multi-developer scenario of course there is the issue of open development work at the time of the upgrade. We solve this by first of all encouraging everyone to not have too much open work (you can regulate that a little by not starting with very complex tasks prior to the announced upgrade time) and – more importantly – not letting anyone check in anything in the time between the code upgrade tool started its processing and the commit of the pending changes of the merge. We even stop check ins until the manual code merge is done. Work that gets finished (on the former version) in between needs to be shelved and checked in later – possible incompatibilities then would get apparent.
If you’re working with development projects (Visual Studio solutions) in /Trunk/Main/Projects/ you might want to either be careful with or even (we do so) skip the merge of $/YourAX7Project/Releases/7.0.1186.16043_CTP8_2015-12-18T14.33.06/Projects because this potentially removes all of your stuff and puts generated projects there. Therefore we only merge the Metadata folder in the first place. If you decide to do so as well it is extremely important you take care of the file ax7.version, too! It would need to be merged additionally then.