Migrations of the past
Historically many Apple admins have done everything in their power to avoid Mobile Device Management migrations. It’s been a painful process not only for the admins but for the people using the devices. For the admins; months of planning and testing, and engineering a specific solution for your migration from MDM A to MDM B which gets broken with every new macOS release.
For the end-user it meant weeks/months of comms from your Workplace Tech / Internal IT team to keep track of. Then either a fully wiped device or a lengthy disruption as the work takes place. And when you’re done with that you have new software and app stores to learn, perhaps a new login window with new credentials to get stuck at, and teething issues as the admins work everything out.
All this work just to save maybe 10-20% off your MDM bill and get access to a few new nice to have features. You could outsource the project of course but there goes your 20% savings in an instant. There was no real workable way of making an MDM migration worth the time and effort. Until now…
So what’s changed?
In the last few years Apple has added many improvements to its MDM framework. This has made it incredibly simple for MDM vendors to include multiple ways for admins to both remove and add devices to their platforms. But the majority of Apple admins still don’t want to move to a new MDM even if it’s the right choice for their business. Instead of looking at why that is let’s look at the reality instead and see if I can change some minds…
The Process
There’s a lot of MDMs out there so we’ll look at it in generic terms first, and then I’ll give some specific examples.
Unmanaging devices
Most modern MDMs will now include an ‘Unmanage Device’ option in the UI, a terminal command, or even via API. Whilst the mechanism behind how this works per MDM differs, the outcome is the same. Your previously managed device will have its enrollment and any other deployed profiles removed, and in most cases any of the MDM-specific software (think Self Service stores, custom login windows, helper apps etc) will be uninstalled from the device. Often this is a completely silent process meaning the user of the device will be unaware that it’s happening.
Enrolling into your new MDM
There are many options here too. A lot of MDMs will have a package that will do most of the work for you which you can deploy in a number of ways. You can look at more manual options like Apple Configurator, or Apple Device Enrollment (ADE) if you want to start afresh. For anyone who knows me I like to automate everything so my ideal looks something like this…
Scenarios
Example 1 – User Initiated – Automated – Jamf to Kandji via Self Service
This is definitely one of the best migration flows I’ve seen. Kandji have built a package that you can deploy to your device at any time pre-deployment that waits until the device’s status is unmanaged and then enrols the device. So what does that look like in practice?
- Deploy Kandji Enrollment package to all devices
- Create Self Service item with ‘Migrate’ button which unmanages the device via
jamf removeFramework - User clicks ‘Migrate’ in Self Service and device is unenrolled
- Already deployed Kandji Enrollment app queries device every 5 minutes and sees that it is now unmanaged
- Device enrols into Kandji
All user initiated, seamless, and could disrupt the end-user for as little as 10 minutes. The only downside is that it may take up to 5 minutes for the enrolment in to Kandji to be started. You also won’t be able to take this approach if the device has a non-removable Enrolment Profile. You’d instead install the Kandji Enrollment package, communicate with your user(s) when the migration will take place, and use ‘Remove MDM Profile‘ Jamf Pro instead. As an aside, you could also do the opposite of this from Kandji to Jamf with equal ease.
Ease of migration score: User – 5/5. Admin – 5/5. Total 10/10
If you’re interested in procuring a new MDM such as Kandji or Jamf get in touch with my friends at Remitech (and tell them I sent you!)
Example 2 – User Initiated – Manual – Kandji to JumpCloud via Enrollment Profile
There’s plenty of other ways to get this done too. Let’s say you have non-removable Enrolment Profiles because you’ve previously enrolled devices via ADE. In this world you could do the following:
- Roll out the JumpCloud Enrollment Profile to each user’s desktop via a package in Kandji
- Communicate with users when the migration needs to occur
- Remove the device from Kandji by Deleting the Device Record
- Communicate with users how to re-enrol using the Enrolment Profile on their desktop
Not as smooth as the first example but still very doable.
Ease of migration score: User – 2/5. Admin – 4/5. Total 6/10
Example 3 – Admin or User Initiated – Automatic – Any to Any via full wipe
The simplest and cleanest way for admins is via a full wipe of the machine. It’s obviously not ideal for the user but in a world where 90%+ of our workload is cloud-based this can be less painful than you’d think.
- Assign devices to your new MDM in Apple Business Manager / Apple Device Enrolment
- Communicate migration plan to users
- Either create wipe command item in a self service store, or send one at a set time to devices
- Device will wipe and automatically re-enroll into new MDM
Ease of migration score: User – 2/5. Admin – 4/5. Total – 6/10
Summary
This is by no means an exhaustive list. There’s a huge number of MDMs, many of which have unique ways to enroll into and unenroll from. My point is that overall it’s considerably easier and quicker than most people seem to think these days. 1 click and 10-15 minutes to go from one MDM to another is now very possible and something that should be utilised far more.
I’ll be recording some videos of the process soon so you can see it for yourself!
So what’s stopping you?
It’s never been easier to migrate between MDMs, and there have never been more viable Apple MDM platforms to choose from. Competition breeds innovation and we’re finally seeing that come to pass after over a decade of slow progress in the Apple MDM market.
More competition has lead to better overall solutions, pricing, and migration options. Whilst the project planning and documentation side of things is unlikely to ever change, the engineering time and cost of time to staff has reduced dramatically, and the new MDM features like login windows are far better integrated into macOS. You can now move more freely between MDMs as your business grows and your requirements change. And you might even save some money along the way.
Let me know in the comments if you’ve done an MDM migration recently or are thinking about it. I’d love to know about people’s successes, and about what’s holding others back.
Check out Pipedream for incredible SaaS orchestration and API automation tools. Low and no-code workflows mean you can go from idea to prod in minutes. Get Slack notifications about your IT stack, automate email alerts, push data between Salesforce and any other API-enabled app, and anything else you can think of.