MDM migration: how to move devices between MDM platforms

MDM migration is the process of moving managed devices from one Mobile Device Management (MDM) platform to another: changing the system that enrolls, configures, secures, and monitors a fleet, without losing control of the devices along the way. Organizations migrate for real reasons: a better-fitting platform, a merger or acquisition, consolidating several tools into one, or a change in cost or strategy, and the recurring fear is the same each time: that migration means wiping and rebuilding every device by hand.

For Apple fleets, that fear is now largely outdated. With the iOS 26 line, which shipped in September 2025, Apple introduced native MDM migration that moves eligible devices between platforms without a wipe, changing how migrations should be planned. This guide explains what MDM migration involves, how the Apple flow works and who qualifies for it, what still requires the older approach, how Android migration differs, and the checklist that keeps a migration from going wrong.

One framing point before the details. Migration is not one process but several, and which one applies depends on the platform, the operating system version, the enrollment type, and whether the device is company-owned or personal. Treating all devices the same is the most common migration mistake, so this guide clearly separates the paths, and the flowchart below shows which path any given device takes.

Why organizations migrate between MDM platforms

Migration is rarely undertaken lightly, because it touches every managed device. The reasons that justify it tend to fall into a few categories.

A better-fitting platform. The current MDM may lack cross-platform coverage, specific management capabilities, or a pricing model that meets the organization’s needs as it grows. Outgrowing a tool is the most common driver.

Mergers, acquisitions, and consolidation. When two organizations come together, they often run different MDMs, or a single organization may have accumulated several over time. Consolidating onto a single platform reduces costs and operational overhead and is a common trigger for migration.

Cost or contract change. License cost, contract terms, or a vendor change can make the current platform untenable. Migration is the mechanism for acting on that decision.

Strategy change. A move to a cloud-first model, a new security posture, or a shift in the device mix (for example, adding Android to an Apple fleet) may require a platform that fits the new direction.

The Apple change: migration without a device wipe

For years, moving an Apple device between MDM platforms through Automated Device Enrollment meant a full device wipe. The device had to be unenrolled, factory reset, then re-enrolled into the new platform, which erased user data and apps and required hands-on time per device. The only alternative left the MDM profile removable by the user, creating an unmanaged-device risk. This is the pain most existing migration advice still describes.

That changed with the iOS 26 line (iOS 26, iPadOS 26, and macOS 26), released in September 2025. Apple added a native device management migration capability, orchestrated through Apple Business (formerly Apple Business Manager) or Apple School Manager, that lets an administrator reassign an enrolled device to a new MDM without wiping it. Management control transfers to the new platform while user data and installed apps remain intact, and the user acts on a notification (a restart on iPhone or iPad, a full-screen prompt on Mac) rather than rebuilding the device.

This is the single most important fact for any current Apple migration: if the fleet meets the eligibility conditions below, migration no longer means a wipe. Because the change is recent, much of the guidance still circulating online describes the old process, so confirming eligibility is the first step, not an afterthought.

“Apple is executing their promise of a declarative future, and we’re excited to enable our customers to leverage the benefits of declarative device management like efficient configurations and real-time status reporting.”

Andrei Cupaciu, Partner, Director IT Infrastructure & Cloud.

Which migration path does a device take?

Before the step-by-step, the flowchart maps each device to its path, as the path is determined by ownership, enrollment type, and OS version, not by preference.

Who qualifies for Apple non-wipe migration?

The non-wipe path is powerful but conditional. Eligibility depends on the operating system, the enrollment type, and how the device sits in Apple Business.

Devices that qualify

Non-wipe migration applies to organization-owned devices running iOS 26, iPadOS 26, or macOS 26 or later, enrolled through Automated Device Enrollment and assigned to a management service in Apple Business or Apple School Manager. Devices added through Apple Configurator qualify once they have completed the 30-day provisional enrollment period. On macOS 26, migration also supports Macs that unenroll and re-enroll with profile-based enrollment (Apple Support, Migrate managed devices).

Devices that do not qualify (and still need the older path)

Several categories fall outside the non-wipe flow and require the traditional approach of unenrollment and manual re-enrollment, or a factory reset:

Devices below OS 26. Any device running an operating system earlier than iOS 26, iPadOS 26, or macOS 26 cannot use the native flow. One option is to first update those devices to OS 26 via the source MDM, then migrate.

BYOD and user-enrolled devices. Personal devices enrolled through user enrollment follow a separate process and do not qualify for the company-owned non-wipe migration path.

Shared iPad deployments. Migration is not available on Shared iPad; those configurations are excluded from the native flow.

Devices not in Apple Business. A device that is not registered in Apple Business or Apple School Manager typically requires a factory reset and fresh enrollment, because there is no record to reassign.

Note: Apple Business Essentials no longer exists as a separate product. Apple consolidated Business Manager, Business Essentials, and Business Connect into a single free platform, Apple Business, in 2026, so there is no longer a separate “migration to or from Apple Business Essentials” case to plan around; devices sit in Apple Business.

The Apple migration flow, step by step

For eligible devices, the migration runs through Apple Business rather than through either MDM directly. Confirm the exact console steps against Apple’s current documentation and your destination MDM before running it.

1. Prepare the destination MDM. Add and configure the new management service in Apple Business, set up Apple Push Notification service, and stage the configuration profiles, policies, and apps the migrated devices should receive. Document the current configuration from the source MDM so nothing is lost in translation.

