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.
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.