Apple MDM Migration: An IT Admin's Guide

Switching MDM providers with hundreds or thousands of Apple devices in production is one of the most operationally complex projects an IT team takes on. Apple's OS 26 native migration capability changes the calculus significantly, but a clean migration still requires careful planning, configuration documentation, and a solid post-migration validation workflow.

This guide covers everything from pre-migration inventory to post-migration compliance verification, with specific attention to the scenarios that trip up most teams: app data preservation, FileVault recovery key synchronization, and managing devices that don't qualify for the new OS 26 migration path.

What Has Changed with Apple OS 26 MDM Migration

Prior to OS 26, migrating supervised Apple devices between MDM solutions almost always meant a factory reset, re-enrollment, and re-installation of every managed app. For a fleet of 500 MacBooks, that's a multi-week project that touches every user.

Apple's OS 26 introduces a native migration flow managed through Apple Business (formerly Apple Business Manager/ASM). The mechanism works like this:

1. An admin reassigns devices from one MDM server to another directly within Apple Business.

2. The source MDM pushes a migration notification to enrolled devices.

3. Users receive a prompt with a configurable deadline to complete the transition.

4. The device unenrolls from the source MDM and enrolls with the destination MDM automatically, without wiping the device.

For Apple device management teams running entirely through Apple Business with ADE-enrolled devices, this is transformative. The key constraint: both source and destination MDMs must support the OS 26 migration API, and devices must be running OS 26 or later.

Devices and scenarios the OS 26 migration does not cover:

• Devices running iOS/iPadOS/macOS below OS 26 (these still require unenrollment and manual re-enrollment or a wipe)
• Shared iPad deployments
• Devices enrolled in Apple Business Essentials
• Devices not registered in Apple Business or Apple School Manager
• User-enrolled (BYOD) devices, which follow a separate process

If your fleet includes a meaningful percentage of devices below OS 26, plan for a parallel migration track. Don't let the headline capability obscure the reality that a mixed-OS environment needs a mixed-method approach. If you manage BYOD devices alongside corporate-owned hardware, those will need their own migration planning entirely.

Pre-Migration Planning: What to Document Before You Touch Anything

The most common cause of a painful MDM migration isn't the migration itself. It's poor documentation of what the source MDM is actually doing. Before you initiate anything in Apple Business or your destination MDM, export and document the following:

Configuration Profiles

• Export every configuration profile from the source MDM, including payload type, scope, and any device-specific exceptions.
• Flag profiles that manage security-sensitive settings: FileVault, screen lock, firewall, certificate trust, and content filtering.
• Note profiles that are delivered by MDM vs. profiles that were manually installed. Manually installed profiles don't migrate automatically and may not be re-deliverable without user action.

App Inventory and VPP/Apps and Books Assignment

• Pull a complete list of managed apps, including App Store apps assigned through Apps and Books and any custom or enterprise apps sideloaded via MDM.
• Document which apps are assigned to devices vs. users.
• Verify your Apps and Books token is associated with your Apple Business account, not hard-coded to the source MDM vendor. You'll need to revoke and re-invite the token in the destination MDM.

Enrollment and Supervision State

For each device, document:

• Enrollment type (ADE/user enrollment/manual)
• Supervision status
• OS version
• Serial number and Apple Business registration status

This is also a good point to reconcile your MDM device inventory against your hardware inventory management records. Devices that appear in one system but not the other are a problem to resolve before migration, not after.

Security Baselines

Map your current configuration profiles to the security controls they enforce. If your organization adheres to CIS Benchmarks for macOS or NIST SP 800-179 recommendations, document which profiles correspond to which control. You'll need this mapping to validate your security posture in the destination MDM post-migration.

Setting Up the Destination MDM Before Migration Day

The destination MDM should be fully configured and tested before a single production device moves. Running a migration into an unprepared MDM is how you create a window where devices are enrolled but ungoverned.

Required Configuration in the Destination MDM

