MDM Migration Without a Wipe: What macOS 26 Unlocks

If device wipes have been your reason for not consolidating your Apple fleet onto a single MDM platform, that reason just disappeared. 

With macOS 26 Tahoe and iOS/iPadOS 26, Apple introduced MDM migration without a wipe — no factory resets, no data loss, no physical device handling required. The migration is orchestrated through Apple Business Manager, and users receive a notification they can act on in minutes. For IT teams managing fragmented Apple fleets across multiple MDM solutions, this is the consolidation window you have been waiting for. 

There is a second, parallel deadline that makes this more urgent: all legacy MDM software update commands — including MDM commands, restrictions, and the com.apple.SoftwareUpdate payload and MDM update queries are fully deprecated and will stop working with the 2026 OS release. Legacy update workflows will no longer function reliably once devices move to the 2026 OS generation, creating a management gap that grows with each device update. 

This post covers what the migration entails, the eligibility requirements, and how to use this window to consolidate your Apple endpoints into a unified management platform. 

What Apple’s Native MDM Migration Actually Does 

Previously, moving iOS devices between MDM solutions via Automated Device Enrollment required a full device wipe. The only alternative was manual re-enrollment, which left the MDM profile removable by the end user, creating an unmanaged device risk. For macOS, re-enrollment without wiping was technically possible but operationally cumbersome. 

The new migration capability completely changes this. The workflow runs through Apple Business Manager or Apple School Manager and allows IT administrators to assign enrolled devices to a new MDM server — with no factory reset, no data loss, and no Activation Lock removal required. 

From the user’s perspective, they receive a system notification, click Start Enrollment, and the migration completes in the background. Administrators can set a migration deadline in ABM. As the deadline approaches, the notification frequency increases. At the deadline, migration becomes mandatory. 

What Transfers During Migration 

• Device management control transfers to the new MDM 

• User data and applications remain intact 

• Activation Lock status is preserved 

• Corporate apps managed through VPP transfer — provided separate VPP tokens are configured for both MDMs 

• Existing MDM configurations are replaced: policies, restrictions, and compliance profiles from the old MDM are overwritten by the new MDM. Configurations must be replicated in the target MDM and tested before migration begins — devices will operate under new policies from the moment migration completes 

Eligibility Requirements — What Must Be in Place 

Migration is not available for every Apple device. The following requirements must all be met before a device is eligible: 

• Device OS: macOS 26 Tahoe, iOS 26, or iPadOS 26 or later must be installed 

• Enrollment type: Devices must be corporate-owned and enrolled via Automated Device Enrollment (ADE). Devices enrolled via Apple Configurator must complete a 30-day provisional ownership period first 

• ABM/ASM membership: Both the source and target MDM must be registered as servers in the same Apple Business Manager or Apple School Manager account 

• MDM API support: Both MDM solutions must support Apple’s Migration APIs and Declarative Device Management (DDM) 

• Tokens: Updated MDM certificates, server tokens, and separate VPP tokens must be configured for both MDMs 

BYOD and personally owned devices do not follow this migration path. Migration applies only to corporate-owned, ADE-enrolled devices. 

The DDM Deadline: Why This Cannot Wait 

The MDM migration capability arrives at the same time Apple forces a fundamental change in its management architecture. Legacy MDM software update commands — the mechanisms most organizations use today to push OS updates to Apple devices — are fully removed with the 2026 OS release. Organizations still relying on these commands face a concrete deadline: migrate to Declarative Device Management or lose the ability to manage software updates on Apple endpoints. 

Declarative Device Management represents a fundamental architectural shift. Rather than MDM servers polling devices and issuing commands reactively, DDM enables devices to apply configurations based on declarative policies, report status asynchronously, and operate consistently even when offline. For IT teams, this means configuring software update policies through the Settings Catalog rather than traditional device configuration profiles. 

The practical implication is straightforward: if your current MDM solution does not fully support DDM, you need a new MDM. And if you need a new MDM, the native migration capability means you can make that move without a fleet-wide wipe. 

The Intel Mac Sunset: A Natural Consolidation Moment 

The timing matters for another reason: macOS 26 Tahoe is the final release supporting Intel-based Macs. For organizations already planning a hardware refresh cycle, the new migration capability creates a natural opportunity to consolidate both hardware and management architecture simultaneously. New Apple Silicon Macs enroll directly into the target MDM via ADE from day one — no legacy migration required. 

How to Use This Window to Consolidate Your Apple Fleet 

The migration window is open now for organizations running eligible devices. Here is a structured approach: 

• Audit your current Apple device inventory. Identify which devices are ADE-enrolled, which OS version they run, and which MDM they are currently managed by. Devices that do not meet eligibility requirements require a separate remediation plan. 

• Verify your target MDM supports Apple Migration APIs and DDM. This is a hard requirement. If the target MDM does not support both, migration will not complete successfully. 

• Register both MDM solutions in Apple Business Manager. Both source and target MDMs must appear as configured servers in the same ABM account before migration can be initiated. 

• Configure separate VPP tokens for both MDMs. This ensures managed App Store apps transfer correctly to the new platform without gaps in license management. 

• Replicate configurations in the target MDM before initiating migration. Policies, restrictions, compliance profiles, and app assignments should be in place and tested on a pilot device before fleet-wide migration begins. 

• Set a migration deadline in ABM and communicate it to users. Users receive notifications and can complete migration themselves. The deadline ensures stragglers are managed without manual intervention. 

• Migrate to DDM software update policies immediately. Legacy update commands will stop working. Configure DDM update policies in the Settings Catalog as a parallel workstream — do not wait for legacy commands to fail. 

For organizations using this window to consolidate onto a single platform, the choice of destination MDM matters as much as the migration itself. The platform needs to support Apple Migration APIs and DDM, enroll devices via ADE, and manage the rest of your endpoint fleet — iOS, iPadOS, Android, Windows, and macOS — without adding another fragmented console. 

How CapaOne Mobile Manager Fits This Migration 

CapaOne Endpoint Management Platform includes Mobile Manager, which unifies enrollment, configuration, compliance, and application delivery across iOS, iPadOS, Android, Windows, and macOS in a consolidated endpoint governance platform. 

For organizations consolidating fragmented Apple fleets, CapaOne Mobile Manager is the target platform. It supports ADE-based enrollment via Apple Business Manager, making it a valid destination for Apple’s native MDM migration workflow. When devices migrate via ABM, they enroll directly into Mobile Manager — no physical intervention required. 

For organizations managing mixed fleets — iOS, iPadOS, Android, Windows, and macOS — Mobile Manager eliminates the separate MDM consoles that currently produce fragmented compliance visibility. Enrollment, configuration, compliance evidence, application delivery, and essential remote actions all run on a single platform, alongside Application Manager, Privilege Manager, and Security Monitor for full endpoint governance coverage. 

For organizations where mobile device compliance is part of a broader NIS2 evidence requirement, Mobile Manager provides the documented enrollment, configuration, and policy enforcement data that NIS2 endpoint compliance requires — across every managed device in the fleet, in a unified operational layer. 

CapaOne is not the orchestrator of the Apple MDM migration — that is Apple Business Manager’s role. CapaOne is the destination: a unified endpoint governance platform ready to receive your migrated Apple devices and manage them alongside the rest of your endpoint fleet. Book a demo of CapaOne Endpoint Management Platform to see how Mobile Manager supports Apple fleet consolidation, DDM-ready device management, and unified endpoint governance across mixed device environments.