Skip to content
Pricing
Virtual Tour Get Started
Get Started
migrating mdm on ios and ipados using return to service
Blog Recent News Migrating ...

Migrating MDM on iOS and iPadOS Using Return to Service

Alexandre Morin & Brian Van Peski Alexandre Morin & Brian Van Peski
10 min read

When you’re migrating from one MDM solution to another, you have to move the devices you’re managing with you. They need to be enrolled in that new solution so you can manage them.

On Mac, such migrations can be relatively straightforward. That’s because they can run custom tooling (such as Kandji’s Migration Agent) to assist with the move from one MDM to another. 

Corporate-owned mobile devices are often another story because iOS and iPadOS can’t run the tooling that can facilitate such migrations. Thankfully, Apple’s Return to Service functionality can help with migrations on iPhone and iPad—if the conditions are right. Here’s how it breaks down.

MDM Migration with Return to Service

Apple’s Return to Service feature—introduced in 2023 with iOS/iPadOS 17—was great news for IT admins. It gave them a new workflow for resetting iPhone and iPad devices remotely, erasing their data, and then getting them ready for use again—connected to Wi-Fi and enrolled in MDM.

The most obvious use case for Return to Service is for devices that must be reset frequently—think of an iPad configured as a retail kiosk, dedicated Zoom station, or shared field-service terminal. However, Return to Service is also a great way to migrate such devices from one MDM solution to another.

That’s because, as part of the Return to Service workflow, the device goes through Automated Device Enrollment (ADE). After erasure and reboot, the device will interrogate Apple's activation servers to find out which MDM to enroll into through ADE. You can assign devices to a new MDM in Apple Business Manager first, then issue an Erase command in your old MDM solution with the Return to Service option enabled. When the devices reboot, they enroll in the new MDM. Voilà: MDM migration at scale. 

Return to Service Requirements

While Return to Service offers a golden path to switching corporate-owned iPhone and iPad devices that have been through ADE from one MDM solution to another, it does have some requirements:

  • Obviously, your existing MDM solution must support the Return to Service command.
  • It must be OK to wipe the device.
  • The devices you’re migrating must be running iOS/iPadOS 17 or later.
  • They must also be in Apple Business Manager.
  • After being wiped, they must have access to an internet connection (either via a Wi-Fi payload that you send to the device along with Return to Service or an active cellular data plan).
  • Activation Lock must be turned off.
  • Authentication should not be required during enrollment.

Return to Service Blockers

For devices that don’t meet those requirements, you’ll have to either find some workarounds within that “golden path” or follow an alternative path altogether. The migration can still happen, but it takes more work.

Wiping the Device

The Return to Service migration workflow is based entirely on erasing the device. For that reason, it’s great for migrating devices that are shared or used in some public-facing way. But what about corporate-owned devices that are used by single users and have personal data on them? In those cases, wiping may be a harder path to follow. 

One remedy for this blocker is to make sure that the user’s private data—typically photos and messages—are synced via iCloud or another cloud service. Assuming your IT policies permit such syncing, that data will sync back to the device after Return to Service once the users sign into their accounts after the migration. 

However, it’s critical that the device is not restored from an iCloud backup after it’s been wiped. That’s because the device would then revert to the state it was in at the time of backup—including the old MDM profile. And if it wasn’t enrolled in your MDM solution at the time of that backup, it won’t enroll itself into the new one.

Migrating single-user devices can also be much easier if the old MDM offers something like Kandji's Self Service feature.

MDM Support for Return to Service

Your current MDM might not support Return to Service. If that’s the case, you can’t very well send an Erase command with the Return to Service option. However, it may offer a way to send custom MDM commands. If so, here’s a sample data structure for an Erase command that includes the Return to Service key and a Wi-Fi profile:

<dict>
    <key>RequestType</key>
    <string>EraseDevice</string>
    <key>ReturnToService</key>
    <dict>
        <key>Enabled</key>
        <true/>
        <key>WiFiProfileData</key>
        <data>base64 encoded Wi-Fi profile data</data>
     </dict>
</dict>

Devices Running Older OSes

If you have devices you want to migrate that are running OSes prior to iOS/iPadOS 17, you won't be able to leverage Return to Service: You’ll have to follow one of the alternative paths outlined below. While you’re doing that, you can take the opportunity to upgrade those devices to the latest OS. 

Devices Not in Apple Business Manager

If they aren’t in Apple Business Manager now, they really should be. There’s no downside and plenty of upside. You can use Apple Configurator to do that manually or work with your Apple reseller to submit your previously purchased devices to your instance.

No Known Internet Connectivity

As part of the Return to Service workflow, you can specify a Wi-Fi network to which the devices should connect after they’ve been erased. That connection is then used to contact Apple Business Manager and go through ADE.

But if a device isn’t connecting to a known Wi-Fi network (think of single-user devices connecting at home) and isn’t connecting some other way (cellular or tethered), you’ll have to follow one of the alternative flows below.

Alternatives to Return to Service

If the Return to Service workflow and those workarounds aren’t viable, you’ve got three other choices for migrating iOS and iPadOS devices. (For a more detailed discussion of these alternatives, see "Choosing the Right Way to Change Device Management on iOS and iPadOS.")

Wipe and Erase without Return to Service

This is the way things were done before Return to Service: You’d send the Erase command, the device would be wiped, and the device would enroll in your new MDM solution via ADE. The advantage is that the device will be supervised. The only problems are:

  • It isn’t hands-off: It requires a user or admin to interact with the device to complete enrollment. 
  • As with Return to Service, it erases any personal data that might have been on the device; you can offer the same iCloud solution we suggested above.

Replace and Restore the Device

For single-user devices, the golden path is to offer those users new devices, which will then be enrolled in your new MDM. Such upgrades could be part of your regularly scheduled refresh cycle for the entire fleet or bespoke upgrades just for specific users. This workflow also allows those users to restore their data from iCloud backups.

The appeal: They'll have to go through the device transition anyway, but they get a fresh new device in the bargain, while you get that device enrolled into your new MDM. Best of all, that MDM is locked: Users can’t remove the MDM profile manually.

Manual Enrollment

Finally, you can remove the MDM profile (either remotely or manually), then manually install the new MDM profile. This could mean asking the user to manually download and install a profile for the new MDM solution. 

But there’s a caveat here: With this process, you go from an unremovable MDM profile (because the device went through ADE) to one that can be removed (even though the device is still supervised); if the user were to remove it, the entire device would be wiped.

However, the advantage is that supervision is retained, so the new MDM will inherit supervised-only capabilities. Again, the MDM profile will still be removable (that isn’t the case with devices that have gone through ADE), but if the user attempts to do so, they will be warned that their device will be erased if they proceed, which is an extra level of friction that plays in your favor.

Return to Service is still the golden path for many, many iOS and iPadOS devices. And for the exceptions to that path, you do have workarounds and alternatives.

About Kandji

Kandji is the Apple device management and security platform that empowers secure and productive global work. With Kandji, Apple devices transform themselves into enterprise-ready endpoints, with all the right apps, settings, and security systems in place. Through advanced automation and thoughtful experiences, we’re bringing much-needed harmony to the way IT, InfoSec, and Apple device users work today and tomorrow.