Apple Push Notification Service (APNs) certificate: APNs certificates are vendor-specific. Your source MDM's APNs certificate cannot be transferred. Generate a new certificate through the Apple Push Certificates Portal using your organization's Apple ID, then upload it to the destination MDM. The certificate must be renewed annually, so document the expiry date and the Apple ID used.

ADE/Automated Device Enrollment integration: In Apple Business, assign the destination MDM as the server for the devices you're migrating. This is the step that sets up the OS 26 migration flow. Devices assigned to the new MDM server will receive the migration prompt once your source MDM initiates it.

PreStage enrollment configuration: In the destination MDM, configure your PreStage (or equivalent enrollment profile) before devices arrive. This includes:

• Setup Assistant pane configuration
• Initial profile assignments
• MDM profile installation settings

Apps and Books token: Revoke the token from the source MDM and re-invite it to the destination MDM. Note that revoking the token from the source MDM will immediately remove the ability to push new VPP app assignments from that system, so coordinate this timing with your migration window.

Configuration profiles: Recreate all required configuration profiles in the destination MDM. Don't simply recreate the old MDM's profile architecture 1:1. Use the migration as an opportunity to rationalize your policy structure. Legacy MDM environments often accumulate years of overlapping, conflicting, or redundant profiles. A migration is a natural forcing function to clean this up.

Executing the Migration: The OS 26 Flow Step by Step

With the destination MDM configured and devices assigned in Apple Business, here's the operational sequence:

1. Initiate migration from the source MDM. The source MDM sends an MDM command to enrolled devices signaling the migration. The exact mechanism varies by vendor, but the result is the same: a notification appears on the device.

2. Users receive a migration prompt. Apple's OS 26 migration includes a configurable enrollment deadline. You can set a grace period (commonly 24-72 hours for managed corporate devices) after which the device enforces migration automatically. Inform users before the prompt appears. An unexplained system dialog asking to change device management will generate support tickets.

3. Device unenrolls from source MDM. The device removes the source MDM's management profile and any configuration profiles delivered by that MDM.

4. Device enrolls with destination MDM. The device contacts Apple's servers, retrieves the assigned enrollment profile for the destination MDM, and completes enrollment.

5. Destination MDM delivers configuration profiles and apps. The device receives its assigned profiles and begins installing managed apps. Devices do not wipe. User data, locally installed apps, and settings unrelated to MDM-delivered configuration are preserved.

App preservation note: Managed apps assigned through Apps and Books are preserved during OS 26 migration if the destination MDM is configured to claim management of those apps. If the destination MDM doesn't claim the apps, they may transition from managed to unmanaged status, which has implications for managed app data and selective wipe behavior. Verify your destination MDM's app management claim configuration before migrating.

FileVault and Security Configuration Continuity

FileVault recovery keys are stored by the source MDM. When a Mac migrates to the destination MDM, the source MDM loses its management connection and the recovery key stored there becomes orphaned.

To maintain FileVault recovery key continuity:

• After migration, the destination MDM should issue a FileVault recovery key rotation command. This generates a new recovery key and escrowed it with the destination MDM.
• Until that rotation occurs, the previous key stored in the source MDM is still valid for recovery, but it's no longer being managed.
• Prioritize Macs with FileVault enabled in your migration validation checklist. Confirm the new recovery key is escrowed in the destination MDM for every device.

For other security configurations, validate the following in the destination MDM after migration:

• Screen lock and password policy enforcement
• Firewall state
• System Integrity Protection (SIP) status on Intel Macs
• Gatekeeper configuration
• Certificate trust profiles

If your organization follows a compliance framework, this is the right time to run a compliance check against each device. Understanding device management and security as an integrated discipline, rather than separate workstreams, makes post-migration validation more systematic.

Migration Strategies for Devices Below OS 26

For devices running iOS/iPadOS or macOS below OS 26, you have three paths:

Option 1: Update to OS 26, then migrate. If the device supports OS 26, push the update from the source MDM before initiating migration. This is the simplest path for eligible hardware.

Option 2: Unenroll from source MDM, re-enroll in destination MDM. For ADE-enrolled devices, you can unenroll from the source MDM and the device will re-enroll with the destination MDM based on its Apple Business assignment. This doesn't require a wipe but does require the user to complete Setup Assistant steps if you haven't configured them to skip.

