Apple MDM migration has traditionally been a high-effort process that requires device resets, which can disrupt users and add risk to what should be a straightforward transition.

At the center of this process is Apple Business Manager (ABM), Apple’s free, centralized platform for managing organizational devices, app licenses, and device enrollment. It serves as the control layer for assigning devices to a Mobile Device Management (MDM) solution and enabling automated enrollment at scale.

Until recently, Apple MDM migration through this ecosystem came with a major limitation:

• Devices typically required a factory reset to fully transition between MDM providers
• User data and apps were removed during unenrollment
• Downtime was unavoidable
• Supervision and full management depended on re-enrollment

This made MDM migration technically possible but operationally disruptive.

Apple’s latest platform updates are beginning to change that.

With newer versions of iOS, iPadOS, and macOS, Apple has introduced more flexible MDM migration workflows that allow eligible devices to be reassigned and re-enrolled between providers without always requiring a full device wipe.

For organizations managing Apple devices at scale, this means:

• Reduced need for full factory resets
• Less disruption for end users
• More controlled, efficient transitions for IT teams

This shift is especially valuable for organizations dealing with fragmented tools, overlapping licenses, or increasingly complex MDM environments, particularly those evaluating Apple MDM migration as part of a broader device management strategy.

Who Can Use The New Apple Migration Process?

Not all Apple devices are eligible for Apple MDM migration without a device wipe. Eligibility depends on how devices are enrolled, assigned, and managed within Apple Business Manager (ABM).

Eligible Devices

For ABM MDM migration, devices are best suited when they meet the following criteria:

• Running iOS 26, iPadOS 26, or macOS 26 (or later)
• Organization-owned devices enrolled via Automated Device Enrollment (ADE)
• Devices assigned to an MDM server within ABM
• macOS 26+ devices enrolled via profile-based enrollment
• Devices added via Apple Configurator that have completed the 30-day provisional period

Not Eligible

Some device types and configurations are not supported under the new migration process:

• Shared iPad
• Devices managed through Apple Business Essentials (ABE)
• Devices not enrolled via ADE or not assigned in ABM

Understanding these Apple MDM migration requirements helps set realistic expectations. In most environments, this step quickly identifies which devices qualify for streamlined migration, and which may require a more traditional transition path.

The 7-Step ABM “MIGRATE” Framework

Once device eligibility is confirmed, the focus shifts to planning and coordination. A clear framework helps maintain consistency, reduce avoidable issues, and guide devices through each stage of migration.

The following seven-step framework outlines a practical Apple MDM migration guide for planning and executing migrations through Apple Business Manager.

1. Map Out Existing Devices and Configurations

Before making any changes, establish a clear understanding of your current device environment. Mapping devices, policies, and configurations establishes a reliable baseline for Apple MDM migration. This typically includes:

• Configuration profiles (passcode, Wi-Fi, VPN)
• Encryption settings and certificates
• Managed applications (including VPP apps and deployment settings)
• Device groups, tags, or organizational structures

A detailed inventory helps ensure critical settings and policies are accounted for while confirming the new MDM solution can support existing security and operational requirements. It also creates an opportunity to identify outdated or unnecessary configurations, rather than carrying everything over by default.

This step creates a stronger operational foundation for the remaining stages of the migration process.

2. Integrate the New MDM with Apple Business Manager

Once your current environment is mapped, the next step is to configure the new MDM environment for deployment. This involves aligning the platform with business and operational requirements while establishing its connection to Apple Business Manager (ABM).

As part of broader MDM cloud migration steps, this stage focuses on configuring the destination environment before active migration begins.

This includes:

• Setting up Apple Push Notification service (APNs) to enable secure communication between devices and the MDM
• Connecting Automated Device Enrollment (ADE) to the new MDM within ABM
• Creating enrollment profiles to define how devices are provisioned and managed
• Configuring Apple Volume Purchase Program (VPP) to manage app licenses and assignments

These steps ensure the new MDM environment is deployment-ready before devices are reassigned.

When creating enrollment profiles, applying default tags where possible can also improve device organization from the start. This can reduce manual administrative work later by supporting more consistent policy assignments during enrollment.

3. Generate Equivalent Profiles, Apps, and Policies in the New MDM

MDM configurations don’t transfer automatically during Apple MDM migration. To maintain operational continuity, equivalent configurations must be rebuilt within the new MDM environment. This typically includes:

• Enrollment profiles

  Define how devices are set up during enrollment, including supervision, user experience, and management controls

• Configuration profiles

  Core device settings such as Wi-Fi, passcode policies, restrictions, and update behaviors

• Applications and their configurations

  App Store, VPP, and custom apps, along with any managed settings or deployment rules

