The Plan
I had a great plan, an elegant plan. The plan went like this:
- Create a new AX2012 development environment
- Uninstall all models in layers above SYP
- Move Data to D365 Development Environment
- Apply AX2012>D365 upgrade package
- Have a functioning Out Of Box D365F&O environment with our data
The purpose of this plan was to provide our business team with a D365 Environment to perform a new fit-gap analysis and evaluate our current AX2012 modifications. We have been modifying AX now for 6 + years and a portion of those modifications are no longer needed. From past experience the best way to get key users engaged is by provide real-life data.
tt was a good plan but badly flawed.
The Reality
The first challenge I ran into was getting an appropriate Development environment running (see the first post in this series for details). Once that task was complete, I started onto applying the data upgrade script. This process was fraught with problems. Microsoft was very helpful in resolving them but it took time.
Then finally I was past the pre-upgrade prep steps, and running the actual data upgrade scripts. I ended up having to apply the update manually via AXUpdateUtil so I got to watch the upgrade happen. it was an exciting time.
Then, failure. No problem, I thought, I’ll just look into the log and fix the problem. What I found was many unique index violations and lots of them. I spent far too long trying to figure out what had gone wrong before identifying the problem.
Lesson Learned
By dropping the CUS layer models, I had reverted the AX2012 data dictionary to OOB. I was expecting to lose any fields we have over-layered onto tables, however I did not consider EDTs and Enums. We had previously increased the number of characters allowed by many EDTs, however, when they were returned to OOB size, it caused index violations in our data. Additionally we had over-layered a few Enums, which caused an issue because the matching Enum would not exist in the OOB code.
What I have learned is that to effectively complete an upgrade from AX2012 to D365 the data dictionary is the minimum amount of code that must be migrated to extensions.
Next Steps
Now comes the work of moving all of our data dictionary modifications to D365 Extensions. I have already begun this process with a CUS Model and Project started to encapsulate all of the required changes. I will also need to deal with data dictionary changes from our ISV but that will be another post.
I will eventually have a series of posts detailing how we accomplished out Data Upgrade but until I have been successful, I will continue posting lessons learned.
