Introduction

A device management migration can bring the new Intune tenant online while Windows devices still enroll into the old one. Compliance policies never apply in the target tenant, Autopilot devices keep joining the retired management environment, or one device batch lands correctly while another still uses the previous tenant because enrollment profiles, MDM authority settings, and device records often persist long after the backend move.

Treat this as an enrollment-targeting problem instead of a generic Intune sync issue. Start by checking which tenant, enrollment profile, and MDM discovery path an affected device actually uses, because migrations often validate the new Intune portal while devices or provisioning flows continue following older enrollment associations.

Symptoms

  • Devices still enroll into the old Intune tenant after migration
  • Compliance, configuration, or app policies never appear in the new tenant
  • Autopilot or zero-touch devices join the retired management environment
  • One enrollment method works while another still uses the previous tenant
  • Enrollment fails only after the old tenant configuration is removed
  • The issue started after moving Intune, MDM authority, or endpoint management infrastructure

Common Causes

  • Enrollment profiles or Autopilot assignments still belong to the old tenant
  • MDM discovery, device enrollment restrictions, or corporate identifiers still reference the previous environment
  • Devices retain stale workplace join or MDM registration state from the old tenant
  • Provisioning packages, OEM enrollment flows, or scripts still target the retired tenant
  • One identity or region-specific enrollment path was updated while another still uses the old configuration
  • Validation confirmed the new tenant was ready but did not verify where real devices actually enrolled

Step-by-Step Fix

  1. Capture one affected device and record the tenant association, enrollment profile, and current MDM registration it actually uses, because the live enrollment binding determines where policy and management traffic go.
  2. Compare that active device-management path with the intended post-migration tenant design, because one stale profile or registration record can keep many endpoints tied to the retired tenant.
  3. Review Intune enrollment profiles, Autopilot assignment, MDM discovery settings, device records, and provisioning scripts for references to the old tenant, because endpoint enrollment usually spans identity, device, and provisioning layers.
  4. Check Autopilot devices, manually enrolled devices, and existing corporate devices separately if behavior differs, because migrations often fix one onboarding path while another still follows the previous tenant.
  5. Update the authoritative enrollment configuration and clear stale device-management associations where required so affected endpoints join the intended tenant, because creating the new tenant alone does not retarget already known devices.
  6. Run a controlled enrollment from an affected scenario and confirm the device appears in the intended Intune tenant and receives current policy, because a successful sign-in does not prove the right management backend was selected.
  7. Verify the old tenant no longer receives new enrollments or check-ins from migrated devices, because split endpoint management can stay hidden while both tenants remain accessible.
  8. Review licensing, conditional access, and device cleanup timing if enrollment still fails, because the destination can be correct while old registrations or identity controls still block reassignment.
  9. Document which team owns Autopilot assignment, MDM discovery, and tenant-cutover validation so future Intune migrations verify the real enrollment target before retiring the previous tenant.