How to f*ck up a project: Microsoft Application Update.3 min read

Dynamics 365 provides organizations with continuous, touchless service updates that constantly offer new features and functionality. This way, Microsoft eliminates the need to do expensive upgrades every few years. But updates trigger risk assessment, meaning teams should pay enough attention to testing their system as soon as new updates are released.

Each update is mentioned in the calendar so organizations could plan ahead and be prepared for what is coming. Nevertheless, sometimes they fail to update its system seamlessly. Why is so?

UAT – Risk Assessment – Production Environment. Keep the order.

As soon as a new release of updates is deployed, user acceptance testing (UAT) is typically required before you take a Microsoft application update, or before you apply custom code and configurations to your production environment.

The sandbox environment is updated automatically seven calendar days prior to the day you select for production updates. The problem here is that you are limited to options in the production environment update cadence when Microsoft can update your system. 

While organizations that work 24/5 can run one on a weekend – those who work 24/7 cannot and will have to do updates manually, as there is no way to create a more custom schedule. Thus, they should plan their resources ahead to be prepared for a manual update, as automatic is barely an option.

Another sine qua non about any newly released updates is that teams tend to miss testing due to the workload and lack of time – they simply forget that UAT was updated. Being in the rush with testing they don’t find obvious issues in the system – which may result in further costs – and as the consequence instead of enjoying our barbeque weekend, we are handling critical support calls. Classic.

Testers don’t like to break things. They like to dispel the illusion that things work.

Even though some of the features are updated automatically by D365, it can’t guarantee that your custom code or/and Independent Software Vendor (ISV) are safe. That means any organization must decide what strategy should be used to test new features before implementing it, especially when you have a decent amount of custom code.

As soon as you come up with the strategy, make sure you set off enough resources to test your system. Pay more attention to all customizations, excel exports, integrations you have ever implemented – as it’s quite common for newly released features to crash these.

You may also use Remote Server Administration Tool (RSAT) to reduce the number of manual efforts required to test new updates for existing deployments through automation. But keep in mind that RSAT is not a silver bullet – you still have to supply and update the test library due to changes in standard code. Not to mention it does not cover retail, for instance.