Migration can stall or become partially manual. Devices with removable profiles can often be migrated with automated policies, but non-removable profiles usually require unenrollment from the current MDM first. For ADE enrolled devices, the serial number association must be switched through Apple Business Manager or Apple School Manager, so the transition becomes more dependent on the source enrollment path.
Why an MDM Migration Depends on Profile Removability
The practical difference is whether the current MDM can release the device cleanly. If enrollment profiles are removable, migration can often be automated through policy and re-enrolment. If they are not removable, the device usually has to be unenrolled first, which adds manual steps and can interrupt fleet transition planning. For ADE devices, the Apple Business Manager or Apple School Manager association becomes part of the migration path.
That means the migration question is really about control of the existing management relationship, not just the destination MDM. A clean handoff is straightforward only when the source profile allows it and the device can be re-associated without policy deadlock.
When teams skip this check, they often discover late that some devices cannot accept the new path until the old one is removed. At that point, the migration is no longer a single workflow; it becomes a mixed estate problem with some devices moving automatically and others requiring intervention.
What Changes for ADE, User Enrolment, and Non-Removable Profiles
Apple device enrolment methods determine how much of the transition can be scripted. ADE enrolled devices depend on the serial number being assigned to the correct MDM in Apple Business Manager or Apple School Manager, so the association itself has to be moved before the new management state can take effect. Other enrolment types may be easier to retire if the profile was designed to be removed at the user or device level.
A useful mental model is to separate three questions: can the profile be removed, can the device be unenrolled without data loss or operational disruption, and can the serial number or ownership association be shifted to the new MDM. If any one of those answers is no, the migration plan needs a fallback process rather than assuming the automated route will work everywhere.
That is especially important in mixed Apple fleets, where supervised devices, user-enrolled devices, and ADE devices do not behave the same way. Migration planning should therefore be based on actual enrolment state, not on device model or policy intent.
Why Migration Failures Become Operationally Expensive
Unverified removability turns a rollout into a troubleshooting exercise. The most common failure mode is partial migration, where some devices enrol into the new platform while others remain anchored to the old one because the original profile blocks transfer. That creates inconsistent policy enforcement, uneven app deployment, and extra help desk load.
It also increases the risk of losing visibility during the handoff. If a device is unenrolled before the replacement path is ready, it may sit outside compliant management for a period of time. If it is not unenrolled when required, the new MDM may never gain full control, leaving administrators with duplicated work and uncertain ownership.
For teams operating at scale, the cost is usually not the single troublesome device. It is the long tail of exceptions, each of which needs manual review, coordination with Apple business tooling, and verification that the device has landed in the expected state.
Risk and Threat Considerations
Migration mistakes create a short window where devices can be mismanaged, incompletely enrolled, or left dependent on the wrong control plane. That is an operational risk first, but it can become a security risk if policy enforcement, command delivery, or device compliance is lost during the transition.
Failure mechanism: A non-removable profile blocks automated migration, forcing unenrolment and reassociation steps that are often discovered too late in the rollout plan.
Impact: The estate can end up split between management systems, with gaps in compliance enforcement, delayed remediation, and a higher chance of manual error during the handoff.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | MDM migration depends on controlled device configuration and enrolment state. |
| Recommendation — Inventory enrolment states and enforce a controlled migration path for each device class. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | You need accurate device and enrolment inventory to plan migration by profile type. |
| AC-2 — Account Management | Migration changes who can manage devices and when access should be transferred or revoked. | |
| Recommendation — Maintain a current inventory of devices, enrolment profiles, and management associations. Coordinate device management access changes with the enrolment transition and retire old access promptly. | ||
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Migration planning must reflect the organisation's device ownership and management model. |
| Recommendation — Define which Apple devices are in scope for each management path before migration starts. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Enrolment profiles and MDM associations are configuration items that must be controlled during change. |
| Recommendation — Control device enrolment changes as managed configuration updates with approval and rollback planning. | ||
Practitioner Guidance
What to verify: Confirm the enrolment path for every device class before scheduling migration, especially whether the existing profile can be removed without a manual wipe or source-MDM action. If ADE is involved, validate the Apple Business Manager or Apple School Manager serial assignment path as part of the readiness check.
Decision rule: If the current profile is not removable, treat the device as a separate migration track and plan for unenrolment, reassociation, and post-move validation. Do not mix those devices into the same automated wave as removable-profile devices.
Practitioner takeaway: The key question is not “can we switch MDMs?”, but “can we release each device cleanly enough to switch without losing control of it?”
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org