How to Change Device Management on iOS and iPadOS

Switching your organization from one mobile device management solution to another is not a trivial undertaking. It can be a substantial project requiring careful planning and detailed execution. But if your current MDM solution isn’t cutting it anymore—if you’ve outgrown its capabilities, or if its provider isn’t deploying new features quickly enough for you—it’s also an imperative and eminently doable one.

Because of some unique platform security and privacy features (which I’ll explain in a bit), migrating MDM vendors on iOS and iPadOS devices is more involved than it is with macOS. Tools such as Kandji’s Migration Agent can help with migrations on macOS but won’t work on Apple’s mobile platforms. (There are tools that advertise the ability to help migrate iPhone and iPad to a new MDM, but those tools cannot bypass Apple’s platform restrictions and so are unlikely to be as helpful as you might wish.)

But there are still some steps you can take that will make migrating your iPhone and iPad fleet to a new device management platform as smooth as possible. Those steps will vary depending on who owns the devices and whether you want to preserve the data stored locally on them.

Here are some ways of thinking through such a migration and some best practices that should help make the process easier for everyone.

BYOD vs. Organization-Owned Devices

The first question you need to consider is: Who owns the iPhone and iPad devices in your fleet, your organization or the user? The answer will largely determine what you as an administrator can control on those devices and how the MDM migration will be executed.

In the case of user-owned devices (aka BYOD), each user is in charge of enrolling (and, because the MDM profile cannot be locked to these personal devices, staying enrolled) in your MDM solution. That means they will play a key role in the migration because each user will have to unenroll from your current MDM and enroll in whatever MDM platform you’re switching to. Fortunately, you have the benefit of familiarity here: Since those same users once had to enroll their devices in your old MDM solution, they will likely be comfortable—or at least familiar—with the steps involved in enrolling in a new one.

For BYO devices, the migration process will look something like this:

The user navigates to Settings > VPN & Device Management and removes the existing MDM enrollment.
All corporate apps–along with all of their associated data–that were installed by the old MDM solution are automatically removed from the device.
The user visits an enrollment web page or downloads an app to enroll in the new MDM.
Finally, the user navigates to the new MDM solution’s app portal or self-service app to reinstall corporate apps.

With BYO devices especially, clear, concise communications are extremely important. You want the users to see this migration as something that will benefit them. Those communications can stress the advantages of making the switch, such as the continued access it will provide to secured work resources, apps, and networking. (These are likely the same incentives you used to get them to enroll their devices in the first place.)

For devices that are owned by your organization, your best path is to leverage Automated Device Enrollment (ADE) through Apple Business Manager. (If the devices you own are not in Apple Business Manager for some reason, you or your reseller can add them.) ADE streamlined the first enrollment of your corporate devices, by directing them automatically to your MDM solution while in Setup Assistant and enabling supervision (the enhanced management state enabled through Apple Business Manager) over the air. It can also help you migrate corporate devices to your new MDM.

For organization-owned devices, that migration will proceed like this:

You assign devices to the new MDM in Apple Business Manager.
You then erase the devices (through MDM, on the device, or via USB) so they have to go through Setup Assistant again (a requirement of ADE).
When users go through Setup Assistant, their devices will automatically be enrolled in your new solution.

You might be thinking that erasing devices will be a tough pill for users to swallow—but that is true only some of the time, for a specific subset of devices.

Shared vs. 1:1 Devices

In some respects, migrating organization-owned devices can actually be more work than BYOD, depending on whether they are assigned to a single user (1:1) or shared among users.

That’s because you will likely want to preserve the non-removable MDM feature, to ensure that all devices remain managed. (The non-removable MDM feature is what prevents a user from opening Settings > VPN & Device Management and unenrolling their device.) This feature is available only to devices that enroll to your new MDM through Setup Assistant, which can only happen right out of the box or after the device has been erased. That means erasing all existing devices and all of their contents so that ADE can force them into management and keep them managed.

That’s not usually too big a challenge for hardware that’s shared among users, because those devices don’t typically have local data that you need to preserve. They can easily be migrated as part of regular re-provisioning or a mass software update operation, in which case you can use Apple Configurator 2 over a USB connection to take devices through ADE once again (without the need to touch each device).

But you will need to spend more time planning for the migration of user-assigned devices. These are typically iPhone devices that users take everywhere, personalize, and store personal content on—and so will not want to have them erased.

