Every Windows 10 migration deck we've seen this year has the same slide: a green arrow from Windows 7 to Windows 10, a task sequence icon in the middle, and a timeline that assumes nothing goes wrong. We are two years into running Windows 10 migration programs with SCCM for enterprise and government clients, and we can report that the arrow is real but the timeline never is. The task sequence is maybe fifteen percent of the work. The other eighty-five percent is application compatibility, driver management, user-state migration, and the political question of who owns the machine while it reboots four times.
The engagement behind this post is an enterprise estate in the low five figures of Windows 7 devices, managed by an SCCM Current Branch hierarchy we had previously migrated off 2012 R2. The mandate: get to Windows 10 1709 before the next hardware refresh cycle, without a forklift, and without the help desk declaring war on us. January 2020 is when Windows 7 extended support ends, which sounds far away until you divide the fleet size by realistic weekly throughput and discover you needed to start last quarter.
Here is what we've standardized on, what broke, and what we do differently now.
In-place upgrade first, wipe-and-load by exception
The religious debate of 2016 — in-place upgrade versus wipe-and-load — is settled for us. In-place upgrade with the Windows 10 setup engine is the default path, and it earns that position on numbers: it preserves applications, drivers, and user data automatically, it rolls back cleanly if setup fails before the finalization phase, and it takes the user-state migration problem off the table for the majority of the fleet.
Wipe-and-load survives as the exception path, triggered by a short list of conditions we evaluate per device collection:
- BIOS-to-UEFI conversion required (we want UEFI and Secure Boot on everything that supports it, and in-place upgrade before 1703 couldn't convert the disk; even now we treat firmware conversion as a rebuild event)
- Encryption products that block setup — third-party full-disk encryption that isn't upgrade-aware means decrypt-rebuild-re-encrypt, or better, a move to BitLocker during the rebuild
- Machines with more than three years of accumulated local weirdness, identified by hardware inventory and a hefty dose of help-desk folklore
- x86 installs of Windows 7, because there is no in-place path from 32-bit to 64-bit and we refuse to install 32-bit Windows 10 in 2018
On this estate the split landed near 80/20 in favor of in-place. Every point of that 80 percent is a machine where we never had to touch USMT, and that is worth protecting.
The task sequence itself: boring on purpose
Our in-place upgrade task sequence is deliberately short. The upgrade task sequence template in SCCM Current Branch gives you the skeleton; we add three things and resist adding a fourth.
First, a pre-flight group that fails fast and loudly: disk space check (we require 20 GB free, not the bare minimum), battery and power state, pending-reboot detection, and a compatibility scan run of Windows setup with the /Compat ScanOnly switch executed as its own step days before the real deployment. The scan-only run is the single highest-value step in the sequence. It surfaces the hard blocks — incompatible drivers, offending applications — while the fix is still an email rather than an incident.
Second, a driver and firmware staging group. More on drivers below.
Third, post-upgrade cleanup: re-enable the third-party agents we suspended, reapply power and BitLocker policy, run a health script that verifies the SCCM client, and set a registry tattoo with the program version and date so reporting can distinguish our upgrades from Windows Update opportunism.
What we resist is application installation logic inside the upgrade sequence. In-place upgrade keeps the apps; the moment you start layering installs into the same maintenance window you've rebuilt a wipe-and-load with extra steps and a two-hour window that becomes four.
# Pre-flight compat scan, deployed a week ahead of the upgrade ring
Start-Process -FilePath ".\setup.exe" -ArgumentList `
"/Auto Upgrade /Quiet /NoReboot /DynamicUpdate Disable /Compat ScanOnly" -Wait
# Exit code 0xC1900210 = no compat issues found; anything else gets triaged
Drivers: the estate tax nobody budgets for
Driver management is where Windows 10 migrations go to die quietly. This fleet had eleven hardware models in scope after we retired the long tail; each model needed validated Windows 10 drivers, and three of them needed firmware updates before the upgrade would even survive the compatibility scan.
Our discipline: one driver package per model per Windows 10 build, populated only from the vendor's enterprise CAB or SCCM-specific bundle, never from the consumer auto-update tool. The task sequence selects the package by WMI model query. We version driver packages like software — the package name carries the vendor CAB release date — because "latest" is not a version and you will otherwise never be able to answer the question "what changed since the pilot ring worked."
Firmware gets its own deployment ahead of the OS wave, with BitLocker suspended for exactly one restart. We learned to schedule firmware at least a week before the upgrade wave lands; interleaving firmware and OS upgrade in one window produced our two worst nights of the program.
USMT and the 20 percent
For the wipe-and-load minority, user-state migration is USMT hardlinking where the disk survives and a state migration point where it doesn't. The technology is fine. The failure mode is scope: nobody in the building can actually tell you what user data matters until you delete something.
We handle this contractually rather than technically. The migration standard, signed off by the client's IT leadership before the first pilot, says exactly what USMT captures: profile documents, desktop, favorites, application settings on the supported-app list, and nothing else. PSTs on local disks get flagged in discovery and moved to the Exchange Online archive — this client's mailboxes were already in Office 365 from an earlier program of ours, which turned the PST conversation from a crisis into a checkbox. Anything outside the standard is the user's job to stage on OneDrive or the home drive, communicated three times before the appointment.
The number that matters: our USMT-related ticket rate fell by roughly two-thirds between pilot and production, and every point of that came from communication and the signed scope document, not from XML tuning.
Application compatibility: triage, don't test everything
The instinct on a fleet this size is to test every application against Windows 10. The application inventory said just over 1,100 distinct titles. Testing all of them would have consumed the calendar and delivered nothing, because most of that list is versions, dead weight, and utilities nobody installed on purpose.
We triaged instead. Rationalization first: collapse versions, kill the abandonware, and get the list under 300 titles that anyone would defend in a meeting. Then three buckets: vendor-attested compatible (believe the vendor, verify in pilot), business-critical requiring formal testing (this estate had 40-odd, mostly line-of-business and anything touching hardware), and everything else, which gets tested by the pilot rings for free. Pilot users are your compatibility lab; choose rings that cover departments, not just IT volunteers who all run the same six apps.
The genuine blockers numbered in the single digits: one LOB client pinned to an ancient Java runtime, one document-management integration, and a shim-able install-time version check. That's the honest shape of Windows 7 to 10 app-compat in 2018 — smaller than feared, but concentrated exactly on the applications the business cannot function without.
After the migration: servicing is the new project
The uncomfortable news we deliver in every closing readout: you don't finish a Windows 10 migration. Windows as a service means feature updates on a cadence — we're deploying 1709 today and 1803 is expected within weeks — and the estate needs standing servicing rings, not another project in three years.
We leave clients with a ring structure in SCCM: an IT ring at release plus two weeks, a pilot ring of roughly five percent of the fleet chosen for department coverage at release plus six weeks, and broad deployment gated on pilot exit criteria rather than a calendar date. The task sequence you built for 7-to-10 becomes the feature-update vehicle with minor edits, which is the best argument for having kept it boring.
If you're facing this
If you're staring at a Windows 7 fleet and doing the January 2020 math, the constraint is almost never the task sequence — it's app triage, drivers, and weekly throughput, and those can be measured in a two-week assessment. We've run this program at enterprise scale on SCCM and are happy to compare notes on yours. Get in touch and bring your application inventory; we'll tell you honestly which bucket your timeline falls into.