Intune Tenant to Tenant Migration – Step by Step Guide

• Last updated: 08 September 2026
• Intune,Migration
• Editorial Team

If your organization is splitting, merging, or consolidating Microsoft 365 tenants, mailboxes and SharePoint sites are only part of the job. The devices your employees use every day, the laptops, tablets, and phones enrolled in Microsoft Intune, do not move the same way. There is no button that repoints a managed device from one tenant to another, and treating device migration as an afterthought is one of the most common reasons IT teams get blindsided during a Microsoft 365 tenant migration project.

This guide breaks down exactly what happens to Intune-managed devices during a tenant to tenant migration, which policies survive the move and which do not, how Windows Autopilot fits into the process, and the realistic timeline your team should plan around.

• Key takeaway: Microsoft does not offer a native Intune tenant to tenant migration path. Every device must be unenrolled from the source tenant and re-enrolled in the destination tenant.
• Key takeaway: Some policies, including Wi-Fi, VPN, and email profiles without certificates, can be exported and imported using Microsoft Graph PowerShell. Certificate-based profiles, line-of-business apps, and Endpoint detection and response policies cannot.
• Key takeaway: Devices must be deregistered from Windows Autopilot in the source tenant before they can be re-registered in the destination tenant.
• Key takeaway: A full factory reset is the Microsoft-supported path, but Bulk Primary Refresh Token provisioning packages can move Entra ID joined devices without wiping user data in most cases.
• Key takeaway: Plan for 15 to 30 minutes of hands-on work per device using a scripted approach, or several hours per device if every policy is rebuilt manually.

What Is Intune Tenant to Tenant Migration?

Intune tenant to tenant migration is the process of moving device management, policies, and enrollment records from one Microsoft Intune tenant to another, typically during a merger, acquisition, divestiture, or tenant consolidation project. Unlike moving a mailbox or a SharePoint site, a device migration does not transfer existing objects between tenants. It removes the device from the source tenant’s management and rebuilds that management relationship from scratch in the destination tenant.

This distinction matters because most IT teams planning a broader Microsoft 365 migration assume device management will move the same way mailboxes and files do. It will not, and underestimating the device workstream is one of the most common causes of schedule overruns in multi-workload tenant projects.

Organizations run into this scenario most often in a few situations:

• A company is acquired and its device fleet needs to move into the parent organization’s tenant
• A business divests a division and spins up a separate tenant for it
• Multiple regional or legacy tenants are being consolidated into one
• A commercial tenant is moving to a Microsoft 365 Government (GCC) environment

Does Microsoft Support a Native Intune Tenant to Tenant Migration?

No. Microsoft does not offer a supported, native path for moving an Intune-managed device directly from one tenant to another. Microsoft’s own migration documentation states plainly that a device enrollment is bound to the tenant that issued it, and the only supported route is to unenroll the device from the source tenant and enroll it fresh in the destination tenant.

This is different from Exchange Online, OneDrive, or SharePoint, where Microsoft’s cross-tenant migration tooling and partner platforms like BitTitan MigrationWiz or ShareGate can copy content directly between tenants. Device identity in Intune is tied to Microsoft Entra ID, and Entra ID is tenant-specific by design. A device cannot hold two active management relationships with two different tenants at once, so the source relationship has to end before the destination one can begin.

What you can move are certain policy definitions, using Microsoft Graph and PowerShell scripts. What you cannot move is the live enrollment record itself, or the specific certificate, app, and identity bindings tied to it.

What Happens to Devices During an Intune Tenant to Tenant Migration?

Each device is unenrolled and deregistered from the source tenant, then reset or reprovisioned before it enrolls fresh in the destination tenant and rebuilds its policies from scratch. The exact mechanics depend on how the device was originally joined.

• Microsoft Entra ID Joined Devices

  Devices that are Microsoft Entra ID joined (formerly Azure AD joined) are the most straightforward case. Once unenrolled and removed from Windows Autopilot in the source tenant, they can, in many cases, be moved without a full factory reset if the migration is handled through a scripted provisioning package. The device is signed out of the source tenant identity, rejoined to the destination tenant, and re-enrolled in the destination Intune instance.

• Microsoft Entra Hybrid Joined Devices

  Hybrid Entra joined devices, meaning devices joined to an on-premises Active Directory domain and registered with Entra ID, are more complex. Converting a hybrid joined device to a clean Entra ID joined state in a new tenant generally requires a Windows reset, since the on-premises domain relationship does not carry across tenant boundaries. Organizations with a hybrid environment should budget extra time for this workload specifically.