One response to such resistance is to have the user back up or sync their personal data to a cloud service. If you do that, the migration will have little impact on their device’s content, look, or feel.

But there’s a big caveat here: If the user backs up with iCloud Backup and then restores that backup on the same device while setting it up after it was erased, the old MDM relationship will be restored. This is by design, to ensure that the device remains in a state the user expects and so they are not redirected to a new management solution without their knowledge. It also means you may not be able to let users use iCloud Backup for your MDM migration project unless they’re also getting a different device in the process.

If, on the contrary, they restore their backup to a different device, enrollment to your new MDM will proceed as expected in Setup Assistant; the user will also have a device with the content and configuration they expect.

This is an opportunity for you: If there is a device refresh at hand, the user will be even more incentivized to follow your guidance. Planning MDM migration to be part of a wholesale or gradual fleet refresh will reduce user friction and make your life that much easier.

Timing Your MDM Migration

Since user experience is key to a successful MDM migration, it’s smart to find a time when making that switch will give the users some incentive to do their part.

So, for example, you might execute the migration when you have a new resource coming online that will only be available through the new MDM. Fleet replacements are also ideal triggers for an MDM migration. You may want to see when Apple is releasing new hardware—or, if you’re using cellular devices, when your carrier may have good fleet replacement offers available.

If the user is getting a new device, they can then leverage iCloud Backup or the Setup Assistant’s device-to-device transfer feature for the best user experience. This will also ensure that everything looks exactly the same on their new device; enrollment to the new MDM will just happen as part of their switch to the new hardware.

It can really help to recruit a test group—typically, the IT team plus power users from other departments—to migrate their devices first. Once you’re comfortable that enrollments are going well for them, you can expand the migration to the wider population.

Once you’re ready to go wider, it can help to set a firm cut-off date, after which all new enrollments, as well as any repeat enrollments—device replacements, upgrades, I-lost-it-on-the-trains— are to the new MDM; you don’t want to ask users to enroll twice in a short period of time. Enrollments are always happening, so a hard cutover is recommended.

Again, good, regular communications are key. Take the time to be sure all your communications about the migration and its benefits to users are engaging, properly branded, and from a source that users know and trust. As with any change—from an old app, system, process, or office space to something new—make it clear why this will be worthwhile for the user. You want them to feel they have a stake in its success.

More Migration Tips

If you do not require non-removable MDM, you can coordinate with the users of corporate devices, use the old MDM to remotely unenroll them (assuming it supports that), then have those users manually enroll in the new MDM. This way, you retain supervision, but not the locked MDM profile.
You may have some variation in how you migrate devices, depending on the user. Maybe your C-suite gets a more personalized experience, in which IT staff personally manage the process to be sure everything goes well. This could include USB-based backups and restores, instead of using cloud-based services.
Plan to keep both MDMs operating side-by-side throughout and after your migration—for 30 days or so—to ensure you have access to anything you might have forgotten to move over
Be sure you collect unique device keys—including Activation Lock bypass codes and escrowed keys—from your existing MDM solution. You will need those to maintain access to your devices.
Temporarily remove restrictions that could block the ability to use the on-device Erase All Content and Settings option or USB access for backups.
Move over all MDM settings that you want to keep to the new MDM solution, including the supervision identity, if possible. Supervision identities are stored in protected PKCS12 (.p12) files.
Take care with your Apple Business Manager tokens: Their contents have to be migrated, too. You can set up unique ADE and App and Books tokens for your new MDM solution and, as your migration progresses, use Apple Business Manager to transfer devices and unassigned licenses from the old solution to the new one.
Since these changes will be reflected only when devices are unenrolled and re-enrolled, none of this has any impact on users and their devices until the migration is done. It will not disrupt their productivity.

Of course, every situation is unique, and yours may warrant some different approaches. Still, the advice above should help you navigate your migration effectively.

The bottom line is that the structural limits that make iOS and iPadOS so secure and protective of user privacy can also make migrating from one MDM to another trickier than it is on Mac. If you involve the users in an appropriate and compelling way, they should be your best allies in working through those problems.

About Kandji

If you're switching MDM solutions on Mac, Kandji’s Migration Agent can help make the move quick and clean. It’s customized to meet your particular needs and notifies users when it’s time for them to do their part, and Kandji engineers work with you until every computer is enrolled. With powerful features like zero-touch deployment, one-click compliance, and offline remediation, Kandji has everything you need to enroll, configure, and secure your Apple devices.