Dynamics AX War Stories by Andre

So, you did really good planning, you completed your upgrade iterations, you tested and tested and tested, and you now have business approval to go live ... Time to develop your Go-Live checklist! For us, the release checklist was a huge success factor. We did all our test upgrades during UAT on weekends, and our checklist was what kept a distributed team not only on track, but engaged and informed in detail about each task in the checklist. Our checklist was not what you would imagine in terms of the checklist in the upgrade cockpit in AX. Our checklist had to coordinate every task above and beyond the tasks in AX. That included coordinating with multiple people not from our upgrade team including operations, help desk, security, external entities with integration points and the business. For each day of the weekend release, we had individual and granular tasks with times and responsible team members. Our very first checklist for our first upgrade iteration had 22 items, our

So, we completed the walkthrough of how we planned and upgraded our AX 2009 to AX 2012. Remember how I emphasized that this is also a change management project because it will impact your users heavily during and on their initial performance with AX 2012. Although familiar in terms of process, it will look different. I write this and I am already thinking our next major upgrade, which due to AX moving to the cloud, will have a redesigned HTML5 UI (I assume). So this will apply for that upgrade as well. So, for this blog, I will break our final part of the project plan into two major phases: The Deployment phase (Training and Production Release) The Operations phase (Post go live support and operations) In terms of deployment, we were very focused in ensuring our users would be familiar and well trained in using AX 2012. In my previous blog, I shared with you the process of how we did parallel testing to ensure the system was production ready, but it also did

Hi there! Sorry for the long pause in writing. We have faced many high priority items this past month that has left me no time to continue this story. On my last blog, I shared with you the code upgrade part of the upgrade project plan. Of course, you will have your own code areas and you should make sure to have a task for each major code area of your application. I also found it quite beneficial to have your development team do some planning poker around each of them, discuss their estimates and concerns. I used a lot of those discussions to populate my risk register! Before we start on how we addressed the data upgrade, MSDynamicsWorld published a summary of 4 key steps to world class upgrade as recommended by Andrew Jewsbury from Microsoft, whom I had the pleasure to present with in last year's Convergence:  4 Steps to Completing a World-Class Upgrade to Microsoft Dynamics AX 2012 R3 . Here  is my part of the presentation about our upgrade from Convergence last year if y

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

What do developers love most? Writing code of course! And what if you are a passionate AX developer, working on AX 2009 and are going to be part of an AX 2012 upgrade? Well, jumping into AX 2012 as soon as possible! So, it was my job to be the boring PM that had to explain that no one was to start coding anything until the boring analysis phase was completed. And I was right! Critical success factor alert - Make sure your team (both technical and functional) understand the target version as well as the current version so they can make the right decisions for your upgrade. For a few weeks, our technical team was divided into areas of interest in the system, and had the tasks to study the AX 2012 documentation, play with the AX 2012 sandbox to get to understand what we were dealing with. None of our team had expertise in AX 2012 really, we were really early adopters! For every key area, both functional and technical team members had to develop a document that would describe the

Before I dive into the plan details, I would like to remind you that the exercise of developing the plan is what really is critical to your success. So my plan may not work for you verbatim! You have to go through this process yourself :) Ok, enough with the caveat, here we go, below is the expanded section for the planning phase of the upgrade project plan: The first artifact I developed was our project charter, or the first draft of it. In it I included the project goals and objectives, guiding principles, team stakeholders, high level roadmap, key activities and what is in and what is out of scope. For example, for us, process redesign was out of scope, our upgrade was "apples to apples". Key for me was to keep this as a one pager. Something I could give as a handout to a new tea member or an interested stakeholder. Here it is, I blanked out the team members to maintain their anonymity: I will write about building our team in a fu

So I was appointed to take on the task of upgrading our AX 2009 system to AX 2012. I was new to AX but experienced as a developer, architect and then project and program manager in my career. So I had to do a lot of research, but I struggled to understand how big was this project? How many people will be needed? What are the types of skillsets needed? Is this a purely technical exercise? What is the optimal sequencing of tasks? The research did not provide the answers I needed, I found a lot of technical material on how to do upgrades, white papers etc. But not much else. I did find Sure Step, but it did not provide me much either, although I used the Sure Step phases and color scheme on my project plan which I will share with you. I thought that would make it easier for AX resources to get used to, it did kind of do the trick. Here we go, below is the collapsed view of my AX 2012 upgrade project plan after 12 or 13 iterations in terms of task sequencing and task estimated duration