Custom DPC to AMAPI Migration Guide

Custom DPC to AMAPI migration: quick answer

Google provides a one-way path for an eligible device already managed by an EMM's custom Device Policy Controller (DPC) to move to Android Device Policy and the Android Management API (AMAPI). The migration can be transparent to the device user, but it cannot be undone after completion and it cannot move a device to a different EMM or enterprise.

This is not a general cross-vendor migration method. It applies only when the current EMM supports Google's custom-DPC migration flow within the same Managed Google Play Accounts enterprise. Confirm support, eligibility, policy parity, and recovery procedures with the current EMM before scheduling a rollout.

When Google's migration path applies

Google's current migration guide lists these prerequisites:

• The device is already managed by the same EMM through a custom DPC.
• The custom DPC integrates the AMAPI SDK; Google requires version 1.1.4 or later and recommends the latest available version.
• The device was enrolled through the Google Play EMM API and belongs to a Managed Google Play Accounts enterprise.
• The device runs Android 9 or later. A work profile on a company-owned device requires Android 11 or later.
• The target AMAPI policy belongs to the same enterprise as the existing Play EMM API enrollment.

The flow covers personally owned work profiles, company-owned work profiles on supported Android versions, and fully managed devices. It does not support moving a device between EMM providers or enterprises. Devices outside the eligibility boundary need a separately planned enrollment or reprovisioning path.

How the migration-token workflow works

1. Prepare the target policy. Build an AMAPI policy in the same enterprise. Google recommends making it equivalent to the policy currently enforced by the custom DPC.
2. Create one token per device. The EMM server calls enterprises.migrationTokens.create. The token identifies one device, its management mode, and the initial AMAPI policy.
3. Deliver the token to the custom DPC. A token remains usable until migration succeeds or the token expires. Google allows an expiration of at most seven days.
4. Make Android Device Policy available. The EMM ensures Android Device Policy is installed before ownership is transferred.
5. Start migration from the custom DPC. The DPC calls migrateDeviceManagementToAndroidManagementApi through the AMAPI SDK.
6. Verify the result. After completion, ownership moves to Android Device Policy, the AMAPI device becomes active, and the EMM can receive a status report through its configured Pub/Sub channel.

The device needs internet access to begin. Google designs the sequence so network-dependent work occurs before the transfer of device-owner or profile-owner rights, but that design does not replace a tested rollout and support plan.

Plan policy parity before cutover

Inventory the policies, managed apps, certificates, networks, restrictions, and lifecycle actions enforced by the custom DPC. Recreate only supported requirements in the target AMAPI policy, then test them on representative device models, Android versions, ownership modes, apps, and networks.

Do not assume that a platform policy name guarantees identical behavior across devices or management providers. Record any unsupported or changed setting, define the acceptable fallback, and decide whether the affected population should migrate, remain temporarily on the existing path, or use a separate reprovisioning plan.

Handle Wi-Fi by management mode

Wi-Fi behavior differs by management mode. On fully managed devices and company-owned work-profile devices, matching SSID and security settings in the AMAPI ONC policy help Android Device Policy take over management of an existing network. Removing the custom DPC after migration can remove networks that it configured, so the target policy must contain the required replacements.

For a work profile on a personally owned device, the custom DPC supplies information about only the Wi-Fi networks it configured. The AMAPI SDK removes those networks before ownership transfer so Android Device Policy can manage the policy versions. The active network can be briefly unavailable. Android 12 has additional permission and removal behavior documented by Google, so test that version explicitly.

Monitor the attempt and define the recovery boundary

The custom DPC must implement a NotificationReceiverService, even when the EMM does not expose detailed progress to an administrator. Use the AMAPI SDK's migration-attempt state together with the AMAPI device state and Pub/Sub status report to distinguish preparation, failure, and completion.

Before starting, document how to pause a batch, expire or replace an unused token, restore connectivity, and keep devices managed when a prerequisite fails. After a device completes migration, the transfer is one-way and cannot be rolled back to the custom DPC. A pre-cutover contingency plan is therefore different from a post-migration rollback.

Do not confuse in-place migration with changing EMMs

Google's migration-token flow stays inside the same EMM and enterprise. Sharing Android Device Policy or AMAPI as an underlying platform does not make devices portable between management providers. If the project changes EMMs or enterprises, obtain a provider-specific migration plan and expect that unsupported populations may need removal from management, a work-profile recreation, or a factory reset and new enrollment.

Avoid claims of guaranteed wipe-free migration, zero downtime, universal device eligibility, or automatic policy equivalence. Eligibility and user impact depend on the current management architecture, Android version, ownership mode, policy, network, and provider implementation.

Where Nomid fits

This article explains Google's platform migration capability; it does not claim that Nomid implements the custom-DPC migration-token workflow. For new or reprovisioned supported company-owned devices, review Nomid's QR code and zero-touch enrollment paths. Use the Android Device Policy guide for the management agent's role and the Android Enterprise overview for ownership modes, enrollment, policy, and lifecycle context.

Before changing a production fleet, ask the current EMM to confirm whether Google's in-place path is supported for the exact enterprise and device population. If it is not, plan a separately reviewed enrollment transition rather than treating AMAPI as a promise of cross-vendor portability.