Topic starter
10/06/2026 12:04 am
TL;DR: Migrating from Cisco Meraki Systems Manager requires cleanly removing old management control, reassigning device tokens, and preserving APNs or Android Enterprise trust so endpoints do not drift, lose control, or keep stale profiles, according to JumpCloud. The governance lesson is that endpoint identity transitions fail when lifecycle and cryptographic ownership are not treated as one process.
Editorial analysis by NHI Mgmt Group, based on content published by JumpCloud: “The Technical Guide to Migrating from Cisco Meraki Systems Manager (SM)”.
Key questions
Q: What breaks when an MDM migration does not fully remove the old management profile?
A: The device can keep stale configuration, certificates, or policy bindings that belong to the previous MDM, which creates drift between the intended control plane and the actual endpoint state.
Q: Why does endpoint migration create identity risk instead of just operational downtime?
A: Because management authority is part of the device’s trust state.
Q: How can security teams tell whether an MDM cutover is actually complete?
A: They should verify three things: the old profile has been removed locally, the endpoint no longer reports the previous organisation identifier, and the new MDM can successfully issue policy or wipe commands.
Practitioner guidance
- Map endpoint offboarding before enrollment cutover Define the exact sequence for retiring the old MDM trust relationship, including unenrollment command delivery, cloud token reassignment, and local profile removal before any new enrollment is trusted.
- Validate push-certificate and token handoff together Check APNs certificates, Android Enterprise service accounts, and cloud enrollment tokens as one migration dependency chain so the target MDM can complete its handshake.
- Use supervised wipe paths where residual trust is unacceptable For corporate-owned devices, prefer full reset or Automated Device Enrollment workflows when the business cannot tolerate leftover profiles, orphaned certificates, or policy conflicts.
Bottom line: Meraki-to-new-MDM migration fails when endpoint deprovisioning, certificate handoff, and re-enrollment are not executed as one governed lifecycle.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
11/06/2026 1:41 am
Endpoint migrations expose a governance assumption that device identity can be transferred without a control gap. That assumption works only when the old authority is fully revoked before the new one takes over. In this workflow, the device can remain bound to stale profiles, expired tokens, or orphaned payloads if the sequencing fails. Practitioners should treat migration as a lifecycle event, not a tooling change.
A few things that frame the scale:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why unmanaged identity transitions so often become hidden control failures.
A question worth separating out:
Q: When should organisations choose a factory reset instead of in-place migration?
A: Choose a factory reset when the endpoint must be fully re-owned, when residual policy state would create compliance risk, or when a supervised device must be rebuilt from a known-clean baseline. In-place migration is only suitable when the team can verify that the old profile has been removed without leaving hidden management residue.
👉 Read our full editorial: MDM migration from Cisco Meraki exposes endpoint identity drift
12/06/2026 3:15 am
Endpoint identity drift is a lifecycle failure, not a deployment glitch. The article shows that MDM migration breaks when deprovisioning, certificate transfer, and re-enrollment are treated as separate tasks. That separation creates a trust gap where the device can remain partially bound to the old authority while the new one is trying to take control. Practitioners should read this as an identity governance problem spanning endpoint, certificate, and enrollment ownership.
A question worth separating out:
Q: Should organisations use in-place migration or a full wipe for managed devices?
A: Use a full wipe when the environment cannot tolerate residual trust state or orphaned certificates. In-place migration is faster and preserves user data, but it only works if the organisation can tightly coordinate unenrollment and re-enrollment. The choice depends on how much leftover policy state you are willing to accept.
👉 Read our full editorial: MDM migration from Cisco Meraki exposes endpoint identity drift
This post was modified 4 days ago by NHI Mgmt Group