How to Execute a Successful MDM Migration on Mac

Switching from one MDM solution to another on a Mac fleet is no trivial undertaking. There are many moving parts to coordinate, and failure to think it all through could render your fleet unprotected at best and inoperable at worst. As usual with any serious IT project, prior planning and preparation will prevent any number of outcomes that you just don’t want.

Here’s how an ideal MDM migration on Mac should work.

Step-by-Step: The Migration Process 

The deal-making is over, the paperwork is signed, and you’re a fully fledged customer of your new MDM provider. Now, it’s on you to make the changeover happen. 

There are two phases to any good migration: First, there’s the preparation phase (which includes planning and testing), and then there’s the actual migration itself. Don't even think about the second until you've worked through the first.

Planning the Migration

Before you do anything with the new solution itself, you need to be very clear about what you want it to do. You should define your desired end-state for devices before you begin to consider the details of how you’ll get them there.

What are your management goals? What do you want the new MDM solution to do? Some of the functionality you’re looking for may replicate what you’re getting now from your existing solution. Some of it may be net-new. But it pays to spell out exactly what functionality you’re expecting the new solution to deliver. That list will guide your testing plan.

Next, talk through the migration process with your IT team, to get everyone aligned on what you’re all going to be doing for the next month or so. (Yes, “a month or so” is a good ballpark estimate of how long it’ll take; it might be less, it might be more.) Walk them through the steps outlined below and get their feedback on any concerns or blockers they might have.

Finally, start sketching out the migration plan in whatever tool you prefer. Give every item on it a deadline and an assignee.

Apple has more excellent suggestions about migration planning. It also spells out the different migration scenarios for different types of devices.

Preparing for the Migration

Once you’re clear on what you’re trying to accomplish and what needs to happen when, it’s time to get your hands on some software. 

