This post is part of a series covering lessons learned when upgrading Windows 10 to a new version (Microsoft releases a new version twice a year). It is based on our own experiences upgrading over 25,000 machines.

Find incompatible apps using a phased deployment and pilot groups

While there are tools that help indicate application compatibility we have found they contain too many false positives (apps indicated as an issue, or potential issue that work just fine), too many false negatives (apps indicated as fine, that are not fine), and a general overwhelming amount of data (consider an organisation with 5,000+ users can easily have 5,000+ applications; this sounds improbable, but in organisation where application versions are fragmented it is possible to have 10+ versions of each application thus it quickly adds up).

In our experience, the actual applications with an issue after version upgrade is insignificantly small. Indeed, in deployments covering over 25,000 machines, we have found just 3 applications in total.

Given the above, we have found deploying an upgrade using a phased deployment and pilot groups to be the most time effective way to identify applications, while at the same time piloting the deployment approach. Yes, this is a reactive approach to identifying applications, but it is also relatively pragmatic.

An example phased approach:

  • First phase – Core apps:¬†Deploy to owners of core applications in your Windows image; Antivirus, VPN, SAP, etc.
  • Second phase – Support teams: Deploy to site support and application support teams. This is key in gaining support visibility before extending to the next phases. As part of this second phase, support processes should be provided to on how to roll back an upgrade or restart a failed upgrade.
  • Third phase – All of IT: This phase allows any kinks in deployment to be identified before deploying to your Business Unit first adopters; this is important so that any issues are genuine application issues and not issues due to problems with the deployment process.
  • Forth phase – Business Unit first adopters: Deploy to owners of key business systems; Finance, Legal, HR, and whatever makes sense in your organisation. This is easy in organisations that have clear representatives for key groups along with a helpful attitude for supporting technology upgrades.
  • Fifth phase – Full rollout: By the time this phase starts any significant application issues will have been identified. Of course, there still may be application issues waiting to be found, but if the first four phases were completed correctly the only applications with issues can be managed re-actively without significant impact.

The above approach not only finds incompatible applications without any significant impact, but it also enables effective engagement with support teams and users which facilitates support for a full rollout.