D365FO Upgrades – Chasing the Unicorn

Many customers have decided that it is now time to upgrade to D365.  Some of the customers are coming from AX 2009, the majority of the customers planning the move are from AX 2012.  With the end of support for AX 2012, the need to upgrade has accelerated. While this article focuses on the move from AX 2012 primarily, the concepts and ideas directly apply to any upgrade.

One of the big promises from Partners is that Microsoft has made upgrading easy and that the customer can simply perform a “lift and shift”, taking the old system into the modern age with little effort.  If you haven’t heard the phrase “lift and shift” before, just talk to a partner about upgrading to D365 and it will surely come up.

The idea of “lift and shift” is that the old system can be transformed into something that fits into D365 with just some slight changes. Essentially, you have all the customizations in your system that you already want, so simply just modify that code to work on D365 and bang, “lift and shift” is complete.  The pitch also tends to include the idea that with a lift and shift you can be up and running on D365 in about 6 months.  Seem a little to be good to be true? Well, it is.  In fact, spend just a little time in the partner circle and you will find “lift and shift” has another name, a name that conveniently leaves the letter “f” out of one the words in the phrase. 

 

Why doesn’t it work?

The basic reason that “lift and shift” does not work is because the systems are vastly different.  Common sense, one might say.  Everything from the infrastructure, code promotion process, database, integrations, backend, front end, well, everything is different.  These differences are what allow D365FO to use the unique infrastructure it has.  Basically, this is an apples and oranges scenario, but it’s obscured because the user experience mimics the same functional flow between the systems.  Maybe, one might say, the orange has been painted red to make it look a bit more like an apple, but don’t be fooled, it’s still an orange.

Now, somebody is probably screaming here, “Nah, it’s not that different.  The kernel is the same and the code is essentially the same.”  Well, as a developer there is some truth there in terms of the substance.  However, the frameworks and patterns are not the same.  Again, it looks similar, but we are dealing with a different methodology and approach.  Is it as drastic as the other changes? Maybe not, but maybe you are just a developer that came up on the new patterns for code development and that’s why it is not so foreign. Regardless, the differences are big enough that your current code cannot be simply tweaked, they need to be rebuilt to work in the new system.  Made changes to sales orders, or invoices, or posting of anything? Well, those need to be rewritten.  The framework changes do not allow a simply copy and paste of code to work.

What about Microsoft upgrade tools?

Microsoft has done a lot of work to make the process better than it was.  This does not mean that it’s easy, just improved over the past few years as more customers ran into issues.  There are two main tools for upgrading: the data upgrade tool and the code upgrade in LCS (these tools are specifically for AX 2012 upgrades). 

Of the two tools, one actually does something really helpful and the other, well does something.  The data upgrade tool is the most refined tool that is very helpful.  It is designed to handle the task of taking your current data and upgrading it to work in D365FO.  Customers and partners seem to forget this is not a click once and it just works magically tool.  This requires a coordinated effort to make your database work with the tool.  There is no shortcut here.  It’s an incremental process of fixing your data and cleaning up the database to work.  There is no “lift and shift” magical button to fix the issues for you, rather this is a manual and iterative process; each iteration helping produce a cleaner database that can be used for the upgrade.

Microsoft’s other upgrade tool should really be renamed.  There is no “code upgrade.” You can’t shift code from an overlayered approach to an extension or chain of command approach by simply running it through a tool.  Instead, the “code upgrade” actually just creates an Azure DevOps repository with the customizations separated.  Nothing is upgraded, you can’t compile it, and it sure won’t function.  The “lift and shift” myth is probably more heavily sold based on the idea, “You already have all the code done.  You just have to move it to D365.” However, Microsoft’s code upgrade tool just helps create the separation of customizations to make identifying what needs be rewritten easier and workable.  Customers tend to severely underestimate the time it takes to move a decade’s worth of customizations in an antiquated system to a new framework and the code “upgrade” tool does not assist in actually upgrading code.

Remember, your system was built over many years.  Customizations are all over and means your development for D365 will require changes to all type of objects: forms, reports, batch jobs, services, and overlayered system objects.  The things you might bring over without much additional work are the purely custom classes; those would require the least amount of effort.  So, if you are a customer where your entire AX system is built on custom objects, then you are in luck.

What to do instead?

Customers need to stop buying into a 6 month, “lift and shift” idea.  It’s simply not feasible.  Maybe if you put in enough overtime hours, work weekends, and drive your people into the ground you can hit the 6-month schedule.  It still won’t be achieved by the mythical “lift and shift.”  A better approach is to understand the scope of change between the current system and D365FO, giving your team enough time to make mistakes, understanding that the tools provided require a methodical and manual approach.

• Commit your team to the upgrade full time.  Having your team try to work their regular jobs as well work on the project is a sure-fire way to cause delays.  Most customers that miss their deadlines learn this the hard way.  They go in thinking “Hey, lift and shift.  Easy. We are basically halfway done.” When budgets are blown and deadlines are missed, then they start pulling people from their regular jobs into the project full time.  Save yourself the headache and stress, dedicate to the project full time.  Remember, this is the future of your business’ operations that you are building out.

• Plan for multiple iterations for upgrading data.  Even though there is a tool, this is not a shortcut.  If you even look at the code for the upgrade, it brings your data up iteratively, through the different versions of Dynamics.  It’s not a straight jump from AX 2012 to D365 and the data upgrade tool is bringing your data forward one version at a time.  Upgrading your data requires time and manual work. There is a manual cleanup process that takes multiple iterations.  There are unknown errors that you might hit because of the way your system has evolved. You need a runway to accomplish the work and multiple tests in a development and sandbox environment. Make sure you plan accordingly.

• Be realistic in the code upgrade time requirements.  A way to trim down the scope of changes is to use the new system with users and only make changes that are necessary for the business to achieve its goals.  Notice, those are only necessary changes for the business to work, not what users want.  In the first stages of a new system, the users will always complain about its differences from the current system and focus on changes where they can recreate the current system in the new system.  Don’t become bogged down in those customizations.  Instead, identify what the business needs for success and make those changes.  You will find users will learn to use the new system and adjust to how it works, without having to recreate the old system within the new system.

My advice for partners is this: stop selling unicorns.  They aren’t real and neither is “lift and shift.”  Set the right expectations with customers and be honest. This is a complex process that requires steady and honest guidance.