Zero-touch provisioning with Autopilot: a migration playbook

Why order of operations matters here

Autopilot migrations fail less often on the technology and more often on sequencing — turning it on for a pilot group before the dependencies it needs (hardware hash upload, group tagging, app assignment parity) are actually in place. This playbook is the sequence that got an 1,800-device estate across without a forced re-image on any of them.

Phase 1 — Inventory and hash collection, before touching config

Confirm every device model in scope is on a supported firmware/TPM baseline. Older devices without TPM 2.0 are the single most common blocker discovered after a pilot starts, not before.
Collect hardware hashes for the full scope, not just the pilot. Use the Get-WindowsAutopilotInfo script run at imaging time (OEM registration is the better long-term path, but retrofitting hash collection onto an existing estate needs this).
Group-tag at hash-upload time, not afterwards. Retroactively re-tagging devices already enrolled is more fiddly than getting the tag right on the way in.

Phase 2 — Build app and policy parity before the first real pilot device

The single biggest source of pilot failure: a device goes through Autopilot and lands on a desktop missing three applications the user actually needs on day one, because those apps were "just part of the image" and nobody translated them into Intune app assignments.

Build a side-by-side checklist: every app in the current image, mapped to its Intune equivalent (Win32 app, MSIX, or Store) and its assignment group.
Don't assume Group Policy settings have an Intune-native equivalent one-to-one. Budget time for the ones that need Administrative Templates (ADMX) import or a settings catalog profile instead.
Get compliance policies and Conditional Access rules built and tested against a non-production group before any real user hits enrollment — a misconfigured Conditional Access rule at this stage locks users out of mail on their first day with the new device, which is the fastest way to lose trust in the migration.

Phase 3 — Pilot with a group that can tolerate friction

Pick a pilot group with two properties: they're technically forgiving, and their day-to-day work would surface real gaps (not just email and a browser). IT itself is a common, reasonable first pilot group for this reason.

Run the pilot on new hardware first, not existing devices being wiped — this isolates "does Autopilot + app assignment actually work" from "does the wipe/re-enroll path work," which is a separate failure mode.
Only after new-hardware Autopilot is clean, pilot the wipe-and-reset path on a small group of existing devices.

Phase 4 — Staged rollout, not big bang

Roll out by group tag, in waves sized to what the service desk can actually absorb — not by how fast the technology allows. The technology can enroll thousands of devices a day; the constraint is always support capacity for the inevitable app-gap tickets in the first week of each wave.

What we'd do differently next time

Start OEM hash registration (Autopilot Deployment Program via reseller) six months before the migration, not during it — retrofitting hash collection onto devices already in the field is the most tedious part of the whole project.
Build the app-parity checklist as a living document from week one of planning, not as a pre-pilot scramble.