We are currently going through the process of upgrading our internal production Microsoft Dynamics AX 2012 environment to Dynamics 365. This is the first post of a four-part series documenting our upgrade to D365 process, particularly where it deviates from the more commonly documented process.
The Standard Approach
The standard approach for an upgrade of Dynamics AX 2012 R3 to Dynamics 365 involves two major steps: code upgrade and then a data upgrade. The code upgrade portion is very cumbersome, complex, and can be considered overwhelming.
The common approach looks very much like the following:
- In LCS, perform a code upgrade analysis on your AX 2012 model store
- Setup and configure Visual Studio in a DEV VM
- Connect Visual Studio to VSTS
- Configure your source control mappings
- Pull down the upgraded code to source control
- Resolve conflicts until you get a clean build
- Perform the data upgrade
- Test, rinse and repeat
- “Go live”
enVista’s Approach
Our approach begins in much the same way with one key difference; we ignore the upgraded code and DO NOT import into source control. We download the code upgrade package for reference but do not work with it directly within our solution. We then select enhancements to data schema and recreate them in Dynamics 365.
With a focus of Minimum Viable Product (MVP), our goal is to facilitate the upgrade as quickly as we can. This allows our business users to test new functionality in Dynamics 365 using their familiar legacy data. We also employ an agile methodology to assess the need and viability of previous enhancements against existing Dynamics 365 functionality.
Hidden Treasures of Advanced Warehousing
Make the most of Microsoft Dynamics 365’s Advanced Warehousing module and gain insight into the hidden treasures to unlock value.
The Benefits of enVista’s Approach
We have realized the following benefits with our approach:
- An environment that is much closer to the native solution and one that is not cluttered from years of accumulated customizations.
- Eliminating old artifacts from ISV/third party solutions that are no longer used.
- Reduction in noise and confusion associated with resolving an untold number of conflicts.
- A functioning environment stood up as quickly as possible for our business users so they can begin evaluating and testing it.
Justification
You could think of this approach as a compromise between a new implementation and a direct upgrade. We will not be blindly moving code forward without a clear business need, and we won’t be wasting our time trying to resolve conflicts just to get a solution to build successfully. Instead, we start with a nearly native solution, populated with our data, that the business is able to work with and evaluate.
This approach does place more responsibility on our business analysts and end-users. They are responsible for determining which legacy enhancements are required instead of a developer or automated tool. This approach also promotes increased ownership from the end-users by engaging them earlier than the last phase of the upgrade (acceptance testing).
In the next three blog posts, I will explain the following:
- Identify the data schema elements to be upgraded and created in Dynamics 365 to accept our 2012 data.
- Perform the data upgrade.
- Evaluate the system, with OUR data, against 2012 and determine what enhancements need to be brought forward.
Deep Expertise in Dynamics AX and D365
In this blog, we have presented our approach for upgrading to Dynamics 365 from AX 2012. In future posts, we will take you through the actual process of updating the data schema, performing the data upgrade and other various components of the upgrade process.
enVista is dedicated to helping the Microsoft community by continuously sharing our in-depth knowledge of X++ and Microsoft Dynamics 365 development. If you are struggling with Dynamics AX or D365 development, contact us, and we will connect you with one of our in-house experts.
