As the number of platforms used in business has proliferated beyond the PC, mobile device management (or enterprise mobility management or unified endpoint management, if you prefer) has become a core competency for IT departments. Apple actually kick-started the MDM market back 2010 when it announced that iOS 4 would offer enterprise management via the Apple MDM framework, and focused that framework on third-party vendors.

Today, business gets done on everything from iPhones to Chromebooks, and each device or platform — not to mention the OS or app versions they run — has its own quirks and requirements. So do the MDM tools to secure and manage those devices and platforms.

Apple represents a majority of mobile devices in business, and macOS is the second biggest platform in business computing. Virtually every company today has Apple products used within it, meaning Apple MDM is a crucial component of today’s IT stack. iOS devices, Macs, and even Apple TVs are all managed by same Apple MDM framework. Some MDM vendors build their products specifically around this framework and Apple. Others incorporate support for Android, chromeOS, and Windows. With a truly broad set of options, picking the best one isn’t always easy.

Like many parts of IT infrastructure, MDM needs to integrate with a variety of core disciplines, particularly identity management, user support and self-service portals, network management, and security. Investing in the right platform should make the lives of IT administrators, end users, and anyone in between more friction-free, while choosing the wrong MDM can create headaches, bottlenecks, and support tickets.

So how do you make this selection? More importantly, if you’re already using an MDM platform (Apple-focused or not) and it isn’t the best fit, how do you invest in, and transition, to one of the other options out there? What questions do you need to ask yourself and potential vendors?

If you’re reading this, it’s probably a safe assumption that you have at least some iPhones, iPads, or Macs to manage. But what exactly does that mean? One advantage to Apple products tends to be that they’re long lived, which means they deliver a lot of value. It also means you may have a number of older Macs and iOS devices. Some may be running old OS versions, and some might not be able to run the current versions or be on the chopping block for support in the next year.

Most companies also support a fair number of non-Apple devices, ranging from Android phones and tablets to Chromebooks and Windows PCs.

So you need an accurate count of which devices you’re actively managing or going to manage. At the least, you’ll need basic information like the number of devices, their platform and OS version, whether they’re company-owned or BYOD, and user(s) assigned to them. Ideally you’ll have much more information than just the basics, particularly if you’re already using an MDM, network monitoring tool, or even just a well-maintained device inventory.

The second part of this question is more policy than fact-based. Do all the devices in your organization need to be managed by MDM? Because Apple MDM can be applied to any device including Windows PCs, you could manage everything through MDM, using it as a single solution for all management functions.

There are some reasons not to do this. Windows devices in particular may be better managed through group policies or Azure Active Directory enrollment. This lessens the count of devices (and therefore the cost of MDM) and allows you to maintain legacy management groups and configurations.

You may also be in a situation where you want to use different tools for different segments of your inventory or user groups. You may split devices across multiple management solutions while ramping up a deployment or for a longer period.

You may find that one MDM option doesn’t fully meet your needs. This will most often be an issue when it comes to Apple-focused MDMs that have limited capabilities on Android or other non-Apple systems. It may be worth the overhead to use an Apple-specific product for Macs, iPhones, and iPads if such a product provides more support and capabilities or better workflows for Apple products than a more general solution designed for multiple platforms.

In this case, you should ask the question: do I want I want a single tool that’s like a Swiss army knife, or do I want a best-of-breed solution that does one thing — manage Apple products and integrate well with Apple services — really well, even if means I’ll need to invest in more tools and management planning?

MDM has become an infrastructure-level component of the modern IT stack. Transitioning from one vendor to another isn’t something to take lightly, particularly for devices that can only be managed by a single MDM. You’ll need to consider not just the capabilities of potential replacements, but also what the transition from one product to another is going to look like.

This is something that’s going vary widely depending on the two products in question, your specific mix of devices, and other details about how your IT stack is configured. Any potential vendor should be willing to invest the time and effort to plot out what a migration path will look like, acknowledge potential speed bumps, and explain how they will help you handle them. They should also be ready to give you contacts from similar migrations they’ve done in the past so that you can vet that they’re up to your particular needs.

Not getting your questions answered is a major red flag. Having your questions — and those you may not have thought to ask — anticipated demonstrates that you’re working with someone who knows their stuff and how to work with you during and after the transition.

Getting into the details of implementation also includes any back-end transitions that involve you, the potential vendor, and third parties. Apple Business (or School) Manager is one major example. How will the handoff from your old provider to the new one be accomplished?

On the other end, what’s involved in shifting the devices themselves from one MDM tool to the other? There’s the obvious fact of unenrolling and then re-enrolling devices, but how does that happen at the device level? Will you need to wipe the devices in the process? To what extent can the process be automated so you don’t need to worry about every device? Will users need to play an active part in the transition, and can you prepare and support them adequately?