• Mobile Devices (iOS, iPadOS, Android)

  Mobile devices follow a similar unenroll and re-enroll pattern, but supervised iOS and iPadOS devices tied to Apple Business Manager, and Android devices enrolled through Android Enterprise, need their respective Apple or Google management portals reconfigured for the destination tenant before re-enrollment will succeed cleanly.

Which Intune Policies Can You Export and Import Between Tenants?

Settings catalog and custom configuration policies generally export and import cleanly through Microsoft Graph PowerShell, while apps, certificate-dependent profiles, and Endpoint detection and response policies do not transfer and must be reconfigured in the destination tenant. Microsoft publishes a specific compatibility list, and the pattern comes down to one thing: anything tied to a tenant-specific ID, whether that is a root certificate, a group object, or a Defender for Endpoint instance, breaks on import.

Policy or Profile Type	Migrates?	Why
Compliance policy assignments	Export only	Assignments target a group ID, and that ID is different in the new tenant
Wi-Fi, VPN, and email profiles	Depends	Imports cleanly if no certificate is referenced; fails if one is
SCEP certificate profiles	No	Tied to a root certificate ID that is unique per tenant
Win32, LOB, and store-linked apps	No	Requires original source files or a fresh store account link
Endpoint detection and response	No	Linked to Microsoft Defender for Endpoint, which is tenant-specific
Settings catalog and custom policies	Yes	No certificate or group dependency, so it exports and imports as-is

A practical note worth planning around: even policies marked “export only” still save time. Having the source configuration as a JSON file means your team is recreating a policy from a known-good template rather than reverse-engineering settings from scratch, which is a meaningful head start even when a straight import is not possible.

How Do You Migrate Intune Devices Using Microsoft Graph and PowerShell?

Microsoft provides sample Graph PowerShell scripts on GitHub that export supported Intune policies to JSON files, which are then imported into the destination tenant using matching import scripts. This is the officially documented method, and it works well for policy definitions, though not for the device enrollment itself.

Before starting, note that support for the legacy AzureAD PowerShell module ended in March 2025. Any script or internal documentation referencing AzureAD PowerShell needs to be updated to use the Microsoft Graph PowerShell SDK instead, or the scripts will fail against current tenants.

• Download the sample scripts. Microsoft’s powershell-intune-samples repository on GitHub contains export and import scripts organized by policy type, including compliance policies, configuration profiles, and app protection policies.
• Install the Microsoft Graph PowerShell module. This replaces the retired AzureAD and MSOnline modules and handles authentication to both the source and destination tenants.
• Run the export script against the source tenant. Sign in with an account that has the appropriate Intune administrator role, and specify a local folder to save the exported JSON files.
• Review each exported policy before import. Strip out or flag any policy referencing a certificate, since these need to be rebuilt manually rather than imported as-is.
• Run the import script against the destination tenant. Sign in with an Intune administrator account in the target tenant and point the script to the JSON files from the export step.
• Verify in the Intune admin center. Confirm each imported policy appears correctly and reassign it to the appropriate groups, since group assignments do not carry over automatically.

Microsoft is explicit that these are sample scripts, not a packaged migration product. They should be tested in a non-production tenant first, and your organization’s security team should review them against internal policy before they touch a live environment.

How Does Windows Autopilot Factor Into an Intune Tenant to Tenant Migration?

A device registered with Windows Autopilot in the source tenant must be deregistered there before it can be re-registered in the destination tenant, since Autopilot registration, like Intune enrollment, is tenant-specific. Skipping this step is one of the most common causes of failed re-enrollment attempts during device migrations.

The Autopilot side of a migration typically involves:

• Exporting the hardware hash for every device that needs to move, either through the existing MDM record or by running a PowerShell script on each machine
• Removing the device’s Autopilot registration from the source tenant, either manually or in bulk through Graph API calls
• Importing the hardware hashes into the destination tenant’s Autopilot service
• Assigning the correct Autopilot deployment profile and Entra ID device group tag in the destination tenant so the device provisions with the right out-of-box experience

For organizations buying new hardware as part of the migration rather than moving existing devices, this step is simpler: new machines can be registered directly with the destination tenant’s Autopilot service by the OEM or reseller, bypassing the deregister and re-register cycle entirely.

Can You Migrate Intune-Managed Devices Without Wiping Them?

In many cases, yes. Microsoft Entra ID joined Windows devices can be moved to a new tenant without a full factory reset using a Bulk Primary Refresh Token provisioning package built with Windows Configuration Designer, though this is not Microsoft’s officially documented default method. The Microsoft-supported default remains unenroll, reset, and re-enroll.