2. Plan managed apps and licensing. A management service can preserve managed apps on iPhone and iPad during migration: if the new MDM delivers the apps before the device is marked configured, the apps and their data are kept, with no re-download and no data loss (declarative managed apps are always preserved by the device). What does not follow automatically is volume-purchase licensing. If volume-purchased apps are part of the deployment, set the migration deadline no greater than 30 days, and prepare Volume Purchasing tokens on the destination so licenses reassign cleanly.

3. Assign devices and set the deadline. In Apple Business, assign the eligible devices (individually or as a multi-device selection) to the new management service and set a deadline. Apple’s allowed range is precise: the deadline must be more than a day and less than 90 days from now (and no more than 30 days when volume-purchased apps are involved). Users then receive notifications to confirm re-enrollment, with notifications becoming more frequent as the deadline approaches.

4. The device migrates without wiping. The device moves management to the destination MDM (a restart on iPhone or iPad, a full-screen prompt on Mac). User data and locally installed apps are preserved; managed apps are preserved if the destination delivered them in time; and the new MDM applies its configuration. Policies and restrictions from the old MDM are replaced by the new MDM’s.

5. Verify and decommission the old MDM. Confirm each device reports in and is compliant in the new console, verify apps and policies applied correctly, then remove the devices and tokens from the old MDM and decommission it once the fleet is fully migrated.

On scale, Apple Business supports migrating multiple devices at once (select the devices, assign the new management service, set a single deadline), so bulk migration through the portal is a first-class action rather than a device-by-device chore. Very large fleets are still best moved in managed waves, by group or platform, so issues stay contained and the support load stays even, but that is a rollout choice, not a platform limitation.

What transfers during an Apple non-wipe migration

Knowing what moves and what doesn’t prevents common surprises, especially around apps and policies.

Migrating devices that do not qualify for the non-wipe path

A real fleet almost always contains devices outside the eligible set. Handling them is where a migration plan earns its keep, because these devices can cause data loss or downtime if treated like the eligible ones.

Update first, then migrate. For company-owned, ADE-enrolled devices running an OS below 26, the cleanest route is often to push an OS update to 26 from the source MDM, then use the native non-wipe flow once they qualify.

Unenroll and re-enroll through Setup Assistant. For ADE devices where updating is not practical, unenrolling from the source MDM allows the device to re-enroll in the new MDM based on its Apple Business assignment during Setup Assistant. This is more disruptive than the native flow and requires user interaction.

Factory reset and fresh enrollment. Devices not in Apple Business and some manually enrolled devices require a traditional wipe and fresh enrollment. Plan these deliberately, back up anything needed, and schedule them to minimize disruption.

BYOD devices follow their own process. Personal devices under user enrollment are migrated through the user-enrollment path, and users may need to re-authenticate and re-enroll the work portion of their device. Communicate this clearly, since it touches personal hardware.

Migrating an Android fleet between MDM platforms

Apple’s non-wipe flow is Apple-specific, so an Android migration follows a different model. The mechanics depend on the enrollment type, and, as with Apple, that determines how disruptive the move is.

Android Enterprise and zero-touch devices. For company-owned devices provisioned through Android Zero-Touch or a Samsung Knox enrollment program, migration generally involves reassigning the devices to the new MDM in the relevant enrollment console, then having them re-provision on the new platform. Fully managed Android devices typically require a factory reset to switch between EMMs because the management binding is set at provisioning, so plan for reset-and-reprovision on fully managed hardware.

Work profile (BYOD) devices. Personal Android devices with a work profile are migrated by removing the work profile associated with the old MDM and enrolling a new one with the destination MDM. Personal data outside the work profile is unaffected, keeping the impact contained to the work side.

OEMConfig and device-specific settings. Rugged and enterprise Android devices configured via OEMConfig require their hardware-specific settings to be recreated in the new MDM, as those configurations do not transfer between platforms. Document them from the source MDM before migrating.

The practical takeaway for Android is that there is no single equivalent to Apple’s non-wipe flow, so the migration plan must be tailored to each enrollment type: fully managed devices generally require reprovisioning, while work-profile devices are more straightforward.

MDM migration checklist

A migration succeeds or fails on planning. The one-page checklist below covers the steps that matter across platforms; download it, fill in the fields, and work it wave by wave.

Download: MDM migration checklist (PDF)

Choosing a destination MDM for the migration

Most migrations are motivated by the desire to use a single platform to manage a mixed fleet rather than multiple tools for different device types. The migration mechanics themselves are largely set by Apple, Google, and the enrollment programs, not by the MDM vendor: Apple’s non-wipe flow behaves the same way regardless of which compliant management service is the destination, and the Android paths depend on the enrollment type. What a destination platform decides is how cleanly it receives the migrated devices and how much of the groundwork it makes repeatable.

So the useful questions when evaluating a destination are concrete: does it support Apple non-wipe migration on the iOS 26 line, including delivering managed apps before the device is marked configured so app preservation works; does it handle the Android enrollment paths your fleet actually uses; and can it receive a multi-device assignment and apply your rebuilt policies without per-device setup. Bento MDM is a cross-platform destination that manages Apple, Android, and Windows from one console; for a migration specifically, confirming these three points on the actual devices, ideally in a pilot wave, is what separates a smooth cutover from a stalled one.

Frequently Asked Questions