On these last points, its crucial to remember that BYOD users are using their personal devices. That gives them more of a stake in what happens and requires them to invest more trust in your decisions and processes. From health to banking to personal communications, the level of personal data that we carry around on our phones and other devices can’t be overemphasized. This is where you absolutely need to stick the landing. If a vendor can’t ensure that you do, that’s another major red flag.

MDM needs to be central to your IT stack, but it is only one piece of it. How it fits with all the other pieces can be even more important than what the MDM software itself can do. This is another question where experience can vary significantly depending on a number of factors.

One of the most important considerations is that a new MDM platform integrate seamlessly with your identity access management tool. This is almost guaranteed if you’re using one of the major vendors in this space like Microsoft or Okta, but you will want to triple-check (or more), particularly if you have complex federation between different solutions. Likewise you’ll need to ensure that other systems like Microsoft 365, Google Workspace, Slack, CRM tools, and any in-house services can be supported in a way to doesn’t generate too much overhead for your team or create additional administrative tasks for your users.

Implementing a new MDM affects your user base as well as your IT staff. While you may be able to make the deployment go smoothly and have very little direct impact on user experience, that experience doesn’t stop when you switch. We live in a time when user self-service is more common and more expected than ever before. What will that look like?

Will there be a significant difference in what users will be able to do to enroll and provision devices and resolve issues on their own? How does the experience as well as the functionality shift, and will there be a learning curve? In an ideal world, self-service (and support more broadly) will improve, with users being able to handle their needs more easily — or at least stay comparable.

The last thing you want is to make any user-facing process more onerous — and today needing to call or message tech support is considered onerous, because everyone, especially young people, are digital natives. We all expect to be able to solve our own issues without making a phone call. Adding/improving self-service capabilities alone is a point in favor of investing in a new provider.

Even if the level of experience improves or remains roughly the same, there will be differences in terms of how users access self-service portals or connect with support. The experience and any user-oriented guides, training, and onboarding processes will change to some extent, but you can work to minimize the changes and acquaint everyone with the new tools.

Engaging users directly as part of the vetting and trial period as well as the lead-up to transition also provides a powerful way to be sure that you’re getting everything right and ironing out problems before day one. It also means building momentum and even excitement around the project.

Any IT project is an opportunity for staff to expand their horizons and their skill sets. Moving to a new MDM vendor can be a great way to engage people from different IT disciplines in the procurement and deployment process and orchestrate some dialog and cross-training (official or unofficial). IT has become so broad over the years that it can seem like different workers work at different companies altogether. Any major decision and rollout offers an opportunity to get the band together.

Beyond the team building, what can your staff take away from the experience? Are there training and certification programs from potential vendors? Can the integration with new systems be a chance for people to push their boundaries a little? There should be several ways for your team to stretch, grow, and stake out new professional territory that will help them in their current roles as well as in the future.

It’s worth noting, of course, that training, certification, and such are just a part of the support package that you get from a vendor. What support options are available is a crucial question, so much so that it might seem like I’m stating the obvious.

But support comes in many forms and with many different SLAs and commitments (from both parties). In addition to the standard responses when you call for help, support should include active engagement and advice from your MDM vendor, product updates, and day one support for Apple’s new releases of major OS versions, as well as updates and urgent patches.

You should be introduced to and familiar to with the various team members with whom you’ll be working during and after deployment. These are people you’re going to need to lean on in both good and no-so-good circumstances.

How well you work together is important on day one as well as in six months, a year, or even further down the road. This goes down somewhat to the vendor’s corporate culture (individuals can and will come and go), but it should also reflect your own department and company culture. The two need to be able to interface successfully. Understanding their vendor’s culture, working methods, and personalities is as important as understanding your own.

One of the great things about managing Apple products is the amazing Apple admin community that includes resources, conferences, discussions, and even a Slack presence open to all Apple admins. Don’t be afraid to make use of the people within that community for purchase advice; help moving through the selection, setup, and deployment processes; and ongoing information and advice after implementation.

It’s also worth noting that every major MDM vendor has its own admin community you can tap into — for instance, Microsoft just officially opened one for Apple Intune and Microsoft 365 admins. If you’re considering a product that doesn’t have such an active community around it, this might be a sign to be cautious.

The process of looking at MDM vendors is going to be a stressful prospect, particularly if you’re doing so for the first time or if you’re upgrading from a small-business tool like Apple Business Essentials to a full MDM product. The more homework you do in advance and the more you understand your own needs as well as the features of various products, the easier the scouting, decision-making, and eventual adoption will go.

Take the time to really consider each of these questions, your own answers, and the answers of potential providers. If implementing a new MDM is worth doing, it’s worth doing right.