Rebuilding Autopilot after an enrollment tenant change

Autopilot registrations belong to a tenant, and a device can be registered to exactly one. That is fine until an acquisition, a divestiture, or a tenant consolidation means a few hundred laptops need to boot into a different tenant's out-of-box experience. Nothing about that is automatic, and the parts that people expect to be hard (the new tenant) are easy while the part they expect to be easy (the old tenant) is where the project stalls.

The rule that governs everything

A device's hardware hash is registered to one tenant. If you upload the same hash to a second tenant while the first registration exists, the upload fails with an error saying the device is already assigned to another tenant — it tells you the tenant's name, and nothing else. There is no override, no support process that moves a registration, and no waiting period after which it lapses. The old tenant must release the device first.

Plan the project around that sentence. Everything else is mechanics.

Phase 1: inventory in the old tenant

In the source tenant's Intune admin center → Devices → Enrollment → Windows Autopilot devices, export the list. You need serial numbers, and you need to reconcile them against the devices you actually intend to move; a decade of Autopilot use accumulates registrations for machines that were recycled years ago.

Two things to check per device:

• Is it currently enrolled in Intune (as opposed to merely registered for Autopilot)? Enrolled devices need to leave Intune and Entra as well, or the user's next sign-in will produce confusing conditional-access results against the wrong tenant.
• Does it have a group tag or deployment profile you want to reproduce? Note them; nothing carries over.

Phase 2: deregister from the old tenant

For each device, in the source tenant:

1. If the device is enrolled, retire or wipe it from Intune. Retire removes management; wipe resets it. Either is fine for the purposes of Autopilot, and wipe is what you will do on the device anyway.
2. In Windows Autopilot devices, select the device and Delete. This removes the Autopilot registration and, after a short delay, the associated Entra device object. Microsoft's guidance is to delete the Autopilot registration first and let it clean up the Entra device — deleting the Entra device first can leave the registration stuck.
3. Wait. The deletion is asynchronous. In practice most registrations release within a few minutes; some take hours. If the new tenant's upload still reports "assigned to another tenant" a day later, open a support case in the old tenant — this is the one step where support engagement is sometimes required, and it is why you do phase 2 for a pilot batch first.

For bulk work, Get-AutopilotDevice and Remove-AutopilotDevice from the community WindowsAutopilotIntune module, or the Graph endpoints under deviceManagement/windowsAutopilotDeviceIdentities, do this at scale. Keep the export from phase 1 so you can confirm every serial actually left.

If you no longer have admin access to the old tenant — a divestiture where the other side has moved on — the devices cannot be re-registered until someone with access there deletes them. Get that agreement in writing early.

Phase 3: register in the new tenant

Three routes, from best to most laborious:

• OEM or reseller registration. Dell, HP, Lenovo, Microsoft Surface and most CSPs can register serials directly to a tenant ID, and can do it for devices already in the field if you supply the serial list and a signed authorisation. This is the cleanest route for hundreds of devices and needs no hash collection.
• Hardware hash upload. Collect hashes with Get-WindowsAutopilotInfo -Online on each device, or its offline CSV variant, and import in the new tenant. This means touching each device with a logged-in admin session, or scripting it into the old tenant's Intune before you retire it (a proactive remediation that collects the hash to a share is a common pattern).
• Autopilot device preparation — the newer, group-based model. Devices are not pre-registered at all; a device preparation policy targets an Entra device group, and the device is added to that group during OOBE by a user who is a member of the assigned user group. This removes the whole hash-registration problem, at the cost of a slightly different OOBE and a shorter list of supported scenarios (no pre-provisioning, no self-deploying mode at the time of writing). For a tenant move, it is worth considering as the target state rather than reproducing the classic model.

Rebuild deployment profiles, group tags, dynamic device groups, and the enrollment status page in the new tenant before you upload a single hash. A device that lands in the new tenant with no profile assigned just does a normal OOBE.

Phase 4: the device itself

Registration is one thing; the operating system on the device is still joined to the old tenant. Each device needs a reset. Options:

• Autopilot Reset from the old tenant (if still enrolled) or a local Reset this PC with Remove everything — the device restarts into OOBE, contacts the Autopilot service, finds the new tenant's profile, and proceeds.
• A USB reinstall if the device is in a state where reset fails.

There is no path that avoids a reset. Users need their data in OneDrive and their apps deployable from the new tenant, which is a tenant migration prerequisite, not an Autopilot one.

BitLocker: recovery keys are escrowed to the old tenant's Entra. Export them before deleting device objects there, or you will meet one at the worst moment.

Sequencing that works

1. Build the new tenant's Autopilot configuration completely.
2. Pilot ten devices through phases 2, 3 and 4 end to end. Measure how long deregistration takes in your tenant.
3. Batch the rest by site or team, deregistering a batch the day before it is reset.
4. Keep the phase 1 export until the last device is confirmed in the new tenant.

Downtime per device is the reset plus enrollment — an hour or two per machine, more if apps are heavy. Plan it around the user, not the admin.