Operating System Upgrade Rollout Checklist Template

What the OS Upgrade Rollout Checklist Covers

1. 1
   Phase 1

   Phase 1: Scope, Deadline & Inventory

   6 tasks

   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
2. 2
   Phase 2

   Phase 2: Compatibility & Readiness

   6 tasks

   • 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
3. 3
   Phase 3

   Phase 3: Rollback, Rings & Approval

   6 tasks

   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
4. 4
   Phase 4

   Phase 4: Test & Pilot Rings

   6 tasks

   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
5. 5
   Phase 5 — Endpoints

   Phase 5: Endpoint Rollout

   6 tasks

   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
6. 6
   Phase 6 — Servers

   Phase 6: Server Upgrades

   6 tasks

   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
7. 7
   Phase 7

   Phase 7: Completion, Exceptions & Close

   6 tasks

   The exception task appears only when devices remain on the source version.

   • Reconcile completion against the Phase 1 inventory — by group, with every device still on the source version named
   • Record an exception for each device left behind — owner, reason, compensating control and an end date before support ends
   • Treat extended security updates as a paid, time-limited bridge — Windows 10 ESU for organisations runs for up to three years, needs version 22H2 and doubles in price each year
   • Confirm nobody still needs a rollback before the window closes — after it closes, going back means a rebuild
   • Update the standard image, build documents and asset register — so new devices do not arrive on the old version
   • Sign off the rollout and close the change record — the rollout owner confirms results and exceptions, with the completion report attached