Microsoft Entra Joined Device Tenant-to-Tenant Migration

Migrating Microsoft Entra joined Windows devices, formerly Azure AD joined devices, is not a simple tenant-side move. In 2026, successful endpoint migration usually means planned unjoin, unenrollment, user-profile and data handling, and rejoin or re-enrollment into the target tenant with Microsoft Intune, Conditional Access, Windows Autopilot, and endpoint security dependencies rebuilt correctly.

What a device tenant-to-tenant migration really means in 2026

Microsoft Entra joined device objects are tenant-bound. They are not directly migrated from one Microsoft Entra ID tenant to another in the same way that mailboxes or files can be copied. In most projects, device migration means removing or retiring the device from management in the source tenant, preserving or moving the user experience where required, and then joining and enrolling the device into the target tenant.

This is common during mergers, acquisitions, divestitures, tenant consolidations, rebrands, and carve-outs. The endpoint workstream must be coordinated with identity, licensing, Exchange Online, OneDrive, Teams, SharePoint, security, and application migration planning.

Key prerequisite decisions

Before touching devices, confirm these items:

• Administrative access: define source and target roles using least privilege where possible. Typical roles include Microsoft Entra, Microsoft Intune, security, compliance, and device-administration roles.
• Licensing: assign the right Microsoft 365, Enterprise Mobility + Security, Microsoft Intune, Microsoft Entra ID P1/P2, Defender, and Windows licenses in the target tenant before enrollment. If licenses are purchased through CSP New Commerce Experience, plan term commitments and tenant-specific subscriptions early; licenses do not automatically move with users or devices.
• Target Intune readiness: configure enrollment restrictions, device platform rules, compliance policies, configuration profiles, security baselines, app deployment, update rings, Endpoint Privilege Management, Windows LAPS, certificates, Wi-Fi, VPN, and role-based access.
• Domain and UPN plan: a custom domain cannot be verified in two tenants at the same time. Do not assume source and target domains must match during device migration. Plan interim UPNs, domain cutover timing, and user sign-in changes as a separate workstream.
• Conditional Access readiness: define which policies require compliant or hybrid joined devices, what happens during cutover, and whether temporary exclusions or grace periods are needed.
• Autopilot status: identify which devices are registered with Windows Autopilot in the source tenant and how they will be removed, transferred if supported for the scenario, or re-imported into the target tenant.
• Data and profile strategy: decide whether devices will be wiped and reprovisioned, manually rejoined, or migrated with a profile-migration tool.

Endpoint inventory checklist

A reliable inventory prevents surprises. Capture at least the following for each device:

• Device name, serial number, hardware model, ownership, primary user, location, and business unit.
• Windows edition and version, patch status, TPM readiness, Secure Boot status, and local administrator access.
• Microsoft Entra join state, Intune enrollment state, compliance state, and management authority.
• Windows Autopilot registration and assigned Autopilot profile.
• BitLocker status and recovery-key escrow location.
• Microsoft Defender for Endpoint onboarding state and security baseline assignments.
• Installed Microsoft 365 Apps, line-of-business apps, app dependencies, printers, browser profiles, certificates, VPN, Wi-Fi, and mapped resources.
• User data locations, OneDrive Known Folder Move status, local-only data, Outlook cache considerations, Teams state, and browser synchronization state.
• Special cases such as shared devices, kiosks, frontline devices, lab devices, executive devices, developer workstations, and devices with regulated workloads.

Common migration paths

There is no single best method for every organization. Common approaches include:

1. Wipe and reprovision with Windows Autopilot. This is usually the cleanest approach for standard corporate devices. It gives the target tenant a fresh Intune enrollment, target policies, target apps, and a predictable security posture. The tradeoff is user downtime and the need to handle local data and application state.

2. Manual disconnect and rejoin. A technician or user disconnects the work or school account, removes the device from the source tenant where appropriate, and joins the device to the target tenant. This can preserve more of the local Windows installation, but profile, policy, compliance, Windows Hello for Business, cached credentials, and app state issues must be handled carefully.

3. Intune retire or wipe followed by re-enrollment. Retire removes managed data and management profiles where supported, while wipe returns the device to a reset state. The right choice depends on ownership, risk, and whether the device should be rebuilt.

4. Staged migration by department, location, or persona. This reduces risk and helps support teams learn from pilot groups before broader rollout.

5. Third-party user-profile migration. Specialized tools can help map source user profiles to target tenant identities and reduce disruption. These tools do not eliminate the need for Entra join and Intune re-enrollment planning, and they should be tested with your security stack and applications.

Recommended migration process

A practical endpoint migration plan normally follows these phases:

• Discover: inventory devices, users, applications, security dependencies, Autopilot registration, and data locations.
• Design: choose migration paths by device persona, define target Intune architecture, confirm licensing, and document rollback or break-fix procedures.
• Prepare the target tenant: build policies, groups, compliance rules, app deployments, Defender onboarding, certificate connectors, VPN and Wi-Fi profiles, update policies, Windows LAPS, and support roles.
• Pilot: migrate a controlled group of devices representing real user scenarios. Validate sign-in, MFA, Windows Hello for Business, OneDrive, Outlook, Teams, browser sync, VPN, printers, line-of-business apps, and Conditional Access.
• Communicate: give users clear instructions, expected downtime, sign-in changes, MFA prompts, device reset expectations, and support contacts.
• Execute in waves: migrate devices by agreed sequence, track failures, and keep help desk and endpoint engineers aligned.
• Validate: confirm target tenant device objects, Intune enrollment, compliance, Defender onboarding, BitLocker key escrow, app installation, and user access.
• Clean up: remove stale source tenant device objects, old Intune records, source Autopilot registrations when appropriate, orphaned groups, old policies, and obsolete Conditional Access exceptions.

Windows Autopilot and Intune considerations

Windows Autopilot is often central to a modern device migration. Review the source and target Autopilot registrations before the cutover. Devices may need to be removed from the source tenant before they can be registered in the target tenant, depending on ownership, partner relationships, OEM registration, and the current Microsoft-supported process for your scenario.

In the target tenant, validate Autopilot deployment profiles, Enrollment Status Page settings, device naming rules, dynamic groups, app assignment timing, enrollment restrictions, and Windows Autopilot device preparation capabilities where applicable. Test whether required apps install within the expected window and whether security tooling is active before users regain access to sensitive resources.

User profile, data, and application experience

Device migration can be more disruptive than mailbox or file migration because users interact with the local Windows profile every day. Plan for:

• OneDrive Known Folder Move and local-only files before reset or reprovisioning.
• Outlook profile recreation, cache rebuilds, and shared mailbox behavior.
• Teams sign-in, chat context, meeting add-ins, and device permissions.
• Browser profiles, favorites, extensions, passwords, and enterprise sync policies.
• Windows Hello for Business reset, MFA registration prompts, and TPM-bound credentials.
• Certificates, Wi-Fi, VPN, smart cards, printers, and line-of-business app configuration.
• Applications that store data in the local profile or rely on tenant-specific tokens.

Enterprise State Roaming should not be treated as a complete or go-forward profile migration strategy. Validate current Microsoft guidance and use OneDrive, application-specific sync, backup, or profile-migration tooling where needed.

Security and access controls during cutover

Do not leave security controls as an afterthought. During migration, devices may temporarily lose compliance state or device trust in Conditional Access. Plan temporary exclusions or grace periods only where justified, document them, and remove them after validation.

Security items to validate include Microsoft Defender for Endpoint offboarding from the source tenant and onboarding to the target tenant, BitLocker recovery-key escrow, Windows LAPS policies, Endpoint Privilege Management, attack surface reduction rules, firewall settings, certificate deployment, VPN and Wi-Fi authentication, local administrator controls, and emergency access procedures.

Also consider Primary Refresh Token behavior, cached credentials, and sign-in dependencies. After rejoin and re-enrollment, users should receive fresh tokens from the target tenant and devices should become compliant under target policies before accessing protected resources.

Common issues and how to reduce risk

Typical issues include devices still registered in the source tenant, Autopilot conflicts, missing Intune licenses, blocked enrollment due to restrictions, Conditional Access policies requiring compliance too early, BitLocker keys escrowed only in the source tenant, missing certificates, VPN or Wi-Fi failures, stale application tokens, and user data left outside OneDrive.

Reduce risk by running a real pilot, using wave-based execution, documenting a device-by-device status tracker, preparing help desk scripts, validating local administrator or break-glass access, and keeping source tenant cleanup separate from user-facing migration steps.

Related tenant-to-tenant migration workstreams

Endpoint migration should be planned alongside other Microsoft 365 workstreams: Exchange Online, OneDrive, SharePoint Online, Microsoft Teams, Microsoft Entra ID users and groups, Microsoft Entra guest accounts, app registrations and enterprise applications, Microsoft Forms, and Microsoft Viva Engage.

Reviewed for 2026. Microsoft admin center names, supported migration options, Windows Autopilot capabilities, Intune features, and licensing programs change frequently, so validate current Microsoft documentation and tenant-specific constraints before execution.

Key takeaways

• Microsoft Entra joined device objects are not directly moved between tenants; migration normally means unjoin or unenroll, then rejoin and re-enroll in the target tenant.
• Microsoft Intune, Windows Autopilot, Conditional Access, Defender for Endpoint, BitLocker, certificates, VPN, Wi-Fi, and user profiles must be planned together.
• A wipe-and-reprovision approach is often the cleanest for standard corporate devices, but manual rejoin or third-party profile migration may be appropriate for some scenarios.
• Custom domain and UPN planning is separate from device migration; domains cannot be verified in two tenants at the same time.
• Pilot testing, user communication, security validation, and source-tenant cleanup are essential for a low-disruption migration.

Planning a merger, divestiture, or Microsoft 365 tenant consolidation? IT Partner can help assess your Microsoft Entra ID and Intune environment, design the device migration approach, and execute a staged endpoint migration with Autopilot, Conditional Access, Defender, and user-experience requirements in scope.