{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-491-do-not-use-policy-removal-as-rollback-for-android-management-api-migration/", "item": { "id": "https://update.dsesecurity.com/updates/dse-20260909-491-do-not-use-policy-removal-as-rollback-for-android-management-api-migration/", "slug": "dse-20260909-491-do-not-use-policy-removal-as-rollback-for-android-management-api-migration", "url": "https://update.dsesecurity.com/updates/dse-20260909-491-do-not-use-policy-removal-as-rollback-for-android-management-api-migration/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-491-do-not-use-policy-removal-as-rollback-for-android-management-api-migration.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-491-do-not-use-policy-removal-as-rollback-for-android-management-api-migration/" }, "title": "Do not use policy removal as rollback for Android Management API migration", "summary": "Does unassigning the Android Management API migration profile return migrated devices to their former manager?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:23:45+00:00", "modified_at": "2026-09-10T02:08:05+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 241, "potentially_affected": "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. 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.", "primary_source": { "name": "Android Management API for personally owned work profiles - Microsoft Intune | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/intune/device-enrollment/android/android-management-api-overview", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Source facts

\n

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.

\n

Applicability

\n

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.

\n

DSE recommendation

\n

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.

\n

Verification

\n

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.

\n

Official references

\n

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

", "content_text": "Source facts\nIntune’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.\nApplicability\nUse 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.\nDSE recommendation\nTreat 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.\nVerification\nFollow 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.\nOfficial references\nMicrosoft Learn: Android Management API for personally owned work profiles.", "content_markdown": "## Source facts\n\nIntune’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](https://learn.microsoft.com/en-us/intune/device-enrollment/android/android-management-api-overview).\n\n## Applicability\n\nUse 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](https://learn.microsoft.com/en-us/intune/device-enrollment/android/android-management-api-overview). Review the source’s changed feature behavior before selecting a migration cohort.\n\n## DSE recommendation\n\nTreat 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.\n\n## Verification\n\nFollow 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.\n\n## Official references\n\n[Microsoft Learn: Android Management API for personally owned work profiles](https://learn.microsoft.com/en-us/intune/device-enrollment/android/android-management-api-overview)." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/dse-20260909-491-do-not-use-policy-removal-as-rollback-for-android-management-api-migration/", "url": "https://update.dsesecurity.com/updates/dse-20260909-491-do-not-use-policy-removal-as-rollback-for-android-management-api-migration/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-09-09" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/dse-20260909-491-do-not-use-policy-removal-as-rollback-for-android-management-api-migration/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Do not use policy removal as rollback for Android Management API migration", "item": "https://update.dsesecurity.com/updates/dse-20260909-491-do-not-use-policy-removal-as-rollback-for-android-management-api-migration/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/dse-20260909-491-do-not-use-policy-removal-as-rollback-for-android-management-api-migration/#article", "identifier": "https://update.dsesecurity.com/updates/dse-20260909-491-do-not-use-policy-removal-as-rollback-for-android-management-api-migration/", "url": "https://update.dsesecurity.com/updates/dse-20260909-491-do-not-use-policy-removal-as-rollback-for-android-management-api-migration/", "headline": "Do not use policy removal as rollback for Android Management API migration", "description": "Does unassigning the Android Management API migration profile return migrated devices to their former manager?", "abstract": "Does unassigning the Android Management API migration profile return migrated devices to their former manager?", "articleBody": "Source facts\nIntune’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.\nApplicability\nUse 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.\nDSE recommendation\nTreat 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.\nVerification\nFollow 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.\nOfficial references\nMicrosoft Learn: Android Management API for personally owned work profiles.", "datePublished": "2026-09-10T00:23:45+00:00", "dateModified": "2026-09-10T02:08:05+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/dse-20260909-491-do-not-use-policy-removal-as-rollback-for-android-management-api-migration/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/dse-20260909-491-do-not-use-policy-removal-as-rollback-for-android-management-api-migration/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Do not use policy removal as rollback for Android Management API migration" }, "articleSection": [ "Business Continuity", "IT" ], "keywords": [ "Business Continuity", "IT", "Guide", "Information priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 241, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Android Management API for personally owned work profiles - Microsoft Intune | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/intune/device-enrollment/android/android-management-api-overview" } } ] } }