When Microsoft first announced the idea of automatic application upgrades, I thought to myself “This will never work.” I now eat my words. We recently upgraded a customer’s Dynamics 365 for Finance and Operations environment from 7.3 PU15 to 8.1 PU20. The upgrade was successful and took minimal development effort (largely because this customer has kept customizations to a minimum). We followed Microsoft’s procedures for completing the upgrade, and I’ve outlined the basic steps we followed for the upgrade below to give you an idea of how the process should typically go.
Step 1: Estimate and Analyze
The first step in the upgrade process was to run the upgrade analyzer in estimation mode from Lifecycle Services (LCS). This produced several spreadsheets that gave us our first indication of the work that would be needed to upgrade. The Migration Summary report details the objects that the upgrade tool attempts to upgrade automatically and highlights those objects that need manual attention from a developer. As you can see from the screen shot below, the customer’s position of keeping customizations to a minimum, and using only extensions when customizations are required, has resulted in the best possible outcome– zero objects need to be refactored. 
Next, we reviewed the Upgrade Task List spreadsheet. Here, there were some items that needed attention. This boiled down to two areas. First, several fields on custom data entities had been marked as obsolete in 8.1, so updated these data entities to clean out obsolete fields. Second, an extension to a menu resulted in a naming conflict. When creating the extension, the developer should have added a unique suffix to the menu name. The menu ProductionInformationManagement was extended, and the default name was left as ProductInformationManagement.Extension. This should have been changed to add a suffix after Extension to make sure it would be unique. Because Microsoft extended the object as part of a change after version 7.3, Microsoft’s change now conflicts with ours. So this menu will need to be renamed as part of our upgrade process. So, a couple of data entity updates and a menu rename. Not too bad for a major version upgrade.
Step 2: Upgrade per Microsoft Procedure
We followed the Microsoft procedure found here (https://docs.microsoft.com/en-us/dynamics365/unified-operations/dev-itpro/migration-upgrade/upgrade-latest-update).
Step 3: Testing
Once code changes were made, I gave the environment a quick smoke test to be sure nothing major was broken.
Step 4: Request Upgrade Test Environment
After initial testing looked good, we entered a request via Lifecycle Services to have the Standard Acceptance Test (UAT) environment upgraded using the upgrade code package. Microsoft performed the upgrade successfully at the day and time we agreed upon with the customer. One thing to be aware of here – as part of the upgrade, Microsoft takes a copy of the Production database and upgrades that, copying it to the UAT instance.
Step 5: Customer Test in UAT
Once the upgrade was complete in UAT, the customer took the new version for a thorough round of testing. Once the environment has been upgraded by Microsoft, you will need to sign off on the UAT environment for the production request to be submitted. At this point you can no longer roll back the upgrade.
Step 6: Request Upgrade for Production
After the customer performed their validation testing, we scheduled the upgrade for the Production environment in LCS. It should be noted that there are a limited number of time slots for the Production upgrades, and weekend slots fill up quickly. We did experience a delay in our original upgrade plan because no time slots were available. The upgrade by Microsoft was successful and performed within the 8-hour window Microsoft requests for the upgrade.
Conclusion
All in all, I was surprised by how well the upgrade process went. Of course, this customer is the ideal candidate for a smooth, automated upgrade. Simplified maintenance should be a key factor when deciding whether to customize code. This customer has proven that their decision to keep customizations to a minimum will pay dividends, and the customer seamlessly upgraded to a new version with minimal impact and cost. If you want to read about the initial upgrade from AX 2012 to D365, click here.