VSA 10 MDM: Migrating from another MDM solution

This non-destructive MDM migration process was introduced by Apple for devices running iOS 26, iPadOS 26, and macOS 26. This feature allows administrators to move devices enrolled in Apple Business Manager (ABM) or Apple School Manager (ASM) from one MDM server to another without requiring a full device wipe and re-enrollment. This eliminates the significant downtime and user disruption historically associated with MDM migrations.

Prerequisites

Before initiation a migration with this method, ensure the following prerequisites are met: 

How to perform the migration

Phase 1: Preparation

1. Audit your current MDM: Document all existing configurations in the source MDM, including Wi-Fi profiles, VPN settings, certificates, compliance policies, security baselines (for example, FileVault), and deployed applications. This documentation will serve as the blueprint for the new environment.
2. Configure the destination MDM: Replicate the documented configurations in the new destination MDM solution.
   • Create all necessary MDM profiles and policies in VSA 10. Refer to VSA 10 MDM: Apple MDM profiles.
   • Add all necessary application assignments using MDM Applications profile. Refer to Apple MDM Applications profile.
3. Conduct pilot testing: Enroll a small group of test devices directly into the new MDM to validate that all configurations, policies, and app deployments work as expected.
4. Develop a communication plan: Prepare clear communications for end-users explaining the upcoming change, the deadline, and the specific actions they will need to take. Tailor the messaging for iOS and macOS users, as their experiences will differ significantly.

Phase 2: Initiating the Migration

1. Log in to ABM/ASM: Sign in with an account that has Administrator or Device Enrollment Manager permissions.
2. Select devices to migrate: Navigate to the Devices section and select the device or group of devices to be migrated.
3. Reassign device management: Use the Assign Device Management function to change the assigned MDM server from the current one to the new destination server.
4. Set the migration deadline: A new option, Add deadline, will appear. Set a specific date and time for the migration to be enforced. The deadline must be between one and 90 days in the future.

   IMPORTANT  If no deadline is set, the migration will only occur if the device is erased or a manual re-enrollment command is run.

   

Phase 3: Finishing the migration on user devices

Once you've initiated the migration by following the steps in Phase 2, the devices will begin notifying their users.

• User notifications: The user receives notifications about the required management update. The frequency of these alerts increases as the deadline approaches (for example, daily notifications, then hourly).

  

  

• User-initiated migration: At any point before the deadline, the user can confirm they want to start the process on the notification or select Not Now to postpone it.

  

  

• Forced migration at deadline: If the user takes no action, the migration is enforced automatically when the deadline is reached.

  

  Differences in user experience by platform

  The user experience then the migration deadline expires will differ for users based on which OS is installed on their device. These differences are outlined below.

  Prerequisite	User experience when past migration deadline	Details
  iOS and iPadOS	The device will automatically restart and re-enroll the device in the new MDM service in the background.	Device Restart: If the device is offline after restarting, a Wi-Fi picker appears so the user can connect to a network to complete enrollment.
  macOS	A non-dismissible, full-screen prompt appears, blocking all other use of the computer until the user clicks through the enrollment steps.	User Interaction: The user must actively click Enroll to complete the process. If a managed local user exists, they must be logged in to authorize the migration. No restart is needed.

Phase 4: Post-migration admin verification

1. Verify enrollment: Use the reporting tools in the new MDM to confirm that all targeted devices have successfully checked in and are now managed.

2. Audit device state: Run inventory reports to ensure devices have received the correct configuration profiles and that all necessary managed apps have been re-adopted and installed.

Known limitations and potential risks

• Wi-Fi connectivity gap: The migration process removes the old MDM's configuration profiles (including Wi-Fi) before installing the new ones. If a device relies solely on a pushed profile for internet access, it will be knocked offline and will require the user to manually connect to a network to complete the re-enrollment.

• App and data preservation: To preserve managed apps and their data during a transfer, the new Mobile Device Management (MDM) solution must reissue installation commands for those apps before the device configuration is finalized. If the new MDM fails to do this in time, the device will delete the old managed apps and their data. Because Kaseya MDM does not currently support this process (the await_device_configuration flow), all managed apps will be reinstalled, and their user-entered data will be lost.

• Apps and Books (VPP) token: You must transfer the location token from the old MDM to the new one. While there is a grace period of about 30 days, failure to migrate the token will eventually cause app licenses to be revoked.

• Activation Lock: Any Activation Lock enabled by the source MDM is automatically removed during migration. The destination MDM must be configured to re-enable it to ensure the device remains protected.