Operating System Upgrade Rollout Checklist Template

Phase 1: Scope, Deadline & Inventory

The two scope answers on the first task decide whether the endpoint phase, the server phase or both appear.

• Open the rollout record and set the source and target versions — for example Windows 11 24H2 to 25H2 or Windows Server 2016 to 2025, and whether endpoints, servers or both are in scope
• Record the date the source version stops receiving security updates — from the vendor’s lifecycle page; the whole plan counts back from it
• Export every device on the source version from your management tools — include devices not seen for 30 days; the asset register alone will miss some
• Check each device against the target version’s hardware requirements — Windows 11 needs TPM 2.0, UEFI with Secure Boot capability, 4 GB of RAM and 64 GB of storage
• Confirm the target is offered as an upgrade for your devices — Windows 11 26H1, for example, is for new devices only and is not offered in place from 24H2 or 25H2
• Choose in-place upgrade, wipe and reload, or replacement for each group — and record why; ineligible hardware goes to replacement, not to the rollout

Phase 2: Compatibility & Readiness

• List the applications, agents and drivers each device group depends on — line-of-business apps, security and management agents, VPN, printer and scanner drivers
• Check vendor support statements for the target version — security agents and the VPN client first, because a failed agent leaves a device unprotected and unmanaged
• Read the vendor’s known issues and upgrade blocks — Windows release health lists the safeguard holds that stop affected devices being offered a feature update
• Test each critical application on a lab build of the target version — sign in, print, and the tasks each department relies on most
• Update, replace or record an exception for anything that fails — before the pilot, not during the broad rollout
• Confirm user data and server backups are current — synced or redirected user folders, and a restorable backup for every server in scope

Phase 3: Rollback, Rings & Approval

The approver named on the first task signs off on the last task. The checklist halts there, and nothing is deployed until they decide.

• Set the rollback window before anyone upgrades — Windows keeps the previous version for 10 days by default; DISM can set any value from 2 to 60 days
• Write the rollback steps for each platform — Windows go-back, a snapshot or restore for servers, and a reimage or restore for macOS and Linux
• Define the rings and the exit criteria for each — install success rate, ticket volume and soak time before the next ring opens
• Configure deferral and targeting in the management tool — Windows feature updates can be deferred for up to 365 days; supervised Macs can defer upgrades for up to 90 days
• Raise the change record for the rollout — attach the ring plan, the schedule and the rollback steps
• Approve the rollout plan — the named approver records approved or not approved, with the reason

Phase 4: Test & Pilot Rings

If the pilot result is recorded as Fail, the last task appears and the broad rings wait.

• Upgrade the IT test ring first — IT devices and lab servers catch install failures, not business application problems
• Build a pilot ring that mirrors the estate — every hardware model, every department’s key application and some remote workers
• Tell pilot users what to watch for and how to report it — a dedicated ticket category makes pilot issues easy to count
• Hold the pilot for the agreed soak period — one to two weeks is common; include a month-end if finance devices are in the ring
• Record the pilot result against the exit criteria — pass, or fail with the cause and the devices affected
• Pause the rollout, fix the cause and run the pilot again — the broad rings stay closed until a pilot passes

Phase 5: Endpoint Rollout

Tasks appear only when endpoints are in scope.

• Tell users what will happen and when — how long the restart takes, what looks different and the date it installs anyway
• Deploy the broad rings in waves — sized by site or department so the service desk can absorb the tickets
• Watch install failures and the ticket queue during each wave — stop the next wave if either passes the exit criteria
• Chase devices that are offline, stuck or short of disk space — laptops that rarely connect are the usual stragglers
• Enforce the deadline once the deferral period ends — users choose when within the window, not whether
• Replace or isolate devices that cannot upgrade — an unsupported device should not keep full network access

Phase 6: Server Upgrades

Tasks appear only when servers are in scope.

• Confirm the in-place path is supported for this version and role — Windows Server 2025 accepts in-place upgrades from 2012 R2 onwards; RHEL moves one major version at a time
• Back up the server and record the restore point — Microsoft and Red Hat both advise a backup before any in-place upgrade
• Run the vendor’s pre-upgrade assessment and clear every blocker — for example the Leapp pre-upgrade report on RHEL
• Upgrade clustered servers one node at a time — a Windows cluster rolling upgrade can only move one version at a time
• Test the service with its owner before the window closes — application, monitoring, backup agent and security agent all working
• Rebuild instead where a role does not support in-place upgrade — the new server follows your standard build, then the old one is decommissioned