Migrating Windows Autopilot Devices Between Tenants with PowerSyncPro

Summary

PowerSyncPro migrates the Windows device and the user profile. The device's Windows Autopilot registration is a separate record held in Microsoft's Autopilot service, and it is not part of the current migration workflow. After a PowerSyncPro migration the device is Entra joined and Intune enrolled in the target tenant, but its hardware hash is still registered to the source tenant's Autopilot service. If that device is ever reset or re-imaged, OOBE will look up the hash, find the source registration, and attempt to join the source tenant.

This article explains why that happens, and describes a process that fixes it without visiting the device or collecting hardware hashes by hand:

Delete the Autopilot registration (and only the Autopilot registration) from the source tenant.
Migrate the device with PowerSyncPro as normal.
Let the target tenant register the device automatically using the Convert all targeted devices to Autopilot setting on an Autopilot deployment profile.
Re-apply group tags and assigned users from an export of the source registrations.

The whole process can be automated with Microsoft Graph, and the last section describes what that automation needs to do.

Note: Microsoft does not support tenant-to-tenant migration of Intune or Autopilot as a scenario. The steps here follow Microsoft's published guidance for transferring Autopilot devices between tenants. Test on a pilot group before running at scale.

How Autopilot registration works

Windows Autopilot identifies a device by its hardware hash, a fingerprint generated on the device from its TPM, firmware, and hardware identifiers. When a device is registered with Autopilot, that hash is stored in Microsoft's Autopilot deployment service and associated with exactly one tenant. During OOBE the device sends its hash to the service, and the service replies with the tenant and deployment profile the device belongs to.

Three things follow from this:

A hash can only be registered to one tenant at a time. Uploading a hash that is already registered elsewhere fails with ZtdDeviceAssignedToAnotherTenant. The source registration must be deleted before the target can take it.
The hash cannot be exported from the source tenant. The Intune admin center export and the Graph windowsAutopilotDeviceIdentities resource return serial number, model, group tag, and assignment details, but never the hash itself. The hash can only be obtained from the device, or from an OEM/partner who registered it.
The registration lives in the Autopilot service, not on the device. The current PowerSyncPro migration workflow operates on the device and the user profile, so the Autopilot registration is left in place in the source tenant and needs to be handled as a separate step.

The good news is that Intune can harvest the hash from an enrolled device itself. That is what makes the process below possible without touching endpoints.

Prerequisites

Source tenant

Intune Administrator (or equivalent) rights to delete Autopilot device registrations.
An app registration with relevant Graph application permissions if automating (see the automation section).

Target tenant

An Autopilot deployment profile configured for the migrated devices, with Convert all targeted devices to Autopilot set to Yes.
A device group that the profile is assigned to, and that migrated devices will land in. A dynamic group based on the device naming convention is the usual approach. Note that migrated devices arrive with no group tag, so a group tag based rule will not catch them until step 4 below is complete.
Intune enrollment configured so that migrated devices can enroll as part of a PowerSyncPro migration. This is a standard part of PowerSyncPro migration setup and is not covered here.

Timing

Delete the source Autopilot registration before running the device migration. It must be gone before the target attempts conversion; if it is not, the conversion fails silently and the device simply never appears in the target Autopilot list.
Do not delete the source Intune managed device or Entra ID device object before migration. Deleting the Entra device object removes the device from the source tenant, which breaks the device itself as well as the migration.
Resetting the device is not part of a PowerSyncPro migration; the whole point is that the device carries on without one. The concern is any future reset, re-image, or Autopilot re-provisioning of the device after migration. Until the device appears in the target tenant's Autopilot device list with a profile status of Assigned, a reset would boot into a plain OOBE with no tenant or profile, so hold off on any planned resets or reprovisioning until verification is complete.

Process

Step 1: Export the source Autopilot registrations

Before deleting anything, export the list of Autopilot devices from the source tenant. This export does not contain hashes, but it contains everything needed to reconstruct the registrations in the target: serial number, model, group tag, assigned user, and the Entra device ID.

From the Intune admin center: Devices > Enrollment > Windows > Windows Autopilot > Devices > Export. Or use Graph (see the automation section).

Keep this file. It is your mapping table for step 5 and your audit trail of what was removed.

Step 2: Deregister devices from the source tenant

Delete the Autopilot registration for each device in scope from the source tenant, and nothing else. From the admin center: Devices > Enrollment > Windows > Windows Autopilot > Devices, select the devices, Delete. Or use Graph (see the automation section).

Intune supports removing a device's Autopilot registration while leaving the device enrolled and in use; this is the capability Microsoft describes in its guidance on transferring Autopilot devices between tenants. Deleting the registration has no effect on the running device, its Entra join, or its Intune enrollment. The device continues to work normally in the source tenant until PowerSyncPro migrates it.

Leave the Intune managed device and the Entra ID device object alone. PowerSyncPro relies on both being present to leave the source tenant correctly. When the migration runs, the device leaves the source Entra tenant and the source Entra and Intune objects are cleaned up as part of that process. Deleting the Entra device object by hand beforehand removes the device from the source tenant before PowerSyncPro has migrated it: users can no longer sign in, the device loses its Intune management, and there is a chance that the device will be wiped when it leaves Intune (by Intune policy).

