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.

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.

Reset requirements depend on platform, ownership and enrollment method. BYOD often supports removal of the old management profile or work profile followed by target enrollment without a full device reset. Signing out of Company Portal alone is not a universal unenrollment procedure. Automated corporate enrollment can require a reset and reassignment of enrollment-program records; pilot the exact method before promising downtime or data retention.

From the field: a couple of hundred Windows PCs, one tenant to another

I have done this as part of a full tenant move, with a fleet of just over two hundred Windows PCs alongside the Azure estate that went with them. The technical steps above are the easy part to describe and the hard part to live through, and the things I would say to anyone about to start are not in the Microsoft docs.

The first is that the inventory decides everything, so do it before you promise a date. Every device has to be sorted by how it enrolled, because that single fact tells you whether the user gets a five-minute sign-in or a wiped laptop, and you cannot plan a cutover, write the comms, or size the help desk until you know how many of each you have. The table below is the one I would build first; it takes an afternoon in the Intune admin centre and it saves weeks.

The second is that the target tenant must be finished before the first device leaves the old one. Compliance policies, configuration profiles, the apps, Conditional Access, all of it. A device that enrols into an empty tenant is compliant with nothing, and a Conditional Access policy that requires a compliant device will lock that user out of email the moment they sign in. That is the gap the diagram at the top is warning about, and it is exactly the kind of thing that turns a migration into a support queue.

The third is to pilot on your own team's machines, including the ones that need a reset, and to do it a week before anyone else. You want to find out on IT's laptops that a profile did not import, or that Autopilot Reset left a machine talking to the old tenant, not on the finance director's. And tell people the truth in the comms: which machines will be wiped, on which day, and what to back up. Nobody minds a rebuild they were warned about. Everybody minds the one they were not.

The fourth is Defender for Endpoint, which people forget because it is not Intune. A device onboarded to Defender belongs to the old tenant's Defender just as firmly as its enrolment belongs to the old Intune. It has to be offboarded from the source and onboarded into the target with the new tenant's onboarding package, and the alerts and incidents that were open against it in the old portal do not come across. So before the cutover, go through the old Defender portal and write down every high-severity alert that is still open, with the device and the date, and carry that list into the new tenant by hand. Otherwise the migration quietly closes an investigation nobody finished, and you find out the wrong way.

Before releasing the first device

Record the enrollment method, source/target identities and assignments, required apps, recovery keys, certificates and local data for each device. Test backup restoration and target access with representative pilot devices. Define who verifies successful enrollment and compliance, how long the unmanaged interval may last, and what recovery is available if re-enrollment fails. A reset is destructive; agree the data-preservation procedure with the device owner first.

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. The procedure depends on platform, ownership and enrollment method. BYOD may avoid a full reset, but still needs proper removal of the source management/work profile; Company Portal sign-out alone is not universal. Automated corporate enrollment may require a reset and target enrollment-program reassignment. Validate those requirements on representative devices before migration.

Every class is open to read. A free account saves your progress. Azure resources used for labs may incur charges.

Sources and review

Reviewed 1 October 2026. Clarified platform-specific unenrollment and added a preflight inventory, recovery and target-compliance checklist. Examples are planning guidance; they have not been executed on a customer fleet.

• Intune tenant migration and enrollment requirements
• Unenroll devices and verify removal