Dynamics AX War Stories by Andre

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 cod

Hello there, thanks for following the blog! In this blog, I am going to share with you our design phase for our upgrade. Now, it is perhaps not a traditional pattern design or solution design but more of an upgrade design. Most of the tasks in this phase are self explanatory, and I will just comment on some which were critical, and some that we actually did not complete as intended. To me, developing the project plan is the key exercise, the file the project is created on, quickly loses value as the project progresses and the rapid adaptation to change and unforeseen issues occur. Agile or Waterfall? We decided to go agile with Scrum rather than a more logical waterfall approach for an upgrade. In my opinion, agile is great at adapting to unknowns and waterfall is great when you know the exact scope. With an upgrade, we argued that since it was "an apples to apples" upgrade, that it was clear in terms of scope, but we also were aware that there were many unknowns to us an