Otukan plans a move from your current device manager in three parts: constraints, sequence and recovery. First it works out, per platform and ownership mode, which devices need a reset, which only need re-enrolment and what each user will notice. Then it rebuilds policies and app delivery in Otukan from their purpose, proves the path on a pilot wave and moves the fleet in confirmed stages. Throughout, the old service stays live for groups not yet moved, and every wave has a written fallback and a named support owner. The plan works the same way whichever product you are leaving.
Constraints
A device can only be managed by one service at a time, so every migration is a re-enrolment. What differs is how disruptive that is for each device.
| Device group | What migration involves | User impact |
|---|---|---|
| Android, corporate-owned (fully managed or dedicated) | Reset, then provisioning into Otukan through zero-touch, QR code or another supported method | Device returns to setup; local data not synced elsewhere is lost |
| Android, work profile on personal device | Old work profile removed, new one created through Otukan | Personal side untouched; work data in the old profile is removed |
| Apple, assigned through Apple Business Manager or Apple School Manager | Reassignment to Otukan in the organisation’s account; erase needed or not depending on OS version and enrolment | Varies per group; confirmed on the pilot |
| Apple, User Enrollment | Managed account removed from the old service and enrolled again into Otukan | Personal data untouched; managed apps reinstall |
Otukan fills in this table for your fleet during planning. Two further constraints shape the calendar: the date your current contract ends, and the renewal dates of platform credentials such as the Apple push certificate. Both are placed on the plan before any wave is scheduled.
Preparing users
Where a reset or work-profile removal is involved, users need to know what will happen and what to back up. Otukan provides the wording per group and confirms backup before a device moves. For the enrolment paths themselves, see MDM device enrollment.
Sequence
Otukan runs migration as a chain of steps, each depending on the one before it.
- Survey. Device groups, platforms, enrolment modes, provisioning channels and required apps are recorded.
- Policy transfer. Each existing policy is listed with its purpose and rebuilt in Otukan. Settings that were workarounds for the old product are dropped rather than copied.
- App delivery. Required apps, their managed configurations and in-house builds are set up in Otukan’s managed distribution and verified on test devices.
- Pilot wave. A small group covering each device type migrates first. Otukan checks on the device that policy and apps arrived, and records the user experience.
- Staged waves. Groups or sites move one at a time. Each wave is confirmed before the next is scheduled.
- Close-out. Old enrolments, tokens and device assignments in the previous service are closed.
The pilot is the most valuable step. It turns assumptions about resets, app arrival and user effort into facts about your own devices. The questions worth settling before choosing a new service are listed on the MDM requirements checklist.
Recovery
Every wave has a fallback, and its shape depends on how far a device has gone.
- Before reset or removal. The device is still managed by the old service. Pausing is simple: the wave stops and nothing changes for the user.
- After reset or removal. Going back means enrolling the device into the old service again. The plan keeps that route open until the wave is confirmed.
- After confirmation. The device is fully managed by Otukan, and issues are handled as normal support.
Support ownership is split by service, not by guesswork. Your help desk takes first contact; Otukan owns enrolment, policy and app issues in the new service; whoever runs the old service owns anything that has not yet moved. The split is written down before the pilot and reviewed after every wave.
Each wave ends with a short review: what took longer than planned, which users needed help, and which devices stalled. Those findings adjust the next wave’s timing, user wording and support staffing, so each wave builds on what the last one taught.
The service you move to is described on mobile device management. Migration is one stage of evaluation and lifecycle, alongside the pilot, ownership, support and a planned exit.