Planning a managed device migration means deciding, device by device, how control moves from one management system to another without breaking the work those devices do. A mobile security team should evaluate it by management mode first, because that decides whether a device needs a factory reset. Then it should assign app, operating system and backend tasks to named owners, and test in waves with a written exit condition. This article covers Android and iOS fleets as separate cases. It does not replace a vendor’s own migration tooling, and it treats every trust boundary, not only enrolment, as part of the move.
Buyer task: the affected flows and the trust boundary
A migration is not a file copy. Each managed device trusts one management server to set its policy, push its apps, hold its certificates and wipe it if lost. Moving to a new server means that trust is withdrawn from one party and granted to another, and for a short time the device may trust neither. That window is where risk sits.
Three flows are usually affected:
- Enrolment. How a device becomes managed, and what the user sees while that happens.
- Line-of-business work. The apps and kiosk workflows the device exists to run, with their data and backend sessions.
- Security operations. Remote lock and wipe, compliance reporting and certificate renewal for Wi-Fi, VPN and email.
The management mode sets the path. Android and iOS differ, so read each row for its own platform only.
| Platform | Management mode | Migration path | Reset needed |
|---|---|---|---|
| Android | Fully managed or dedicated device (device owner) | Reset, then re-enrol through zero-touch, QR code or token | Yes |
| Android | Work profile on a personal device | Remove the old work profile, enrol a new one | No, but work data in the profile is removed |
| Android | Work profile on a company-owned device | Reset, then re-enrol | Yes |
| iOS | Supervised, enrolled through Apple Business Manager | Reassign in Apple Business Manager; confirm whether your OS versions allow migration without erase | Depends on OS version |
| iOS | User enrolment on a personal device | Remove the old enrolment, enrol again | No, but managed apps and data are removed |
The Android modes themselves changed over the years, which is why a long-lived fleet often mixes several.
- 2014
Android 5.0
Managed profiles and device owner mode arrive, the foundation of today's work profile and fully managed devices.
- 2018
Android 9
Several legacy device administrator policies are deprecated for enterprise use.
- 2019
Android 10
Those deprecated policies stop working for apps that target Android 10, pushing fleets to modern management.
- 2020
Android 11
Company-owned devices with a work profile replace the earlier fully managed device with a work profile.
Control fit: app, operating system and backend responsibilities
A migration succeeds when every party knows what it owns. The operating system enforces the management mode. The management systems, old and new, deliver policy. The apps hold data and sessions. The backend decides whether a device is still allowed in.
Moves with the device
- Management mode and restrictions
- Managed app installation and configuration
- Wi-Fi, VPN and email certificates issued by the new system
- Kiosk and dedicated-device settings
Must be planned outside the device
- Backend allow-lists tied to the old system's device identifiers
- App data that a reset removes and users still need
- Network rules and conditional access that trust the old server
- Support scripts and runbooks that name the old console
Otukan MDM enrols devices, applies policy and manages kiosk and dedicated devices, and it lets you control where management data lives, which matters when the old system held that data somewhere you did not choose. For devices supplied by a manufacturer, Otukan supports management distributed by the device maker, so new units arrive ready to enrol. Otukan device management engineering works with your team to map each device to its management mode, plan the waves and write the exit test for each one. For the evaluation side of the same decision, see MDM migration, and the enrolment options are in MDM device enrolment.
Evaluation: platforms, evidence and user impact
Move in waves. Each wave has an entry condition, a defined set of devices and an exit test that must pass before the next wave starts.
Inventory
Record each device's platform, OS version, management mode and owner team.
Prepare
Back up required data, stage the new policy and issue new certificates.
Move
Reset or unenrol, then enrol in the new system through the chosen method.
Exit test
Run the real workflow on moved devices and confirm backend access and remote wipe.
Retire old trust
Remove moved devices from the old system and its backend allow-lists.
Wave sizes should grow only as confidence grows. The chart shows the shape of such a plan for an example fleet.
Illustrative only: an example of how wave sizes grow after a small pilot. Your sizes depend on support capacity and on how many device models and modes each wave contains.
Put every device model and every management mode in the pilot, even if that makes it harder. A pilot of one model tells you little about the rest of the fleet. Measure user impact directly: how long each device was out of service, whether any user had to re-enter data, and how many support contacts each wave produced. Those figures, dated and kept with the exit test results, are the evidence your stakeholders will ask for.
A migration is finished when the old system trusts nothing and nothing trusts the old system.
Migration readiness checklist
- Every device is listed with platform, OS version, management mode and owner team.
- Devices that need a reset are known, and users know what will be removed.
- Backend access, certificates and network rules are mapped to the new system per wave.
- The pilot includes every device model and every management mode.
- Each wave has a written exit test that runs the real workflow.
- The old system stays monitored until the last wave passes, and no device is enrolled in both.