Option 3: Factory reset and re-enroll. For devices not in Apple Business or devices with complex local configurations that need to be cleared, a wipe and re-enrollment is the cleanest option. This is the option that requires the most coordination with end users.

Document the OS version distribution across your fleet early in planning. If 30% of your Macs are on macOS Sequoia and ineligible for OS 26, that's a significant operational track to plan for separately.

Rollback Planning and Contingency Procedures

Most migration guides skip this section. Don't.

Before initiating any production migration, define your rollback threshold: at what point do you pause or reverse the migration? Common triggers include:

• More than X% of migrated devices failing to receive configuration profiles within Y hours
• Managed app loss exceeding a defined threshold
• Reports of FileVault recovery key gaps above a set percentage
• Security tool deployment (EDR, endpoint protection) failing to install on migrated devices

Rollback for the OS 26 migration flow means reassigning devices back to the source MDM server in Apple Business and triggering a reverse migration. This is technically possible, but it requires the source MDM to still be active and licensed. Do not cancel your source MDM contract until you have confirmed a successful migration and completed post-migration validation for the entire fleet.

For large fleets, a phased rollout is standard practice: migrate a pilot group of 10-20 devices from a non-critical team, validate thoroughly, then proceed in batches. Each batch should have a validation checkpoint before the next batch begins.

Post-Migration Validation and Compliance Verification

Post-migration validation is where many teams underinvest. A device that appears enrolled in the destination MDM isn't necessarily compliant. Check each of these for your migrated devices:

• Configuration profiles delivered and applied (query device for installed profiles)
• Managed apps installed and in managed state
• FileVault recovery key escrowed in destination MDM
• Security tools (EDR agent, endpoint protection) installed and reporting
• Device compliant with all required policies
• Certificate profiles installed and valid

Build this into a formal validation checklist and run it for every migration batch before marking that batch complete. If your destination MDM has a compliance dashboard or reporting view, use it. Devices that show as enrolled but not compliant need immediate follow-up.

How Iru Approaches Apple MDM Migration

Migration is often the moment teams reconsider their entire policy architecture, not just their MDM vendor. Iru is built around a concept called Assignment Maps, which lets you define a structured policy hierarchy that maps device and user attributes to configuration sets. When migrating from a legacy MDM, this is particularly useful because it forces a deliberate policy design rather than a 1:1 recreation of whatever accumulated in the old system over years.

For app delivery specifically, Iru's auto app deployment is configured to deliver managed apps before the DeviceConfigured command completes. This means devices that go through the OS 26 migration flow receive their apps as part of the initial enrollment sequence rather than as a background process that users might notice as a gap.

Iru connects directly to Apple Business for ADE integration and APNs management, which keeps the migration flow straightforward. You assign devices to the Iru MDM server in Apple Business, configure your enrollment profiles and Assignment Maps, and the migration proceeds through Apple's standard flow.

For security posture validation post-migration, Iru's compliance library includes pre-built items that map to CIS Benchmarks for macOS and common NIST controls. After migration, you can run a compliance report across your fleet and immediately see which devices need remediation, rather than building that mapping from scratch.

For teams migrating from complex legacy platforms, Iru's interface is designed around the way Apple's management frameworks actually work, which reduces the ramp-up time for admins who spent years working around another tool's abstractions.

Making Your Apple MDM Migration Count

An Apple MDM migration is disruptive by definition. The teams that come out of it in the best position treat it as an intentional redesign of their management architecture, not just a vendor swap. That means rationalizing your profile structure, validating your security baselines against a real framework, and confirming that every device is genuinely compliant before you declare the project done.

OS 26's native migration capability removes the factory reset requirement for qualifying devices, which eliminates the biggest user-facing disruption. But the planning work, pre-migration documentation, and post-migration validation remain essential regardless of the migration path.

If your team is evaluating a move to Iru or planning a migration from another Apple MDM provider, request a demo to see how Assignment Maps and Iru's Apple-native architecture can simplify both the migration and the ongoing management that follows it.