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

Part 2 of 4 things you really need to know.

Part 2: Re-implementation vs Upgrade - what do they entail?

You’ve made the decision to move to Dynamics 365 for Operations. You’ve heard there are two main strategies:

  • Upgrade - the data and modifications on your current AX environment are converted into a new Dynamics 365 environment
  • Reimplementation - selected data and modifications on your current AX environment are migrated into a new Dynamics 365 environment

These are two very different approaches. Which do you choose?

First, find out if you have a system that can take an upgrade

At the time of writing AX2012 R3 is the only version you can perform a complete upgrade from. Because 365 for Operations was based on Dynamics AX R3 CU8, any version that came after that should be safe. You can perform a code upgrade from R2, but not full data, so you’d need to do a two-step upgrade: AX2012 R2 > R3 > 365 for Operations if you want both.

Microsoft have released tools for upgrading data from AX2009 - but not code. So, this would still need a re-implementation as it only covers master data, open transactions, opening balances and configuration, not historical transactional data. But it should significantly reduce the data migration aspect which is not recommended without the right tools.

Here are some practical scenarios to consider:

  • How long ago was my original implementation?

Direct upgrades aren’t possible on older versions like Axapta 3 or Dynamics AX 4. It will take multiple jumps to get to Dynamics 365 for Operations, so upgrading is complicated and the cost may be prohibitive.

  • What does my business look like right now?

Perhaps after going live with AX your business went in a completely different direction. Or was acquired by another company. Or maybe you sold off part of the business. In cases like these, it may not make sense to take the entire solution and move it forward to the latest version. It might be more advantageous to start with a clean slate.

  • Is my Dynamics AX environment modified?

AX was a wonderfully easy system to customise. And your AX partner would have advised you to adopt standard best-practice for your modified processes. I’ve seen some truly amazing customisations with fantastic outputs that can be upgraded relatively easily. However, if your AX environment is heavily modified with non-standard processes, then reimplementation may still be the more logical option. Take this opportunity to think critically about your processes and how close they are to standard. Can you rebuild the required enhancement in a way that’s in line with best practice and then upgrade? Or will you still need to reimplement?

  • Do I have an ISV solution as part of my base product?

Microsoft acquired and assimilated many Independent Software Vendors (ISV) solutions into the core AX product. Examples include Ebec’s Lean Manufacturing, Fullscope’s Process Manufacturing/Distribution and Blue Horseshoe’s WAX and TRAX.

Microsoft re-wrote a lot of the ISV functionality making it impossible to simply move the code forward. Businesses using AX2009 or older will have to drop the ISV layer and remap their processes and data to the new code. I’ve never seen this achieved before, and am extremely reluctant to suggest it. Re-implementing onto a fresh install of Dynamics 365 for Operations seems the most logical choice.

  • Do I want to change my mind about previous setup and configuration decisions?

An ERP implementation is a large and complex beast. Even with the right information, partner and timeframes, it’s still possible to end up with a system that isn’t quite what you thought it would be. Financial dimensions, for example, can go through multiple iterations of design and build until you settle on the final setup. But don’t worry, you don’t need a DeLorean to rectify this. By reimplementing you can change core decisions and create a solution that’s a much better fit for your business. And as you’ve already used a version of AX, your knowledge of the ramifications of each decision puts you miles ahead.

Let’s go into some details to give you a better idea of which approach is the right one for your business:


Re-implementing basically means firing up a clean version of Dynamics 365 and migrating the data and modifications you require.

If you’re used to system implementations, you know what to expect. And be assured, migrating data and modifications from one AX system to another is much easier than when a completely different ERP is involved. And Microsoft provides some clever and helpful tools. Reimplementation gives you a chance to review, rationalise and cleanse your data, so you only bring across what you need. However, moving transactional data is nearly impossible, so you won’t have your history in the new version. Your opening balances will map across just like they would have during your original implementation. Reporting can bridge the gap between the old data and the new, but this needs to be factored in and planned for. Just be prepared for the fact you won’t have seamless reporting across both the old and new data.

Diagram (Simplified)


  • Gives you a fantastic opportunity to take a good, hard look at processes and remove or rework bad ones.
  • Your chance to remove redundant modifications. Each new AX release gives you greater functionality, reducing the need to modify the system.
  • You can redesign data to better reflect your business. It’s a common theme, either the system wasn’t configured ideally to begin with, or the business changed over time and past decisions no longer fit. Now you can change things like the chart of accounts, financial dimensions, product structures and so on.


  • It’s intensive. Key users and subject matter experts need to invest time in design workshops, user acceptance and end user training and more. Backfilling temporarily vacated roles is recommended, or the project has a high chance of failure or dragging on. Which usually leads to substandard outcomes.
  • Loss of transactional data. While a positive for some, it makes life harder for businesses who rely heavily on this function. Being unable to make quick enquiries on past orders, old item codes, lost sales and so on can be a big drawback.
  • It’s time-consuming and expensive. Typically, this approach takes more consulting power to redesign processes, configure the new system, unit test, write specifications and so on.


Upgrading is a more technical process. Using a series of tools and scripts, the data, codes and modifications in your current AX environment are converted across into a new Dynamics 365 environment. The conversion itself only takes a single weekend, but there are several practice sessions before doing it for real. You need to run full regression testing because you can’t take anything for granted. The conversion tools are incredibly smart, but they won’t cater for every possible configuration of a Dynamics AX environment. You need to carry out user acceptance testing for each business process to ensure the data and customisations are working. This is where a good Dynamics 365 partner can make the difference between success and failure, as they’ll help find and resolve issues where the scripts haven’t worked correctly.

Diagram (Simplified)


  • Usually faster and less time consuming than reimplementing, this option favours businesses where time or money are the biggest issues.
  • The business has less change to absorb. The upgraded system should look and feel familiar and require less training than a reimplementation.
  • Lower resource investment, which is particularly important for businesses where backfilling is a problem (e.g. niche skills sets or the location limits getting temporary staff in).


  • Historical baggage is inherited by the new system.
  • There’s no opportunity to rationalise data and processes.
  • Requires an extremely robust and repeatable process. Because most businesses can’t afford to shut down for a week while IT upgrades its software, a lot of technical activity is focussed over the cutover weekend, leaving little room for error. A good AX partner will have a robust cutover plan that allows rolling back in the case of failure, but this can result in multiple cutover weekends which can be disruptive and expensive.

Given the young age of AX 2012 R3, the number of businesses that can upgrade directly is small. And as their implementation will be relatively recent, the motivation and reasons to upgrade will be low. There’d need to be a compelling reason to shift again so soon.

But for businesses on AX2009 or older, it’s definitely time to start looking at what Dynamics 365 for Operations can offer from a technology perspective - cloud-based, incredibly tight office integration, operating from any device, part of Dynamics 365 total solution and so on. There’s also the functional perspective including access to out-of-the-box verticals such as Process Manufacturing, Lean Manufacturing and Retail.

What next?

The next big question you probably have at this point is how much and how long?

In part 3 I’ll discuss the phases of the two approaches and give you an idea of what’s required for each. With a better understanding of the overall project, you can make a better cost/benefit analysis of the move.


Great outcomes start with great conversations