First, you need to add the new MDM solution to your instance of Apple Business Manager. As explained by Apple support, that means first downloading a certificate from your new solution. (Here's how to do it in Kandji.) Certificate in hand, you sign in to Apple Business (using an ID with the role of Administrator or Device Enrollment Manager), click your name, select Preferences, click Add, assign an MDM server, and then upload the certificate file. After you click Save you can then download a server token from Apple Business Manager and upload it to your new MDM.

Next, you need to prepare your instance of the new MDM solution for testing. That means defining the settings, apps, scripts, and profiles that you want to distribute. Of course, these configurations are rough drafts of the ones you’ll be deploying more widely to your whole organization, so take some time here to think them through and make them realistic. 

Once again, Apple itself has some excellent suggestions for preparing your new MDM solution for the migration.

Testing the Migration

Your next step is to do a mini-migration on a limited set of test devices. That means first defining who’s in that test group; you may want to define subgroups within that team to receive different configurations. It’s important to include devices that have been enrolled by whatever methods your organization supports: automatically (through Automated Device Enrollment) and manually.

You’ll go through the migration steps outlined below just for this one group—assigning their devices in Apple Business Manager to Kandji, removing them from your old MDM solution, enrolling them in Kandji—and then evaluating the results. 

Your evaluation of this test run should combine objective measures: Did every device enroll? Were the configurations applied correctly? You also want—as well as more subjective evaluations from the test group. Actively solicit tester feedback about the migration process and see what you can correct or tweak. 

You can also use this testing period to develop the end-user documentation that you’ll distribute as part of the full migration. Any MDM migration requires some user input, so you’ll need to provide succinct instructions about what they’ll need to do, as well as answer as many likely questions as possible. This testing period is also a good time to collect the collateral—such as screenshots—that will make your documentation clear.

If that first test run uncovers any serious glitches, you may need to spend some time ironing them out and then running another test (or two). Factor that into your planning.

Implementing the Full Migration

Assuming you’ve ironed out the glitches and have your documentation lined up, it’s game time: the full migration of all the Apple devices in your organization. 

That starts with setting the dates the migration will happen and then communicating that to users and leadership. It’s always better to err on the side of over-communicating. A week or so prior to that date, you’ll want to send out communications to end-users about what they’ll be expected to do.

This is also time to finalize the configurations you’ll be deploying and the groups they’ll be going to in the new solution.

The migration itself kicks off with pointing their Apple devices to the new MDM solution in Apple Business Manager. Apple explains that process in detail here, but the gist is: 

• Sign into Apple Business Manager;
• Go to Devices in the sidebar and select the device(s) you’re migrating;
• Select the number of devices at the top of the list, then next to Edit MDM Server, click Edit;
• Select Assign to the following MDM, click the menu, then select the MDM server you recently created.

Next, you need to unenroll the devices you're migrating. At the very minimum, this requires you to remove the old MDM profile from the devices you're moving. Many MDM solutions, when you delete a device, will send an MDM command to remove the MDM profile from it; check with your current MDM provider for its specific steps. Depending on the device and how it was enrolled, there might be other ways to remove profiles, but using the existing MDM is the only universal way to do so.

For Mac computers, the old MDM solution’s macOS agent might still be installed on the Mac even after the old MDM profile is removed, but getting the Mac enrolled in the new MDM solution is a higher priority, and you can take care of the lingering agent later.

Now it’s time to enroll those now-unmanaged devices in the new solution. 

For devices that can be enrolled via Automated Device Enrollment, you can run the command sudo profiles renew -type enrollment. (This can be done via a script distributed by your old MDM solution.) 

For the others (the ones that were not enrolled via Apple Business Manager), someone will have to enroll them manually. This could mean having the user navigate to an enrollment portal or, for iOS and iPadOS devices, having an admin use Apple Configurator. 

That done, the new solution should begin deploying the configurations you’ve set.

Note that the period after you’ve unenrolled the Mac from the old MDM solution but haven’t yet enrolled it in the new one is particularly perilous: The Mac is both unmanaged and unsecured. So don't dawdle on this.

DIY vs Solution-based Migration

As you can see, doing a migration ‘by hand’ entails a lot of work for you and your users. 

It can also be a real challenge to do it at scale. In order to be successful, each migrating user has to be logged in with an admin account and they need to be comfortable using Terminal. (On that last point, note that the alert that macOS displays after the sudo profiles command won’t appear if the user has Do Not Disturb turned on. It’ll also be invisible if they’re recording or mirroring their screen, and their Notifications setting Allow notifications when mirroring or sharing the display is turned off—which is the default.)

There are some solutions (including Kandji) that will help you automate much—but not all—of the migration process.

So, for example, the Kandji Migration Agent is a collection of scripts and a launch daemon, distributed as a package, that you deploy to migrating Mac computers using your existing MDM solution. (It relies on scripts that can’t run on iOS or iPadOS devices.) 

In this case, the process is:

• You move the Mac computers you’re migrating from your existing MDM to Kandji in Apple Business Manager.
• In your old solution, you create a custom policy or app to distribute the Kandji Migration Agent to them.
• Next time those computers check in with the old solution, they’ll receive the Migration Agent.
• The Agent will run and wait for the MDM profile from the old solution to be removed. 
• Then, the Migration Agent will prompt the user to enroll in Kandji, either via Automated Device Enrollment or manually.  

That obviously cuts out a lot of the hassle that manual approaches require. And because it’s more automated, it can eliminate some of the fumble-fingered errors that can trip up any manual process. If you have the option, a solution-based migration is way easier than the DIY approach. 

Tips for MDM Migration for iOS and iPadOS

While some of the above will apply equally to iOS and iPadOS devices as to Mac computers, there are some differences.

First and foremost is the scriptability of the process on Mac. That’s a huge plus to the solution-based approach. However, the unique platform security and privacy features that Apple has built into iOS and iPadOS devices are also a big factor.

We spelled out some of these migration idiosyncrasies in our post, "Choosing the Right Way to Change Device Management on iOS and iPadOS."

The bottom line is that, while migrating to a new MDM isn’t trivial, it is doable—particularly if you can automate as much of the process as possible. But no matter what your mix of devices and enrollment types, it can never be automated entirely. It’s always going to take at least some collaboration between IT and end users to make the switch.

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.