Pick pilot users who are willing to report problems and who together cover your widest mix of applications and devices. Recruit them by asking for volunteers, say you want feedback, and keep each department spread across several rings so one bad patch cannot stop a whole function.
Start with the goal
Microsoft's guidance on Windows client servicing says the purpose of a test deployment is to receive feedback. That sounds obvious, but many pilots are just a list of names. A pilot user who never reports anything gives you no data.
NIST SP 800-40 Rev 4 makes a related point. It suggests a first round with technically knowledgeable users, such as system administrators and security engineers, lasting a few days. A larger second round of early adopters who are willing to try updates for a few weeks follows, and they should ideally represent the entire user community.
Who to include
- IT and security staff for the first round, since they can diagnose problems.
- People who use different applications, including the awkward ones.
- Users on different hardware and operating system versions.
- Representatives from each business unit, not only technical teams.
- Remote and travelling staff, if your estate includes them.
Microsoft says to include members who provide the broadest set of applications and devices, which validates the largest number of combinations.
How to ask
Request volunteers. Be direct that you are looking for feedback, not for people to simply try it out, and that occasional issues are possible when updates arrive early. People who know the deal are more tolerant and more useful.
Give volunteers:
- A single place to report problems.
- A short list of what to watch, such as crashes or a failing application.
- A promise about response time.
- A thank you at the end. Pilots that feel ignored dry up.
Protect critical teams
Microsoft suggests splitting each department across multiple rings. If something goes wrong in an early ring, no single department loses all of its machines, so critical business can continue. The same logic applies to servers: do not patch both nodes of a pair in the same ring.
Keep special devices out
Devices that control factory or medical equipment, or run ATMs, may need a stricter and less frequent cycle. Microsoft advises identifying them and separating them from the phased deployment so administrators do not confuse them. Give them their own maintenance group.
Know when the pilot is done
Write the exit rule before you start. For example: no unresolved blocking issues for a set number of days, and a minimum number of reports or confirmations received. The sources do not set numbers, so choose ones you can defend. For the wider method, see canary patch rollouts.
Safeguard covers the developer side. Its CLI and IDE extensions can run dependency scans before a change merges, and gates can block builds that violate policy.
Quick check
How many pilot users do we need?
The sources do not give a number. Aim for enough people to cover your main application and device combinations.
Should executives be in the pilot?
Usually not in the first ring. Keep them in a later ring so a faulty patch does not hit them first.
Sources
Last reviewed: 19 October 2026.
