Upgrading to Dynamics 365 for Operations from Dynamics AX - part 3.

Part 3 of 4 things you really need to know.

Part 3: “Next-next-next, it’s that easy, right?” - internal resource requirements

The most common (and logical) questions I’m asked are ‘how long will it take?’ and more importantly, ‘how much will it cost?’

Unfortunately, some form of discovery is needed up front before I can give an answer. Just like a builder asked to estimate the time and costs of renovating a house, even if the owner can describe the building size, number of rooms, house type etc, an onsite inspection is essential before a realistic estimate can be made. Even putting it in a range is challenging, as influencing factors include:

  • company size
  • number of users
  • business/industry complexity
  • geographical spread
  • 3rd party solutions
  • EDI and other integrations
  • wireless warehousing
  • your ability to backfill key user roles
  • the appetite for change within the business
  • executive buy in and direction
  • preferred approach e.g. re-implement or upgrade

So to make the time and costs clear from the outset, your Microsoft Partner will create a map which details the complexities of your current solution, and then produce a future-state map of the new version. This demonstrates how all the parts of the new solution integrate, and gives a great visual blueprint to refer back to throughout the project. I’ve always found my solution maps on the project wall, well viewed and under discussion.

Current State

Future State

The devil is in the detail

While I draw on the many customer upgrades I’ve done in the past and my knowledge of the architectural changes in Dynamics 365 for each new project, it’s important to remember that there will always be unknowns. You should always factor in contingencies (in terms of time and budget) to any planned upgrade. That way you won’t be caught out part-way through the project when those unknowns rear their ugly heads.

Another thing to factor in to a Dynamics 365 upgrade is the code sealing. Microsoft are ‘sealing off’ the application code over the next year, which means existing customisation must be rewritten as an ‘extension’, rather than using the old method of ‘overlaying’. As this blog is more business level than technical, I won’t expand here.  However, there are some great blogs out there that dive into the technical details, and your Microsoft Partner can explain further if required. The point is, careful planning and execution is required to deliver an upgraded system that conforms to Dynamics 365’s new architectural principles.

Our two project approaches – cooking an egg

The following step by step breakdowns give you a basic idea of the major activities involved in an upgrade or a re-implementation. However, there’s more than one way to cook an egg, so bear in mind that these may not describe exactly how your unique project will run.


As mentioned in parts 1 and 2 of this blog series, a re-implementation runs a lot like a full-blown ERP implementation. So these steps are likely to feel familiar if you’ve done that already. However, there are some subtle differences when moving from one version of Dynamics AX to another.

Step 1 - Solution Review

Your business consultant runs a series of workshops for each functional area, which fully reviews your current AX processes. The consultant needs to understand your business and identify areas for change in the upgrade to Dynamics 365 Operations, including business processes, data and modifications. At the same time, your subject matter experts have the chance to learn about new opportunities for process improvement. Your consultant documents all these points, and this becomes the macro design of your new system.

Step 2 – Design

A second set of workshop sessions with the consultant and key users from the business drills into the areas where change will occur. These might, for example, look at the effects of increased use of the system, or at modifications that need re-engineering due to changes between versions. The output of the design phase is the functional and technical design specs necessary to build the new system.

Step 3 – Build

The new environments are created once the solution review and design are finalised and signed off. At this point there’s usually a development freeze on the current solution, as well as a freeze on new projects to extend the system e.g. implementing new modules. Technical consultants migrate all the agreed customisations from the current solution into the new development environment, and work on them as required. This step requires little or no input from your business.

Step 4 – Configure

This step runs parallel to Step 3. Functional consultants and key users migrate the configuration, master data and opening balances from the current solution to the newly-created configuration environment. The result will look a lot like the final solution.

Step 5 – Unit Testing

Before handing the environment back to you for testing, the work performed in Steps 3 and 4 is checked against the functional and technical specs from the design phase. This may require some rework on the code or data migration steps, which is typically performed by the functional consultants. This step requires little or no input from your business.

Step 6 – User Acceptance Testing

The testing environment is handed back to you, along with a full test plan and test cases to drive the process. This part of the project is structured, documented and transparent. Consultants are available for support, but this stage is owned and driven by your business.

Step 7 – Go-live

