Today, we’re reorganizing STEP 2 of the Upgrade Readiness workflow to be more intuitive and efficient. The changes we’ve made include reordering the blades in this section; consolidating information from multiple blades into one; and adding a blade to promote a data-driven approach to rationalizing over low-risk apps and drivers.
The order of the blades in STEP 2 has been reconfigured to make the overall workflow more intuitive. Within STEP 2, the first blade is called “REVIEW APPLICATIONS WITH KNOWN ISSUES”. These are applications that Microsoft has already tested, and an issue has been identified. When you drill into this blade, you’ll see the applications within your organization that have known issues, as well as Microsoft’s recommended mitigation.
The second blade in STEP 2 is called “REVIEW KNOWN DRIVER ISSUES”. Similarly, Microsoft has already tested and identified issues with certain drivers within your organization. Drilling into this blade gives you a list of the drivers that won’t migrate to your target operating system, the hardware devices that are using those drivers, and where you can pick up a suitable replacement driver (if available).
The third blade is new, and it is designed to help you quickly rationalize over apps and drivers that have a low compatibility risk. You can learn more about this blade below.
Finally, the fourth blade is our Proposed Action Plan. This blade allows you to prioritize testing on your remaining apps and drivers.
Reviewing Low-Risk Apps and Drivers Efficiently
The new blade in STEP 2 of the Upgrade Readiness workflow is called “REVIEW LOW-RISK APPS AND DRIVERS”. We have identified a set of popular heuristics that many organizations use to rationalize over their apps and drivers. For example, the first row in the blade shows “Apps with an ISV support statement”. These apps have an official statement of support on Windows 10 from the software vendor, so you can be confident that they will work on your target operating system.
The second row (“Apps that are ‘Highly adopted'”) shows apps that have a ReadyForWindows status of “Highly adopted”. This means that they have been installed on at least 100,000 commercial Windows 10 devices, and we are not detecting significant issues with the app in telemetry. Since these apps are prevalent in the ecosystem at large, you can be confident that they will work in your environment as well.
Each row of the blade uses a different criterion to filter your apps or drivers. If you find the criterion sufficient for your company’s risk tolerance, you can click into a row of the blade, bulk select the results, and mark them “Ready to upgrade”. As an example, let’s click on the row that says “Apps that are ‘Highly adopted'”. The result is a list of apps that have a ReadyForWindows status of “Highly adopted”:
From here, you can bulk select the results, select “Ready to upgrade”, and click save. This will mark all apps meeting this criterion “Ready to upgrade” and no further validation is required. Note that we automatically filter our any applications that you have marked as Mission critical or Business critical, as well as any app that has an issue known to Microsoft. This allows you to rationalize over apps in bulk without having to worry about a critical app slipping through the cracks.
You can also use the Log Search query language to customize criteria. For example, if a ReadyForWindows status of “Adopted” is not sufficient by itself for you to be confident in an app’s compatibility, you can add additional filters. Start by clicking on the row that says “Apps that are ‘Adopted'”. Then, modify the resulting query to fit your company’s risk tolerance. Let’s say that for you to be comfortable that an app will work in your organization, it must be “Adopted” and have fewer than 1,000 installs. You would add “TotalInstalls < 1000″ to the end of the Log Search query.
If you wanted to be even more risk averse, you can add additional filters on attributes such as monthly active users, app importance, etc. Remember that in all cases, apps that you have designated as Mission critical or Business critical are automatically excluded from the counts on the blade. If an app is critical, we recommend always manually validating it prior to upgrade.
We recommend using criteria like the ones presented on this blade to rationalize over your apps and drivers in broad strokes. By either using each set of criteria as-is, or modifying them to fit your risk preference, you can significantly reduce the time it takes to test your apps and drivers while remaining confident that they will continue to work after you upgrade your operating system.
At the bottom of the blade, there is a section called “OTHER APPS AND DRIVERS IN NEED OF REVIEW”. In this section, you can quickly access the apps you have designated as Mission or Buisness critical; your remaining apps that are in need of reivew; and your remaining drivers that are in need of review.
As you effectively utilize the low-risk criteria provided, your numbers of apps and drivers in need of review will decrease to much more manageable levels. As a final step, use the Proposed Action Plan (the fourth blade in STEP 2) to determine the most efficient order in which you can manually test your remaining apps and drivers in need of review.
We hope you enjoy these changes, and as always, we’d love to hear your feedback.