Points that matter:

If the Autopilot registration has an assigned user, remove the user assignment first. Deletion of a registration with an assigned user fails.
Deregistration is not instant. The Autopilot service can take some time to release the hash after the record is deleted. Allow for this before scheduling the migration, so the hash is free by the time the target tries to register it.
There is no undo. A registration deleted by mistake can only be recreated by uploading the hash again, which means obtaining it from the device.

Do this before the PowerSyncPro migration. PowerSyncPro does not depend on the source Autopilot registration at any point.

Step 3: Migrate the device with PowerSyncPro

Run the migration as normal. The device leaves the source tenant, joins the target tenant, and the user profile is repermissioned. The source Entra ID and Intune device objects are cleaned up as part of leaving. On completion the device is Entra joined in the target and, where enrollment is configured, Intune enrolled.

Nothing about the Autopilot process changes how PowerSyncPro is configured or run.

Step 4: Let the target tenant register the device

Once the migrated device is Intune enrolled in the target and is a member of the group your Autopilot deployment profile is assigned to, the Convert all targeted devices to Autopilot setting takes over. Intune collects the hardware hash from the enrolled device and registers it with the Autopilot service under the target tenant.

This happens on Intune's own schedule and can take several hours. The device will appear under Windows Autopilot > Devices in the target tenant when it is done. No action is required on the device.

Microsoft's description of the setting is in Configure Autopilot profiles.

Two things the conversion does not do:

It does not set a group tag. Devices arrive untagged.
It does not set an assigned user.

Step 5: Re-apply group tags and assigned users

Using the export from step 1, apply the source group tag (or the equivalent tag in the target's scheme) and the assigned user to each converted registration. In the admin center this is done per device from the Autopilot device properties. At scale it should be scripted; see the automation section.

Once tags are applied, any tag-based dynamic groups in the target will populate and the correct deployment profile will be assigned.

Step 6: Verify

For each migrated device, confirm in the target tenant that:

The device appears in the Autopilot device list with the expected serial number.
Profile status shows Assigned.
The Autopilot record is linked to the Entra device object created when PowerSyncPro joined the device (the Associated Microsoft Entra device field is populated) rather than a second, unrelated object.
The group tag and assigned user are correct.

The migrated device has been in service throughout; none of this requires a reset. What verification confirms is that the device is now safe to reset, re-image, or reprovision through Autopilot at any point in the future, and that it will land in the target tenant when it does.

Automating the process with Microsoft Graph

Steps 1, 2, 5, and 6 are all available through Microsoft Graph, so the process can be scripted end to end from an admin workstation with no action on the devices. In outline, a script needs to:

Source tenant

Export the Autopilot device list to CSV: serial number, model, group tag, assigned user. This is the mapping table for everything that follows.
Deregister each device in scope: remove the assigned user if there is one, delete the Autopilot registration, and confirm it is gone. Nothing else in the source tenant is touched.

Target tenant (after PowerSyncPro migration and conversion)

Verify that each serial from the export now appears in the target Autopilot device list, and report any that have not.
Restore the group tag and assigned user onto each converted registration from the export, mapping to the target tenant's tag scheme and UPNs, then trigger an Autopilot sync.

All four operations use the Autopilot device identity resource in Graph, which needs only the DeviceManagementServiceConfig.ReadWrite.All application permission in each tenant. The script does not need, and should not be granted, permissions on Intune managed devices or Entra ID device objects. A dry-run mode for the deregister step is strongly recommended, because deleting a registration cannot be undone.

Endpoint details are in the windowsAutopilotDeviceIdentity Graph API reference.

Frequently asked questions

Can I export the hardware hashes from the source tenant and upload them to the target? No. The hash is not exposed through the admin center export or through Graph. It can only be read from the device itself, or supplied by the OEM or partner who originally registered it. The conversion approach in this article avoids the need for it.

Does PowerSyncPro collect the hardware hash during migration? Not in the current workflow. The conversion approach in this article does not require it.

What if the target tenant uses Windows Autopilot device preparation instead of the classic profiles? Device preparation does not use hardware hashes, so there is nothing to register in the target. The source registration still has to be deleted, otherwise a reset device will find it and attempt to join the source tenant. Steps 1 and 2 still apply; steps 4 and 5 do not. See Windows Autopilot device preparation overview.

Do source and target group tags have to match? No, but a mapping is needed. Group tags drive dynamic group membership and therefore profile assignment, so agree the target tag scheme before the migration and map source tags to it in step 5.

What happens if a device is reset before the target conversion completes? It boots into a standard OOBE with no Autopilot profile, and will need to be joined manually or registered by uploading its hash. The local JSON file described above prevents this.

How long does conversion take? Typically a few hours after the device is enrolled and in the assigned group, but it depends on Intune's processing cycle, it could take as long as 48 hours. Test and verify rather than assuming.