Upgrading to Dynamics 365 for Operations from Dynamics AX - part 2.
Part 2 of 4 things you really need to know.
You’ve made the decision to move to Dynamics 365 for Operations. You’ve heard there are two main strategies:
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:
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.
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.
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?
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.
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.
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.
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.
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.