Lessons from 1,000 Migrations: How to Switch Device-Management Solutions

If you manage Apple devices, sooner or later you’ll consider the question: Should we switch from our current device-management solution to another? That question immediately leads to a host of others, and pretty soon the whole idea of migrating may begin to seem overwhelming. 

But it doesn’t have to be. With the right preparation and planning, switching from one device management solution to another is eminently doable, with big payoffs in efficiency and new capabilities at the end. 

What are the best practices that lead to a successful switch? That was the focus of a discussion hosted by Kandji Senior Product Engineer Steven Vogt with two guests who have each taken part in many, many migrations: Erik Van Dijk, IT growth and technical support manager at Vidyard; and Jim Quilty, manager of the Solutions Architecture team at Kandji. They talked about what they’ve learned from their years in the field and what they’d tell an admin facing a migration for the first time. This is an abridged version of that conversation; here’s the full video presentation.

The Big Picture

Steven Vogt (SV): At a high level, what does the typical Mac migration process look like?

Erik Van Dijk (EVD): Each time we've done it, it has involved a planning stage and a testing stage. Then we have the documentation and a test rollout—I always like to test with a small group of highly technical users, to make sure we haven't missed anything. Then there’s the rollout itself, the main event. Afterward, there's troubleshooting.

SV: What should somebody expect for a timeframe?

EVD: For an organization of our size [300-plus employees], the whole process usually takes a couple of months, with the actual deployment taking a couple of weeks. If you have to keep asking folks to complete the migration, that deployment can take a bit longer.

SV: Is there a right time to migrate?

Jim Quilty (JQ): I think the right time is when you're ready. As long as you plan for it and you know what's coming, as long as you've provided users with the documentation and information they need, it can be a smooth process whenever you're ready to pull the trigger.

SV: In terms of where an organization is with their current device-management solution, do they wait until the last day of the contract? Should they have some overlap there?

JQ: I always recommend having about a month of overlap, just so if you need to, you can take a little bit of extra time to make sure things are going correctly, to make sure you have time to get devices out of the old MDM and into the new one successfully.

Planning, Planning, Planning

SV: What is happening behind the scenes in a migration? What makes it complicated?

JQ: A lot of things have to happen in the right order. There can't be more than one MDM on an Apple device at a time, so you've got to coordinate getting the old MDM off and getting the new MDM on. You have to make sure that there's as little time as possible when the device is out of management. You also have to make sure you know which applications are going to be installed—or potentially uninstalled—during the migration. Are there new settings that are going to be applied? Are there old pieces that have to be removed? A lot of planning goes into it.

The biggest challenge is looking at all of the different moving parts. Such as, are your users administrators, so they can approve the MDM installation? Is the profile that's currently there removable by the user, or by anyone, or does it have to be done via MDM? Are devices always online or is it a situation where you have a lot of laptops, where the device might be closed for a certain amount of time? Is it going to receive those commands? Am I going to have to physically touch all of these devices to get them migrated?

EVD: My philosophy is: Test everything and then test everything again. There are so many variables, and you have to be sure that you've accounted for all of them and that you've tested for all of them. I had my team test on different workstations, different Mac computers, older operating systems, newer operating systems, ABM-enrolled devices, non-ABM. What happens when we set up a device that already has FileVault enabled? What happens if we do the same with one that isn't enabled? How do Auto Apps work? How do these different things behave together? All told we probably tested it 15 or 20-plus times, just wiping workstations and trying it again—"Let's try this, let's try that." 

I also had a checklist that we went through, asking questions like, "Is our documentation easy to understand? Are our video guides clear, do they make sense? Where do users report problems, if there's an issue?” Tickets can get a little overwhelming if you have 100 people asking you quick, easy questions. So we used a Slack channel for the rollout, to make sure that if someone had a quick question for us, we could just answer it right then and there.

Think of the User

SV: What’s the migration experience like for users?

EVD: Moving over to a new MDM, for the end user at least, is generally a pretty quick process, but it's not without issues. A user might experience an issue with an application, or maybe there's a setting that's changed because of the policies we’ve built. As IT admins, we try our best to be available, to help folks through that. 

SV: Did you do the migration for users? Or did they do it with your instructions? What did that interaction look like?

EVD: We realized that we wanted to let folks install Kandji at their own pace, at a time that was convenient for them, especially in a remote-first environment, where everybody's on their own schedule, and we've got folks all over the world. So after a quick test rollout, to make sure our documentation was there, we announced it at a meeting: "We're going to install Kandji. It starts on this date, and we hope that you can have it installed by this date." We sent out video guides for different use cases: If you had a computer that maybe wasn't on an MDM and wanted to enroll, or if you had an ABM device or a non-ABM device. And we had full documentation to accompany those videos.

SV: So communication to the user, letting them know exactly what was going to happen, was key. And thinking through all the different technical things that they might face and accounting for those.

EVD: Absolutely.

SV: Jim, in all the different migrations that you’ve done, is this pretty typical, having it be user-driven? 

JQ: It's all over the spectrum, honestly. There were definitely some times when I did the whole thing myself: Sat in a room for three days, gathering up everyone's computers. That was obviously a lot easier when everyone was in a single office, where you just had to go through and hit every computer. But, as Erik said, if you plan it out and you know what's coming down the line, it makes it easy to give users the information to say, "Here's what's expected of you,” and let them take care of that, and then let the MDM solutions do what they need to do. You have to make it easy for the user. You don't want them to take an hour or even a half an hour out of their day to do the migration. You want it to be a couple of minutes.

EVD: One thing we did was make sure that everybody was aware of what the new MDM was, what it could do for us, how it was going to help us. We had a lot of people excited about it; everyone was on board before the process. But if you get to the point where you're following up with folks, and they're not getting back to you, that's when you have to bring in, "We need this for security and audit purposes." Then usually they’ll go, "Oh, I'm sorry," and get switched over right away.

SV: Did you do anything to entice your users? Did they get anything as part of enrolling?

EVD: We tried to showcase how versatile Self Service could be. We pulled in the various teams and said, "If new folks are joining tomorrow, what tools would they need?" And we started adding custom apps for them. That was really helpful. The other one was, "Hey, if you ever need to upgrade your computer, we're going to be able to automate a lot of that for you, and it's going to streamline things for you." People were excited about that.

About Kandji

Kandji’s Migration Agent can help make switching MDM solutions 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.