Moving Intune-managed devices between tenants means un-enrolling and starting over

Someone will ask you to "just move the laptops to the new tenant." There is no button for that. Intune enrollment is glued to the tenant, so the honest answer is: the device leaves the old one and enrolls fresh into the new one — and you rebuild what it used to have.

New to cloud? CAMPUX is a free, build-first course. Start here →

This is one of the sharper edges in a company split or acquisition, and it is part of the Azure tenant-to-tenant migration guide. People expect device management to work the way a mailbox move works — flip a setting, watch it repoint. Intune does not do that. A managed device belongs to exactly one tenant, and Microsoft does not publish a feature that lifts a device from one tenant and drops it, still managed, into another. When you read the official migration guidance, the tenant-to-tenant note is blunt: users have to un-enroll the device from the old tenant and then re-enroll it in the new one. Everything else in this article is the consequence of that one sentence.

Why enrollment is bound to the tenant

Intune does not store identities of its own. It leans on Microsoft Entra ID for who the user is, which groups they belong to, and whether the device has a registered identity at all. Before a device can enroll, the user authenticates and the device establishes an identity in your organization's Entra ID — that registration is a prerequisite for management. Enrollment then installs an MDM certificate on the device that lets your tenant enforce its policies. That certificate, the device record, the Entra identity, the group memberships that decide which policies land — all of it lives inside one tenant's directory. The new tenant is a different directory with different object IDs. Nothing on the device points at it, and there is no supported path to rewrite those pointers in place. So the device does not move. It is released by one tenant and claimed by another.

The un-enroll, re-enroll reality

Strip away the wishful thinking and the sequence is plain. The device un-enrolls from the source tenant, which pulls its MDM certificate, drops its compliance state, and removes the configuration your old tenant pushed. Then it enrolls into the target tenant and, on the first check-in, starts pulling that tenant's policies. In between there is a window where the device is unmanaged: no compliance record, so Conditional Access may lock the user out of corporate resources until the new enrollment completes. That gap is the whole risk. It is not a data-copy operation and it is not instant.

The device does not move. One tenant lets go, and the other picks it up bare.

Whether the user also gets wiped depends on how the device was enrolled in the first place. A personal phone that enrolled through Company Portal usually re-enrolls with a sign-out and sign-in, no reset. A corporate machine provisioned through Windows Autopilot or Apple automated device enrollment is a different story — those enrollment programs are tied to the old tenant, and Microsoft's own enrollment tables mark automated-enrollment platforms as requiring a factory reset before they can enroll somewhere new. A reset means the user's local state goes with it. That is the difference between a five-minute re-sign-in and a rebuild-your-whole-laptop afternoon, and it is worth knowing before you promise anyone a smooth cutover.

What you rebuild in the target tenant

The device is only half of it. The policies, apps, and profiles that made the device useful do not travel on the device — they live in the source tenant and have to be recreated in the target. Microsoft ships Graph and PowerShell sample scripts that export and import some policy types, and they help, but the coverage is deliberately partial. The gaps are not random: anything anchored to something tenant-specific breaks.

Corporate versus BYOD, and staging it so nobody gets surprised

Split the fleet by how it enrolled, because that decides the pain. BYOD phones and personal Macs generally re-enroll through Company Portal with no wipe, so those users mostly need clear instructions and a short outage. Corporate-provisioned devices — Autopilot Windows machines, Apple automated device enrollment, Android fully managed — usually need a reset and re-provisioning, which is real work and real downtime per device. One trap on Windows: use a normal "Reset this PC" to re-provision into the new tenant, not the Autopilot Reset action, because Autopilot Reset leaves the device managed by the old tenant instead of triggering a fresh enrollment.

However you stage it, do it the way Microsoft stages its own migrations — in phases, with a pilot group first, and never with a hard deadline your help desk cannot absorb. The un-enroll step leaves devices unmanaged and vulnerable until they re-enroll, so keep that window short and communicated. Tell users in advance whether their device will be wiped, when, and what they need to back up. A device that gets reset without warning is not a migration event, it is a support fire and a trust problem. Build the target tenant's policies, compliance rules, and apps first, so that the moment a device enrolls it lands on a fully configured tenant rather than an empty one.

The takeaway

There is no native cross-tenant device move in Intune, and pretending otherwise is how migrations go sideways. Enrollment is bound to the tenant, so each device un-enrolls from the source and re-enrolls into the target, its policies and apps rebuilt there rather than copied across. BYOD tends to re-enroll cleanly; corporate-provisioned devices often need a reset. The professional version of this task is not finding a hidden button — it is inventorying the fleet by enrollment type, rebuilding the target tenant ahead of time, and staging the cutover in phases so no user watches their laptop wipe itself without being told.

Questions people also ask

Can you move an Intune device to another tenant?

Not directly. There is no native feature that transfers a managed device from one tenant to another, and Microsoft does not list tenant migration as a supported device scenario. Enrollment is bound to the tenant that holds the device identity, so the device has to un-enroll from the source and enroll fresh into the target.

Do you have to wipe a device to move it to a new tenant?

Sometimes. Whether a reset is required depends on the platform and how the device was enrolled. User-driven BYOD enrollments through Company Portal generally re-enroll without a wipe, while provisioned corporate enrollments like Apple automated device enrollment and Windows Autopilot usually need a factory reset to pick up the new tenant's profile.

Can you migrate Intune policies between tenants?

Partly. Microsoft documents exporting and importing some policies with Graph and PowerShell, but the coverage is incomplete. Anything tied to a certificate, an app source file, or a group ID does not carry over cleanly — SCEP profiles, VPP and line-of-business apps, and assignments all have to be rebuilt or re-linked in the target tenant.

What happens to a device when you un-enroll it from Intune?

It stops receiving your policies and loses its compliance state, so Conditional Access may block it from corporate resources until it re-enrolls. Depending on the action, company data and configuration profiles are removed. The device sits unmanaged and exposed in that gap, which is why you keep the window between un-enroll and re-enroll short.

Is the process different for corporate versus BYOD devices?

Yes. BYOD phones and personal machines usually re-enroll with a sign-out and sign-in through Company Portal, no wipe. Corporate-provisioned devices — Autopilot, Apple automated device enrollment, Android fully managed — are tied to enrollment programs in the old tenant and typically need a reset and re-provisioning before they attach to the new one.