MDM migration: change vendors without stopping the fleet.

The most common reason for staying on an ill-fitting MDM is not satisfaction — it is the fear of the switch. That fear was justified for a long time. With the API for Apple Business Manager and automated assignment through Automated Device Enrollment, the switch is now a project of weeks rather than years. We plan it, test it on a pilot group, and carry it out before your users notice anything has happened.

Plan the migration Compare the platforms

2–4 weeks for 30–150 devices

0 days of parallel operation needed

27% macOS share in mid-market

1 contact instead of a ticket system

Trigger

How you notice the platform no longer fits.

Rarely through one big grievance — usually through four small ones that add up over the years.

You pay for the platform and use a quarter of it

The licensing models of the large vendors are cut for corporations. Anyone managing fifty devices often pays for a feature set of which never more than the basics were put into operation.

Every change needs a specialist

If nobody in-house can adjust a policy without calling the service provider, the platform is too complex for your organization — regardless of how powerful it is.

Security costs extra

With some vendors, endpoint protection, encryption management, and identity services are separate products with separate contracts. What belongs together turns into three invoices and three consoles.

Windows tooling for Apple devices

Cross-platform solutions map Apple features with a delay. New operating system versions are only supported weeks later — in an Apple fleet that is felt every autumn.

The difference from before

Apple removed the switching barrier itself.

Until recently, an MDM switch meant touching every device, disturbing every user, in case of doubt running two systems in parallel for years, and leaving the migration to the hardware refresh. With the API for Apple Business Manager and automated assignment through Automated Device Enrollment, that route is no longer necessary.

Read device and assignment data programmatically instead of maintaining it by hand in the web interface
Assignment to the new MDM server automated for the whole fleet instead of device by device
Migration in waves by team or location, pausable at any time
No parallel operation over years, because the move is not tied to the hardware cycle

Approach

Three paths — and when each is the right one.

Almost every fleet is migrated in a mix. What matters is which part goes which way.

	Reassignment via ABM	Reset and rebuild	Parallel operation
User data	preserved	backup and restore required	preserved
Downtime per device	minutes	one to two hours	none
Prerequisite	device is captured in Apple Business Manager	none	double licensing costs
Suited to	the bulk of a well-maintained fleet	legacy devices and configurations grown over time	transition phases in very large fleets
Risk	low, controllable in waves	low, but noticeable for users	high — two truths about the same device inventory

Our recommendation is almost always the same: reassignment via Apple Business Manager as the standard route, a reset for the remaining stock that is overdue anyway — and parallel operation only for as long as a pilot group is running. Permanent parallel operation is not a compromise but the most expensive route of all: you pay twice and end up unsure, on every device, which policy actually applies.

Process

How a migration runs with us.

Take stock

Which devices exist, which are captured in Apple Business Manager, which policies are actually active — and which merely still present.

Build the target

Rebuild of the configuration in the target system, derived from your actual requirements rather than from the legacy stock. Where certification applies: from the evidence obligations.

Run a pilot group

Five to ten devices across departments, one week in everyday use. What surfaces here does not surface later.

Switch in waves

Migration by team or location, with an announced time window and pausable at any point. At the end, the legacy system is shut down cleanly.

For certified companies

A migration is the best moment to straighten out your evidence.

Anyone who has to evidence ISO 27001 or TISAX® knows the problem: the policy demands one thing, the MDM enforces something slightly different, and in the audit that gap turns into a nonconformity. Rebuilding the configuration lets you clear this up in one pass — the target configuration is derived from the requirements, not from what grew historically.

Encryption and patch level as enforced configuration with retrievable evidence
Device compliance as a condition for access, checked continuously rather than once
Audit evidence straight from the MDM instead of from assembled screenshots
One configuration that fits the requirements of NIS2, ISO 27001, and TISAX® at once

FAQ

Frequently asked questions about MDM migration.

Do devices have to be wiped for the switch?

In most cases, no. Through Apple Business Manager, devices can be assigned to a different MDM server; the old management profile is then removed and the new one installed. User data, apps, and settings are preserved in the process. A full reset only really makes sense in two situations: for devices that were never properly captured in Apple Business Manager, and for legacy stock whose configuration has grown over the years to the point where a clean start is faster than any cleanup. Which path applies to which part of your fleet, we settle before the first device — not during the migration.

How long does a migration take?

For a typical fleet of 30 to 150 devices we plan for two to four weeks, from taking stock to the last migrated device. The larger part of that is not the technology but the preparation: rebuilding policies, checking assignments, running a pilot group, and evaluating the results. Switching a single device takes minutes. What matters is that it runs predictably for every device — and that is decided during planning.

What changed technically to make switching easier today?

Two things. Apple introduced an API for Apple Business Manager that allows device and assignment data to be read and managed programmatically instead of maintained by hand through the web interface. And with it, assigning devices to a different MDM server via Automated Device Enrollment can be automated. For a fleet in the three-digit range, that is the difference between a project spanning months and one spanning weeks — and exactly why parallel operation over years is no longer a necessary evil.

What happens to our existing policies and compliance evidence?

They get translated, not copied. Every MDM platform maps policies differently, which is why a switch is always an opportunity to clear out what has accumulated — in practice, almost every configuration holds a stock of profiles nobody needs anymore and nobody dares delete. For companies with ISO 27001 or TISAX®, we take the opposite route: we derive the target configuration from the requirements you have to evidence, and make sure that after the migration the evidence is again retrievable directly from the MDM.

We are actually happy with Jamf — is a switch still worth it?

Then probably not, and we will tell you so. Jamf is an excellent platform, particularly for large fleets with an administration team of their own. A switch pays off where the platform is larger than the need: when you pay for features that were never put into operation, when every change requires specialist knowledge that does not exist in-house, or when you buy security features separately that are included elsewhere. We compare the platforms openly — the honest comparison is linked on this page.