Success story: Upgrading MsDyn365FO from 7.1 PU18 to 8.1.2 PU22

After almost one month after upgrading one of our Microsoft Dynamics 365 for Finance and Operation customers from version 7.1 PU18 to version 8.1.2 PU22, I want to share the success story of this project.

The baseline or starting point for this upgrade project was an production environment running on version 7.1 PU18 with mainly two codebases.

  1. Our product (ISV solution) with overlayerings almost everywhere: Amongst other overlayerings and extensions, 350 overlayered classes, 500 overlayered tables and 150 overlayered forms in package ApplicationSuite.
  2. Also with a lot of overlayerings, the project customization/extension package: 100 overlayered classes, 50 overlayered tables and 10 overlayered forms in package ApplicationSuite. 

We started the code upgrade service to kick-off the project almost 5 months before the upgrade on prod was planned. The first iteration of the project was to integrate our upgraded product (ISV solution) into the upgraded branch and fix obvious problems in the project customization/extension code. This first stage of the project took almost one month with 1 to 2 developer assigned. At the end of this first stage we deployed the first tier1 environment including the first version of the two upgraded codebases. 

To do not lose track on the upgraded branch we used the following branching/merging strategy, were we merged over all changes from our main-branch to the upgrade-branch in a weekly manner. 

Es wurde kein Alt-Text für dieses Bild angegeben.

With this branching/merging strategy we were able to service the current production environment from the main- und release-branch and we were also able to refactor and change things in the upgrade-branch to meet the requirements of the new version. 

Two months prior to the scheduled upgrade we communicated a code freeze on the main-branch to use all available resources for regression testing and fixing bugs which has been found in regression testing. Two months sounds long at the first view but the Christmas holidays were in this timeframe, so the “actual” regression test was not two months long :-). 

After the first month of regression testing we decided to upgrade the first sandbox environment using the self-service upgrade program. The upgrade went through just fine and we started the next round of regression testing on the upgraded sandbox environment. 

After another months of regression testing we started the data upgrade of the production environment by clicking the data upgrade button in LCS on Friday evening after end of business at the customer side, to use the night for the database upgrade. Over the night everything went fine and we started some manual data upgrade steps on Saturday morning. The next milestone was to pass some general (smoke) tests, which also went well, so we were quiet sure that also the normal business on the next Monday would work very well. On Monday our hopes come true and we only had some minor bugs in comparison to what we had changed with the upgrade. 

After almost one month now, I can say that we were already in the “normal” support process flow after one week. The upgrade of the production environment was extremely smooth but only because of the effort taken by team(s) to prepare, test and execute this process.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s