I've already written about the 550-device MDM migration we ran at Life360 — the planning and execution and the Okta Device Trust lockout incident that nearly derailed week three. If you haven't read those, they're the context for this post.
The short version: we migrated 550 devices from VMware Workspace ONE to Intune and Kandji in 6 weeks with zero devices lost but one significant incident that cost us 45 minutes of engineering downtime and a substantial amount of my credibility for about a week. The incident was preventable. It was preventable by doing math I hadn't done before starting.
After the migration completed, I had a clear picture of exactly what I needed to know before day one that I didn't have. None of it was in a single place. The MDM Migration Planner is the tool I built from that picture.
The Platform Pair Problem
MDM migration planning advice is almost always generic: inventory your devices, create a pilot group, run waves, test compliance reporting. That advice is correct and almost useless, because the specific risks are entirely determined by which platforms you're migrating between.
Workspace ONE to Kandji has a different risk profile than Jamf to Intune. ADE re-enrollment behavior differs between platforms. Conditional Access conflict patterns are an Intune-specific concern. Certificate-based Wi-Fi profile handling is different in Jamf versus Kandji. The things that break are platform-specific, and a generic migration guide doesn't tell you which ones to watch for your particular combination.
The planner takes your source and target platform as inputs and generates a timeline and risk flag matrix scoped to that combination.
Wave Size: The Number Nobody Publishes
This is the section I wish someone had written before our migration.
When you migrate a device from one MDM to another, there's a window between unenrollment from the source platform and the new platform establishing a compliance signal in Okta. During that window, Okta sees the device as unmanaged. If your Device Trust enforcement mode is set to block rather than warn, users are locked out of everything behind Device Trust during that window.
The window duration depends on how long your target MDM takes to establish a compliance signal. For Kandji to Okta, in our environment, it was 2 to 4 minutes.
If you run a wave of 25 devices, the compliance windows open and close sequentially. By the time device 25 is in its compliance window, device 1 is already compliant and restored. The aggregate impact at any moment is small.
If you run a wave of 80 devices, the compliance windows overlap. You have 30 or 40 devices in a compliance gap simultaneously. The aggregate impact is 30 or 40 users locked out at the same time. That's what happened to us.
The planner calculates the recommended wave size ceiling based on your compliance window duration and your Device Trust enforcement mode. If you're in block mode, the ceiling is conservative. If you're in warn mode — which is where you should be during migration anyway — the ceiling is higher because the downside of overlap is a browser warning rather than a lockout.
Platform-Specific Risk Flags
Beyond wave size, the tool surfaces the risk flags relevant to your specific platform pair.
For migrations targeting Kandji or Jamf on Apple devices: ADE re-enrollment. When a device unenrolls from the source MDM and enrolls in the new MDM via Apple Business Manager, it re-enrolls through ADE. For devices with local data that hasn't been synced, it's a data loss risk. The flag prompts you to verify backup status across the fleet before starting.
For migrations targeting Intune in environments with Azure AD Conditional Access: CA policy conflicts. Conditional Access policies that require compliant devices will block users during the compliance window. CA can be set to report-only mode during migration, which allows access while logging the policy evaluation. The flag prompts you to make that switch before starting migration waves.
For migrations from Jamf with certificate-based Wi-Fi: certificate expiry planning. If your Wi-Fi profiles rely on device certificates issued by Jamf, you need a plan for how those certificates transfer or get re-issued before devices lose network connectivity.
The Cutover Checklist
The planner generates a pre-populated cutover checklist scoped to your source and target platforms. For Workspace ONE migrations, the checklist includes DEP profile re-assignment in Apple Business Manager and source platform set to read-only before the cutover window begins. For Jamf migrations, it includes smart group documentation and certificate authority migration steps. For Intune as target, it includes Conditional Access policy staging and Windows Autopilot profile assignment.
The checklist exports as CSV for teams tracking in spreadsheets and as Markdown for teams who want it in Confluence or a runbook system.
The planner requires no API keys or credentials. If you're planning an MDM migration and want to see what the risk flag matrix looks like for your specific platform pair, the tool is on GitHub. The 550-device migration series is the source material for the default assumptions.