What 15 years of switching MDM platforms actually taught me.

I was early. Not “early adopter reading the blogs” early — early in the sense that I was working for one of the first companies in the enterprise mobility management service provider space when the platforms we now take for granted were still figuring out what they were.

The company was Enterprise Mobile. We eventually became Intermec, and then Honeywell Scanning and Mobility. But in those early days, we were sitting across from enterprise customers who needed their mobile device fleets managed, and we were picking up whatever tools existed to do it. SOTI Pocket Controller. BlackBerry BES. Afaria. MobileIron. Wavelink Avalanche for the rugged frontline device programs. And a Wi-Fi network management platform called Wandering WiFi — which, if that name doesn’t ring a bell, you probably know it better by what it became: AirWatch. We were running it before it pivoted to MDM, before it became the market leader, and well before VMware wrote a $1.54 billion check to acquire it in 2014. We weren’t evaluating platforms from a position of expertise — we were building that expertise in real time, on real customer deployments, often with software that was still finding its footing.

It was, in retrospect, one of the best possible educations in this industry. And the most important thing it taught me took years to fully understand.

The pattern nobody tells you about

Early on, I believed what the vendors believed about themselves. Each platform had a different pitch. Different vocabulary. Different UI paradigms. Different certifications to earn and feature matrices to memorize. When you’re new to the industry and the software is new too, that surface-level difference feels significant. You start to develop platform loyalty the same way people develop loyalty to operating systems — through familiarity, through investment, through the sunk cost of everything you’ve already learned.

Then you work with enough customers running different platforms and something starts to bother you. The outcomes are the same. The device gets enrolled. The policy gets applied. The app gets distributed. The compliance report gets generated. The customer on AirWatch and the customer on MobileIron and the customer on SOTI are all getting fundamentally the same result — sometimes paying different prices, sometimes getting a few additional features, sometimes getting a slicker interface — but landing in the same place.

At first I chalked it up to coincidence. Then I chalked it up to the customers having similar requirements. It took a while longer to understand what was actually happening: the platforms weren’t differentiated at the level that mattered. They were all sitting on top of the same OS APIs, the same device management protocols, the same manufacturer-defined management surfaces. Wavelink Avalanche was managing the same Zebra and Honeywell rugged devices as SOTI — different console, same underlying device APIs. Wandering WiFi pivoted to MDM and became AirWatch not because it invented new management capabilities, but because the smartphone boom created demand for the same model applied to a new device category. The logo on the console was the variable. The protocol underneath was the constant.

Once you see that, you can’t unsee it. Every new platform I sat down in front of after that realization felt familiar within hours — not because the UI was the same, but because the underlying model was. Same enrollment flow, different wizard. Same profile schema, different editor. Same compliance engine, different dashboard. I wasn’t learning a new platform. I was learning a new interface for the same model.

The mistake hubris made

Understanding the pattern made me better at the work. It also, for a period, made me worse.

When you feel like you understand something deeply — when you’ve seen enough deployments across enough platforms that the fundamentals feel obvious — there’s a temptation to push against the constraints rather than work within them. To assume that what the platform says is a limitation is actually just a design choice that can be worked around with enough creativity.

I ran into this head-on while building MobiLauncher at Enterprise Mobility. MobiLauncher was a custom lockdown interface — a web app running inside an Android WebView within a SOTI MobiControl Lockdown Profile. The project was genuinely exciting. We were pushing into territory the platform wasn’t explicitly designed for, using the JavaScript Agent API and device Custom Attributes to do things that required real ingenuity to make work.

The problem was that I got ambitious faster than I got stable. The toolset I was allowed to work with was constrained — intentionally, for good operational reasons. But I was committed to showing what was possible, and that commitment started driving decisions that should have been driven by what was reliable. I shipped releases that were technically impressive and operationally brittle. Features that worked in testing and misbehaved in production. And eventually I had to roll back to a more stable build with less functionality, swallow the lesson, and rebuild from a more honest foundation.

It wasn’t a catastrophic failure. But it was a humbling one. Because the thing I’d understood intellectually for years — that the platform has constraints for a reason, that the protocol defines the boundary of what’s safe to build against — I had stopped actually believing in practice. I’d let the excitement of the problem override the discipline of the craft.

What the pattern actually gives you

Here’s what fifteen years and more platform migrations than I can accurately count has left me with:

Migrations are less scary than they look. When you understand that you’re not re-learning device management — you’re re-enrolling devices into a different implementation of the same model — the anxiety about switching platforms deflates significantly. The hard part of a migration is almost never the platform itself. It’s the automation you’ve built on top of vendor-proprietary APIs, the tribal knowledge baked into runbooks that nobody updated, the integrations that assumed a specific implementation detail. Know where your lock-in actually lives before you sign anything.

Platform loyalty is a trap. I’ve watched good engineers spend enormous energy defending a platform choice that was made three years ago under different constraints, long past the point where a different tool would have served them better. The platform is a vehicle, not an identity. The expertise you’re building is in the underlying discipline — endpoint management, policy design, enrollment architecture, automation — not in one vendor’s interpretation of it.

Constraints are information. Some of the worst decisions I’ve made in this industry came from treating a platform constraint as a problem to be solved rather than a signal to be understood. Why does this API not expose that capability? Why does the platform not support this workflow natively? Sometimes the answer is “the vendor hasn’t built it yet.” But sometimes the answer is “the OS doesn’t support it safely” or “customers who tried this pattern got burned.” The constraint knows something. Ask what before you work around it.

The early exposure was the gift. Being in the room when these platforms were young — running Wandering WiFi before it became AirWatch, managing rugged Zebra fleets through Wavelink Avalanche before the Android Enterprise era simplified everything, watching the industry settle on patterns that are now considered obvious — gave me a reference point that’s hard to acquire any other way. I didn’t just learn how MDM works. I learned why it works the way it does, which is a different and more durable kind of knowledge.

The thing I’d tell someone starting out today

Don’t get attached to the platform. Get attached to the protocol. Learn how Apple’s MDM spec actually works — not just how Jamf exposes it, but what APNs is doing, what a mobileconfig actually contains, what the enrollment handshake looks like at the wire level. Learn what Android Management API defines and what it doesn’t. Understand where the OS ends and the vendor begins.

Do that, and every platform you’ll ever sit down in front of becomes familiar within a day. New logo, same model. And when the inevitable migration comes — because it always does — you’ll be the calmest person in the room. Not because you’ve done it before, but because you understand what’s actually changing and what isn’t.

The platform is rented. The understanding is yours.