Migrating Intune and Entra ID Devices Between Microsoft 365 Tenants

Tenant-to-tenant migrations are among the most complex projects in the Microsoft 365 world. They arise during mergers and acquisitions, when a business is divested, when a company moves from a partner-managed tenant to their own, or when IT environments are consolidated. Device migration is one of the most operationally sensitive parts of this process because it directly affects end users and their ability to work.

The hard truth: there is no native Microsoft tooling to migrate enrolled devices between tenants. Intune enrolment, Autopilot registration, and Entra join are all tied to a specific tenant. You cannot lift a device from Tenant A and drop it into Tenant B in its current enrolled state. Every device must go through a re-enrolment process. The question is how to do this efficiently, securely, and with minimal user disruption.

Step 1: Prepare the destination tenant. Before touching any devices, the destination tenant must be fully configured. This means Intune policies, compliance policies, configuration profiles, app assignments, and Autopilot profiles should all be in place and tested on a pilot device before the migration begins. Trying to build the destination environment during migration leads to gaps and user-facing issues.

Step 2: Export Autopilot hardware hashes from the source tenant. If the devices were originally enrolled via Windows Autopilot, you need to export the hardware hash CSV from the source tenant's Intune admin centre (Devices > Enrol devices > Windows enrolment > Devices). These hashes will be imported into the destination tenant's Autopilot. Do this before removing anything from the source tenant.

Step 3: Remove devices from the source tenant. In the Intune admin centre, retire and delete each device. This removes management from the device and clears the MDM enrolment. In Entra ID, delete the device object. In Autopilot, delete the hardware hash. You must complete all three steps or the device will attempt to re-enrol into the source tenant on next boot.

Step 4: Import Autopilot hashes into the destination tenant. Upload the hardware hash CSV into the destination tenant's Autopilot. Assign the appropriate Autopilot deployment profile and enrolment status page profile. Assign devices to the correct Autopilot group.

Step 5: Reset and reprovision devices. Perform a Windows Reset on each device (keeping nothing). On first boot, the device will connect to Windows Autopilot, pull the new tenant's configuration, and guide the user through sign-in with their new tenant credentials. The entire setup process is automated. Apps, policies, and settings are applied without any manual IT intervention.

Protecting user data through the migration. Before any device is wiped, confirm that OneDrive Known Folder Move has been running in the source tenant and that all Desktop, Documents, and Pictures content is synced. In the destination tenant, configure OneDrive to connect to the user's new account before migration day so data is available immediately after sign-in.

Common pitfalls to avoid. Deleting devices from Autopilot in the source tenant before exporting hashes means you lose the hardware hash and must re-harvest it from the physical device using PowerShell. Forgetting to remove the Entra ID device object means the device may still attempt to authenticate against the source tenant. Not pre-configuring apps in the destination tenant means users sit waiting for software after migration. Migrating devices before user accounts and licences are provisioned in the destination tenant breaks the Autopilot flow entirely.

Cloud Centrify manages tenant-to-tenant migrations end to end, from destination tenant buildout and Autopilot configuration through to device migration and user data continuity. If you are planning a tenant migration, get in touch early. The earlier we are involved, the smoother the outcome.