• Certificates and files

  Security certificates (e.g., PEM, DER, PKCS#12) and supporting files required for authentication and access

• Business policies and tags

  Group configurations, apps, and settings into scalable policies, then assign them using tags or device groups for consistent deployment

Rebuilding these elements ensures that devices receive the same level of management, security, and access once they transition.

This stage also provides an opportunity to reassess existing policies and configurations. Instead of duplicating everything, teams can streamline policies, remove legacy configurations, and standardize how settings are applied across devices.

As best practice, organize configurations, apps, and certificates into unified policy sets and apply them via tags. This allows devices to receive all required settings automatically upon enrollment.

It’s also important to account for existing applications on devices, particularly on macOS. Apps deployed through your previous MDM may not be automatically removed, so planning cleanup helps avoid conflicts in the new environment.

4. Reassign Devices to the New MDM in Apple Business Manager

Once the new MDM environment is fully configured, devices must be reassigned within Apple Business Manager (ABM) to the new MDM server.

This involves selecting target devices in ABM and updating their assigned device management service. Once updated, devices are prepared for enrollment in the new MDM.

At this stage, you can also determine how enrollment is triggered for end users:

• Set an enrollment deadline

  Triggers a persistent “Enrollment Required” notification on the device, prompting users to complete the process within a defined timeframe

• No deadline

  No automatic notification is sent, and users must manually initiate enrollment from their device settings

Depending on how deadlines are configured, users will typically receive prompts to complete enrollment after device reassignment.

The right approach depends on how much control is needed over timing, enforcement, and user experience. Setting a deadline helps enforce adoption at scale, while a manual approach may be more suitable for smaller or phased migrations.

5. Assign Enrollment Profiles and Tags

Once devices have been reassigned, enrollment profiles and tags must be applied so devices are provisioned correctly and mapped to the appropriate post-enrollment configurations.

This step includes:

• Assigning enrollment profiles

  Defines how the device is provisioned, including supervision, setup experience, and management controls

• Applying tags to devices

  Tags map devices to specific policies that determine which configurations, apps, and settings are applied after enrollment

In solutions like LogMeIn Resolve, this process can be managed through the synced device list after Apple Business Manager integration. If an enrollment profile is set to default, it will be applied automatically. Otherwise, profiles can be assigned manually, along with the appropriate tags for each device or group.

This stage ensures devices are provisioned appropriately and receive role-specific configurations based on intended use cases, such as employee laptops, shared devices, or specialized deployments.

6. Track Enrollment Progress

As devices begin enrolling into the new MDM, active monitoring helps confirm migration is proceeding as expected while quickly identifying issues that require attention. For large-scale iOS MDM migration efforts, this stage is particularly important for identifying friction before it affects broader deployment.

At this stage, key priorities include:

• Enrollment status to confirm successful completion
• Failed or pending enrollments that may require user action or troubleshooting
• Timing and completion rates to measure rollout performance

In LogMeIn Resolve, enrollment activity can be tracked through Enrollment logs and Apple DEP views, where status indicators provide visibility into device-level activity. Real-time enrollment visibility allows IT teams to address issues early, reduce delays, and maintain rollout momentum—especially during large or phased migrations.

7. Ensure the Migration Has Been Successful

Once users complete enrollment, devices should automatically receive assigned configurations, applications, and certificates based on applied policies and tags.

At this point, devices should become visible in your MDM software, and deployment activity can be tracked to confirm that configurations are being applied as expected. Before expanding to additional devices, validate that deployment, access, and policy enforcement are functioning correctly.

Key validation checks include:

• Devices are visible and fully enrolled in the new MDM
• Configuration profiles have been applied successfully
• Business-critical applications (such as email or VPN) are installed and functioning as expected
• Security and compliance policies are enforced
• No critical errors or failed deployments remain unresolved
• End users can continue working without disruption

In LogMeIn Resolve, deployment status can be tracked through policy views to monitor how configurations, apps, and certificates are applied across devices. If needed, individual configurations, applications, or certificates can still be deployed manually to specific devices without restarting the migration process.

This stage serves as a quality assurance checkpoint. Early validation helps prevent isolated issues from scaling into broader deployment problems as migration expands.

Reducing Complexity in MDM Migration

Apple’s evolving migration workflows make it easier for organizations to rethink their current MDM strategy—whether that means consolidating tools, reducing complexity, or transitioning to a platform better aligned with long-term operational needs.

To minimize risk, consider a phased rollout. Starting with a smaller group of devices helps validate configurations, identify issues early, and build confidence before broader deployment.

For organizations using migration as an opportunity to simplify device management, LogMeIn Resolve combines endpoint management, remote support, and automation within a unified platform designed to reduce complexity beyond migration.

Explore how LogMeIn Resolve can support Apple MDM migration while strengthening ongoing endpoint management.

Learn More

FAQs

Which devices and OS versions support non-wipe migration?

Non-wipe Apple MDM migration is supported for organization-owned devices running iOS 26, iPadOS 26, or macOS 26 (and later) that are enrolled in Apple Business Manager via Automated Device Enrollment (ADE). Apple Configurator-enrolled devices can also qualify after completing the 30-day provisional period.

Will apps be preserved during migration?

In many supported migrations—particularly on iPhone and iPad—apps and managed app data can be preserved, but this depends on how the new MDM is configured. Apple notes that managed app data is preserved, and the destination MDM must properly reassign licenses and redeploy required apps to maintain continuity. Apps not reassigned by the new MDM may eventually be removed.

How long does the migration process take?

Migration timelines vary based on device count, configuration complexity, app licensing, and whether deadlines are enforced. Apple allows administrators to set migration deadlines from more than 1 day to less than 90 days, enabling phased rollouts in larger environments.

Do I need Apple Business Manager to use non-wipe migration?

Yes. Apple’s non-wipe migration workflow depends on Apple Business because device reassignment between MDM providers happens through Apple’s device management service framework. Without ABM/ASM enrollment and supported ownership status, traditional wipe-and-reenroll methods may still be required.

What happens if a device fails non-wipe migration?

If a device doesn’t meet Apple’s eligibility requirements or encounters issues during migration, it may fail to present migration options, require troubleshooting, or need a more traditional reset-and-reenroll path. Apple’s activity logs in ABM can help identify failures, and migrations can often be paused, adjusted, or canceled before completion, depending on the stage.

Will migrating Apple devices to a new MDM disrupt our workflow?

For eligible devices, Apple’s newer migration process is designed to significantly reduce disruption compared to traditional wipe-based migrations. However, disruption still depends on planning quality, policy recreation, app reassignment, and phased rollout strategy. Organizations that carefully align configurations, licenses, and deployment timing are more likely to minimize downtime and preserve user productivity.