Do not use policy removal as rollback for Android Management API migration

Source facts

Intune’s migration policy moves existing personally owned Android work-profile devices to Android Management API. Once migrated, they cannot return to the previous management method. Removing or unassigning the profile leaves completed migrations in place; targeted devices that never received it are not moved. Migration progress appears in the Personal Devices on Android Management API report, not the policy’s device-assignment status or the device’s configuration tab. Microsoft Learn.

Applicability

Use this check for existing personally owned work-profile devices, not the separate tenant-wide web-enrollment switch for new devices. Devices must run Android 9 or later to migrate. Microsoft Learn. Review the source’s changed feature behavior before selecting a migration cohort.

DSE recommendation

Treat stopping further targeting and reversing completed migration as different decisions. Ask the endpoint owner to approve a small, representative group after checking custom policies, Wi-Fi authentication, and other relevant feature changes. Define an acceptance point and escalation route before assignment. If a problem appears, preserve the actual migration state of each device instead of assuming deletion of the profile restores the fleet.

Verification

Follow the dedicated migration report through the pilot and reconcile completed, pending, and error states with representative device behavior. Test required work applications and access after migration. Record which devices have crossed the irreversible transition, then stop expansion if unresolved incompatibilities remain. Keep any recovery plan explicit about the absence of an in-place rollback.

Official references

Microsoft Learn: Android Management API for personally owned work profiles.