My AX 2012 Upgrade Project Plan - Development Phase - Code upgrade

So, here we are, finally to the phase where it all happens: The development phase!
By now, hopefully you got an idea of the criticality of planning and preparing for an upgrade knowing it is like a large change management project. Users are involved, expectations are set, risks identified and catalogued and developers have been held back from code to do research and study the target platform to better be able to make good design decisions for your upgrade.

Ok, since this is by far the largest part of the project plan, I will divide the development phase into two major workstreams:

• The code upgrade workstream, and
• The data upgrade workstream

There is quite good documentation on how to do the actual technical upgrade and I am not going to repeat that, my goal is to share with you how we actually did it. A complication for us, was the fact that we were still supporting our existing production AX 2009 system and that caused a moving target in terms of upgrading code. Our users did not easily accept a code freeze. We did finally get an AX 2009 code freeze 2 months into the upgrade. This was definitely unnecessary work and rework and you should try to avoid it and establish a code freeze early.

The code upgrade workstream
We divided the code upgrade workstream into 4 major categories:

• Clean and refactor AX 2009 code: In here we looked for obsolete functionality and  reports that could be removed first. Reduce the noise for the upgrade as we do not need to upgrade stuff we would not use in terms of legacy code, or code that was needed and now was available in AX 2012 out of the box. We were limited in terms of refactor prior to upgrade since our mandate was an apples to apples upgrade. Critical success factor - Eliminate as many customizations as possible if you don't use them or if they exist in the target version, less code to upgrade, less upgrade scripts, less headaches. The next big task was to start the upgrade the EDTs and Enums as per best practice. We intended to clean up reports, but decided to rewrite them all. The reason was that our reports were all stored procedure based SSRS reports, and we wanted a better reporting architecture that would support future upgrades so we "banned" the use of SQL in our implementation, and all reports use data provider classes or OData services. This effort paid off in our R2 upgrade and will on our next major upgrade.
• Upgrading tables - The next code to upgrade is in your tables and corresponding upgrade scripts. We found the upgrade scripts to work very well for us, but also realized that they are written to cover a breadth and vanilla install of AX. As you upgrade your tables to the new schema, you really need to have your developers do this with the upgrade scripts in mind, this is a side by side effort and needs to be reviewed often to make sure we do not lose data during the data upgrade phase. Another lesson learned from us is that we assumed the scripts were untouchable as designed, and found some bugs, some huge performance problems, but got good advice from our friends at Microsoft that these were open to be improved. Look for your largest tables and do a code review of their corresponding upgrade scripts to see if you can convert the row based queries to set based queries which will greatly reduce your source to target time window. Examples below:

Changed standard script to commit after every 1000 updates where while loops cannot be avoided



Changed standard upgrade script from row based to set based, reduced data migration duration from 55 hours to 5 hours

• Upgrade business logic - The next task is to address all your key processes and business logic. We used a tool we downloaded from informationsource to analyze the code for the upgrade and had about 500 patterns it could apply, think of it as a search and replace application for an upgrade. We did run the code conflict project and assigned this across all developers based on areas of interest and where they had most experience or done most research. Critical success factor alert - Code review, code review, code review! In a team with many developers, upgrading between versions, the knowledge sharing, lessons learned, interdepency analysis and impact of how patterns are implemented must be reviewed by the whole team regularly. We did not do this as well in the early stages, but it is an imperative for our team today, we have 2 team code reviews per week.
• Upgrade Reports - Finally, we had a dedicated team upgrading reports. Perhaps the area we thought would be of less risk or complexity, but it turned out to be a huge effort after all. We had to rewrite all reports, and we did have a lot of them unfortunately. We worked closely with the business to consolidate reports, and prioritize which were critical for go live as we knew we would not have all completed at the same time as we were going to go live with AX 2012. The lesson learned and benefit was that we did succeed in pruning the reports catalogue and also forced us to make a design architecture decision for our reports that was a future proof approach. Since then, we are now providing reports via Power BI, which I know someone requested a separate blog about. We are creating OData services and presenting them in PowerPivot and PowerView in our SharePoint power pivot galleries.

 

Below is the expanded project plan for the code upgrade phase. Basically, load your team with caffeine, have them bring their headphones and favorite music and go through the grind!

No doubt you may have specific questions, happy to answer as best I can :)

Next time, I will share the data upgrade workstream.