The no-wipe approach, commonly used by third-party and community-built migration tools, works roughly like this: a provisioning package containing a Bulk Primary Refresh Token authenticates the device to the destination tenant during a scripted process. Once the user signs in with destination tenant credentials, scheduled tasks update the device’s primary user, Entra ID device group tag, and device category, and the device registers itself with the destination tenant’s Autopilot service, all without erasing local user data and files.

This method can bring per-device migration time down to 15 to 20 minutes with minimal user disruption, compared to the hours a full reimage and data restore can take per machine. The trade-off is that it requires more upfront engineering, including app registrations in both tenants, careful script configuration, and thorough testing on a pilot group before a wider rollout. Organizations without in-house scripting resources typically get better, faster results working with a partner who has already built and tested this workflow rather than developing it from scratch under deadline pressure.

What Are the Common Challenges in Intune Tenant to Tenant Migration?

The most common challenges are certificate-dependent profiles that cannot import, line-of-business apps that need original source files, broken Endpoint detection and response coverage, and BitLocker recovery keys that do not follow the device automatically. Each has a workaround, but each also needs to be planned for rather than discovered mid-migration.

• Certificate profiles fail on import. SCEP, Wi-Fi, and VPN profiles that reference a root certificate cannot be imported as-is, since the certificate ID is unique per tenant. These need to be rebuilt against the destination tenant’s certificate infrastructure.
• Line-of-business apps need source files. Android, iOS, and Windows LOB apps do not carry their installer files during export. Your team needs the original .apk, .ipa, or .intunewin files on hand to re-upload them in the destination tenant.
• Endpoint detection and response has to be reconfigured. Since this policy type is tied to Microsoft Defender for Endpoint at the tenant level, security teams need to set up onboarding for the destination tenant separately rather than expecting existing coverage to transfer.
• BitLocker recovery keys stay with the source tenant. If devices are encrypted, recovery keys escrowed to the source tenant’s Entra ID do not automatically appear in the destination tenant. Plan to either export and securely archive these keys beforehand or trigger new key escrow after re-enrollment.
• Assignments break silently. Even policies that export successfully lose their group assignments, since group object IDs are unique to each tenant. Every imported policy needs to be manually reassigned to the correct groups in the destination tenant.

What Should You Check Before Starting an Intune Tenant to Tenant Migration?

Before moving a single device, confirm the destination tenant’s licensing, group structure, Autopilot profiles, and certificate infrastructure are fully built out, since device re-enrollment will fail or produce inconsistent results if any of these are missing. Most migration delays trace back to a gap in this preparation stage rather than a problem during the device move itself.

• Confirm Intune and Windows licensing is assigned to every user in the destination tenant before their devices attempt to re-enroll, since an unlicensed user will fail enrollment even if every policy is configured correctly.
• Rebuild your security and device groups in the destination tenant ahead of time, matching the source tenant’s structure closely enough that policy reassignment after import is straightforward rather than improvised.
• Pre-stage Autopilot deployment profiles so devices land in the correct enrollment status page experience the moment their hardware hash is imported, rather than sitting unconfigured after re-registration.
• Inventory every certificate-dependent profile in the source tenant so your team knows in advance which Wi-Fi, VPN, and email profiles will need to be rebuilt rather than discovering the failure during import.
• Gather original app installer files for Win32 and line-of-business apps ahead of the migration window, since tracking down a missing .intunewin or .ipa file mid-project stalls the whole wave.
• Communicate the enrollment change to end users in advance, particularly if a factory reset is involved, so they back up any files stored outside OneDrive or SharePoint before their device is wiped.

Organizations moving into a Microsoft 365 Government tenant should add one more item to this list: compliance and Conditional Access baselines in GCC and GCC High environments are often stricter than commercial tenants, so policies that worked in the source tenant may need adjustment, not just reassignment, before they are reapplied.

How Long Does an Intune Tenant to Tenant Migration Take?

A scripted, no-wipe migration typically takes 15 to 30 minutes of active work per device, while a manual unenroll, reset, and rebuild approach can take several hours per device once policies, apps, and certificates are reconfigured. The total project timeline scales with fleet size and how many policy types are in scope.

Fleet Size	Scripted / No-Wipe Approach	Manual Reset and Rebuild
Under 50 devices	2 to 4 business days	1 to 2 weeks
50 to 250 devices	1 to 2 weeks	3 to 6 weeks
250 to 1,000 devices	2 to 4 weeks	2 to 3 months
1,000+ devices	4 to 8 weeks	3 to 6 months or more

These ranges assume a reasonably well-documented existing policy set. Add extra time if your environment includes heavy certificate use, a large number of line-of-business apps without accessible source files, or a hybrid Entra join configuration that forces device resets across the fleet.

What Is the Best Approach for Migrating Intune-Managed Devices During a Tenant Migration?