Over the go-live weekend, the opening balances migrate and any other cutover activities specific to your business are performed. The new system is up and running with limited access to your old AX environment on the Monday. A full resource plan ensures you have both internal and external resources at your disposal. The success of this phase is hugely impacted by the level of testing done in Step 6. There are no shortcuts: test test test!

Upgrade/Technical Upgrade:

What’s the difference? Well, a non-technical upgrade takes a wider view, looking at improving processes, reducing customisation, reorganising data etc. A non-technical upgrade is similar to a re-implementation from a phase perspective. So the following steps focus on a straight-forward technical system upgrade. This doesn’t require the same level of input from your business, as the goal is a ‘like for like’ transfer of processes with no re-engineering (unless forced to by the system). The tasks are, obviously, more technical in nature, but there should still be a full user acceptance testing cycle at the end of the project that requires a high level of input from you to ensure the project’s success. The steps below outline the most basic upgrade, and assumes you’re moving from Ax2012 R3 to Dynamics 365 for Operations. If you’re on an older version, then you need to upgrade to AX2012 R3 first, but this can be done as a double hop in the same project (effectively doing Step 2 twice).

Step 1 - Solution Review

A business consultant runs series of workshops for each functional area of your current AX processes, with a view to understanding which ones will need the most testing, and if any re-design or re-engineering is required. If you’re starting out with a standard AX, the process should work smoothly as soon as the upgrade scripts are in place. However, modified areas may upgrade imperfectly without some re-design and re-engineering.

Step 2 – Upgrade

This is where the fun begins! Depending on which version you’re moving from and to, what ISVs you have, how many modifications your current solution has and so on, activities in this step will vary. But at a high level there are two objectives:

  • Upgrade the code  
    Developers use a series of tools and techniques to upgrade the code, which is relatively straight forward if your existing environment isn’t highly customised. However, the more customisations you have, the more resource intensive this step becomes. If there are changes in the data or code structures between versions, your code may need re-engineering. And as mentioned previously, code in Dynamics 365 should (and soon must) be done via extending, not overlaying as in the past.
  • Upgrade the data  
    Developers also use Microsoft-provided tools to upgrade the data in the system, and in theory this is straight forward. However, experience has shown me it can be time consuming, because Microsoft scripts can’t cater for every possible system configuration. So you may find additional custom scripts are needed to address any issues found during this process.  

    The outcomes of Step 2 are: 
    - An upgraded test system 
    - A document of every single step required to upgrade

Documentation is the most critical part, as this process is repeated multiple times, and again on the cutover weekend. Having consultants and developers document all steps is crucial to ensuring repeatability and consistency.

Step 3 – Unit Testing

Before handing the environment back to you for testing, the work performed in Step 2 is checked and the system is matched against the agreed design from Step 1. This may require some rework on the code or data migration steps.

Step 4 – Test/Upgrade/Test/Upgrade/Test

The system is handed back to your key business users, along with a full test plan and test cases to drive the process. This step involves multiple cycles to make absolutely sure the upgrade can be repeated step by step and achieve the same outcome every time. Once proven, the system is ready to go-live.

Step 5– Go-live

The upgrade runs one final time on the go-live weekend. As the process may take both days, you might need to shut your systems down on Friday. But if all goes to plan, then your new system is up and running on Monday with limited access to your old AX. The testing in Step 4 should ensure a smooth journey, but if a new or unexpected issue arises during the cutover (for example, I’ve seen cases where the live servers had subtle differences which resulted in major knock-on problems), the most prudent thing to do is usually aborting the upgrade and setting a new date for going live.

Who’s who in the zoo

Having the right internal resources is critical for project success. And as with everything I’ve touched on in this blog, who and what you need can vary. This is a table of the most common resources. Ideally you’d have them all, and often one person can cover multiple roles:

This blog should give you sufficient knowledge of the steps and business resources needed at each point in an upgrade.

Fusion5 can carry out an upgrade assessment that helps you work out the right approach for your business and puts your mind at rest on the costs involved in upgrading to Dynamics 365.

So, now you have the information, and you know the effort involved. In the final part of this blog series, I’ll help you to answer the question: ‘Why is an upgrade the best thing for my business right now?’


Great outcomes start with great conversations