Migrate identity first, content second, and devices last, running the device migration in phased waves alongside a pilot group rather than attempting a single cutover for the entire fleet. This sequencing matters because device re-enrollment depends on user identities and group structures already existing correctly in the destination tenant.

A practical rollout sequence looks like this:

• Confirm user accounts, security groups, and licensing are fully provisioned in the destination tenant before touching any devices
• Export the supported policy set from the source tenant and pre-stage equivalents in the destination tenant, including Autopilot deployment profiles
• Run a pilot wave of 5 to 10 devices covering each join type in your environment (Entra ID joined, hybrid joined, and mobile) to validate the process end to end
• Resolve any issues surfaced in the pilot, particularly around certificate profiles, app deployment, and Conditional Access policies
• Roll out in scheduled waves, monitoring enrollment success rates and help desk ticket volume between each wave

Organizations that also use Conditional Access and Enterprise Mobility + Security policies should treat those as part of the device workstream too, since access policies referencing the source tenant’s device compliance state will need to be rebuilt against the destination tenant’s device population before enforcement is turned back on.

One option worth considering for organizations replacing hardware anyway: provisioning Windows 365 Cloud PCs in the destination tenant sidesteps physical device migration entirely for those users, since a Cloud PC is provisioned fresh in whichever tenant it belongs to rather than needing to be unenrolled and re-enrolled like a physical machine.

FAQs About Intune Tenant to Tenant Migration

1. Can Intune devices be migrated between tenants without a factory reset?

   In many cases, yes. Microsoft Entra ID joined Windows devices can be moved using a Bulk Primary Refresh Token provisioning package that reassigns the device to the destination tenant without erasing local data. This is not Microsoft’s default documented method, so it typically requires a scripted setup rather than a built-in feature.

2. Does Microsoft offer a native Intune tenant to tenant migration tool?

   No. Microsoft’s supported path is to unenroll the device from the source tenant and enroll it fresh in the destination tenant. Some policy definitions can be exported and imported using Microsoft Graph PowerShell scripts, but the device enrollment itself does not transfer directly.

3. What happens to Windows Autopilot registration during a tenant migration?

   The device must be deregistered from Windows Autopilot in the source tenant before it can be registered with Autopilot in the destination tenant. This typically involves exporting the device’s hardware hash, removing the source registration, and importing the hash into the destination tenant’s Autopilot service.

4. Can Intune compliance policies be migrated to a new tenant?

   Compliance policies themselves can be exported and imported using Microsoft Graph PowerShell, but the group assignments attached to them cannot, since group object IDs are unique to each tenant. Each imported policy needs to be manually reassigned to the correct groups in the destination tenant.

5. Do Wi-Fi, VPN, and SCEP certificate profiles migrate between Intune tenants?

   Wi-Fi and VPN profiles migrate successfully if they do not reference a certificate. If they do, or if the profile is a SCEP certificate profile, the import fails because the root certificate ID is unique to each tenant. These profiles need to be rebuilt against the destination tenant’s certificate infrastructure.

6. What happens to BitLocker recovery keys during an Intune tenant migration?

   BitLocker recovery keys escrowed to the source tenant’s Microsoft Entra ID do not automatically transfer to the destination tenant. Organizations should export and securely archive existing recovery keys before migration and confirm new key escrow occurs once devices re-enroll in the destination tenant.

7. How long does an Intune tenant to tenant migration take for a mid-sized fleet?

   For a fleet of 250 to 1,000 devices, a scripted no-wipe approach typically takes 2 to 4 weeks, while a manual reset and rebuild approach can take 2 to 3 months. The exact timeline depends on how many certificate-based profiles, line-of-business apps, and hybrid joined devices are in scope.

8. Can macOS, iOS, and Android devices be migrated the same way as Windows devices?

   The unenroll and re-enroll pattern applies across platforms, but the details differ. Supervised iOS and iPadOS devices need Apple Business Manager reconfigured for the destination tenant, and Android Enterprise devices need the Android management account reassigned before re-enrollment will succeed cleanly.

9. Does Microsoft Defender for Endpoint coverage carry over during device migration?

   No. Endpoint detection and response policies are tied to the Microsoft Defender for Endpoint instance in the source tenant. Security teams need to onboard devices to Defender for Endpoint in the destination tenant separately after re-enrollment rather than expecting existing coverage to transfer.

10. How does Apps4Rent help with Intune tenant to tenant migration?

    Apps4Rent’s migration engineers assess a device fleet’s join type and policy set, then manage the full migration end to end, including Autopilot deregistration and re-registration, certificate profile rebuilds, app redeployment, and Defender for Endpoint onboarding in the destination tenant, as part of a broader Microsoft 365 tenant migration project.