Sophos Mobile: Migrate Android Device Administrator devices to Android Enterprise

This article helps you choose the migration path and identify the necessary checks. It does not authorize a production reset. Sophos describes Device Administrator as a legacy management mode: In Sophos Mobile it is available only for Android 9 or earlier; Android 10 and later cannot be enrolled in this mode. This does not mean that every Android Device Policy Manager feature has been discontinued generally, nor is it a recommendation to keep running Android 9. Do not enroll new devices in the legacy mode. The migration branches below assume an Android Enterprise environment has already been set up and configured.

Establish ownership and target mode first

Before making any change, check the actual management mode, device identity, ownership, Android version, assigned user, policies, applications, connectivity and latest device status on the device and in the correct Sophos tenant.

Prepare reenrollment before making changes

Carry out this check while the old device is still managed. It triggers neither a reset nor unenrollment. Record the following details for the selected target mode in the migration log:

Under Sophos Fusion > My Products > Mobile > Setup > Google setup > Android Enterprise, check the existing Android Enterprise mode, displayed account details and state of Use managed Google domain device enrollment. Reuse an existing organization registration; do not run Register account again or replace the Google connection. Resolve a missing or unclear connection first using the section on connecting the organization to Google.
Have an Android Enterprise device policy ready for the corporate device, or an Android Enterprise work profile policy for the personal device. Record the names of the target policy and its task bundle. The bundle for each device type must contain at least Enroll and Assign policy with that specific policy. A legacy Device Administrator policy is not a substitute.
If using the Self Service Portal, open the configuration that applies to the user under Setup > Self Service Portal. In the Android platform settings, Enrollment package must point to the prepared task bundle. Check Owner, the target Device group, group priority and remaining device quota. Check an existing suitable configuration rather than creating a new one as a matter of course or changing Default. The section on preparing the policy, package, and user identity describes the preparation.
Check that Sophos Mobile Control is approved in Managed Google Play. Without that approval, the managed app does not update automatically. If domain device enrollment is enabled, the intended users must exist in the managed Google domain. This domain device enrollment requires Mobile Control 9.8 or later; work profiles also require all available operating-system and app updates to be installed. For a task initiated by Sophos Mobile, the assigned email must exactly match the Google sign-in.
Choose an enrollment path permitted by the existing organization mode and prepare the user handoff below with the responsible IT team in advance. For an organization registered in managed-Google-domain mode before April 9, 2024, without domain device enrollment enabled, administrator enrollment is unavailable; prepare the permitted SSP path instead. Do not casually enable the switch as a migration step. Changes to the organization connection or enrollment mode require separate approval.

For a corporate device with an assigned user, the Android Enterprise guide under “Administrator pilot” describes the supported wizard path through Devices > Add > Add device wizard, user selection, Platform: Android and the prepared enrollment package. Follow this path only after the factory reset has been separately authorized and confirmed on the device. If SSP is required, use the SSP workflow described there. QR, Zero-touch and userless methods are alternatives requiring their own preparation, not additional mandatory steps.

For a verified personal device, prepare the Set up the work profile section in the Android BYOD guide for the user handoff in advance. It covers Owner: Personal, the work-profile package and Mobile Control setup on the device. This new enrollment starts only after the old unenrollment has been confirmed and the correct old record subsequently deleted. The privacy and consent checks under “Before enrollment” are also required; the BYOD workflow does not apply to corporate devices with a work profile.

If any of these prerequisites are missing, stop before either migration branch. Before making changes in production, test the selected path on an authorized, representative test device. Prepared accounts, a saved package or visible portal options do not prove successful device enrollment. After enrollment, check the management mode, user assignment, task status and effective policy in Sophos Mobile and on the device.

Documented migration branches

Do not mix the two documented paths:

Corporate-owned, currently Device Administrator → Android Enterprise: fully managed device. Show device > Actions > Wipe resets the device to factory settings; enroll it again afterward. Sophos lists the Add device wizard, Sophos Fusion Self Service Portal, QR code and zero-touch enrollment as possible methods. Perform this action only with separate authorization.
Personal, currently Device Administrator → Android Enterprise: work profile management. Show device > Actions > Unenroll, then Actions > Delete; only after that, enroll a new work profile. Sophos lists the Add device wizard or Sophos Fusion Self Service Portal. This action also requires separate authorization. A factory reset is not the standard BYOD step.

The German-language Sophos help dated September 22, 2026 uses Gerät anzeigen > Aktionen > Zurücksetzen, Deregistrieren and Löschen; an English-language console uses Show device > Actions > Wipe, Unenroll and Delete. Check the actual menus, permissions and available enrollment methods in the target tenant beforehand. A Sophos Fusion Wipe, a Mobile Admin Zurücksetzen (reset) and removal of an existing work profile are not interchangeable names or migration steps. Existing corporate-owned devices with a work profile and other modes need a separate decision; do not assign them automatically using these two branches.

Stop before any destructive action

Corporate device: Obtain written authorization for the factory reset of this specific device; check local data, business accounts, apps, authentication, a usable backup and restoration. A scheduled reset destroys local data that has not been backed up. A working Android Enterprise reenrollment path, Wi-Fi or cellular access, required credentials and permissions must be ready. Check Google accounts and reset locks for the specific device and reset route in advance. Sophos documents Factory Reset Protection for fully managed Android Enterprise devices; that does not establish that the same FRP configuration governed the legacy Device Administrator reset. Do not promise an FRP bypass.
Personal device: Agree on consent, the distinction between personal and business data, and the effects of legacy unenrollment with the user. Legacy unenrollment deactivates the Sophos Mobile Control device administrator, removes server credentials and received data, and resets Sophos Intercept X for Mobile. Confirm unenrollment first, then delete the associated record; a pending task or a vanished console record does not prove removal on the device. If a work profile is subsequently set up, removing it deletes its apps and local data; it does not restore the old profile. Do not promise that personal data has been preserved without checking the device.
Offline, unknown state or locked device: Do not mark the operation complete or trigger a second delete or reset on a hunch. Work with the user and Sophos/device support to establish the actual device state, whether the task was delivered, and an authorized recovery path. A cloud task is not proof of execution.

Before making changes, where Restrictions are configured, record the actual device and SD-card encryption state and a permitted, demonstrably usable backup and recovery path. Requested SD-card encryption may have been cancelled on some legacy devices; assignment does not prove the actual state. According to the legacy source, disabling Allow backup disables Google backup, not every alternative backup method. USB/MTP restrictions may prevent the required file-transfer method. Do not relax restrictions on a hunch. Allow factory reset concerns resets initiated by the user; it establishes neither authorisation nor feasibility of a separately authorised console Wipe.

Inventory the legacy policy; do not use it as an Android Enterprise template

The Android device policy applies to the legacy Device Administrator mode. Android Enterprise full device and Android Enterprise work profile each have separate policy families. Before approval, prepare a documented source-to-target matrix for all 14 legacy subconfigurations; record the target mode, supported new setting or explicit lack of a replacement, OS/OEM/license, test, effects and recovery path for each entry:

Include the following areas in this matrix. Record existing values, not new Device Administrator configurations to create. Leave a missing replacement visible as an unresolved decision; similarly named target options do not prove equivalent effects.

Connections and certificates

For each existing APN configuration, also inventory these fields:

User-friendly name, the additional name displayed on the device; the two Server entries separately as the HTTP server for web traffic and the WAP gateway, plus the web server’s Port.
User name and the User password dependency using only an access-controlled identity reference and a secure secret reference; MMSC (Multimedia Messaging Service Center), MMS proxy server and MMS proxy port separately for the MMS route.
Authentication type for PPP authentication, APN type for data connection types, Bearer for radio access technology, and Protocol and Roaming protocol for the carrier’s home-network and roaming protocols.

All legacy fields except APN are optional; explicitly mark unused fields as unconfigured rather than filling them with guessed values. For APN type, * or an empty field means all data types. Only one APN configuration can use Use as default APN. These meanings explain the old state, not how to create a new legacy APN. Map every used value to a separately supported target replacement or an explicitly missing replacement, and confirm carrier acceptance for the target SIM/subscription separately. The independent recovery connection remains necessary.

For APN, record the existing access point, carrier and SIM or subscription in use. Confirm with the carrier that it accepts this APN for the intended subscription. Also record and check the existing Mobile Country Code (MCC) and Mobile Network Code (MNC): these values restrict use of the legacy APN to the specified carrier. An incorrect Use as default APN can cut off cellular data. Preserve the carrier settings and an independent connection before making changes; do not change the default APN as an experiment.

For Wi-Fi and VPN, record legacy Wi-Fi/EAP certificates, SSIDs and VPN types, and test target connectivity separately; WEP is not a secure target standard. Also test management check-in through an independent connection.

For every existing Wi-Fi configuration, record the following legacy values in the matrix:

SSID and the actual Security type: None, WEP, WPA/WPA2 PSK, EAP/PEAP, EAP/TLS or EAP/TTLS. None and WEP are not recommended target options. The legacy description excludes policy assignment to Android 12 and later when WEP is used; this historical condition does not provide an enrolment path in the legacy management mode.
Phase 2 authorization only for EAP/PEAP and EAP/TTLS: record the existing selection, None, PAP, CHAP, MSCHAP or MSCHAPv2. Do not add such a legacy value for EAP/TLS.
For EAP, map Identity and Anonymous identity separately. The latter is the pseudonym sent unencrypted in phase 1 of EAP negotiation. For Password, document the existing Wi-Fi password dependency and the secure storage or replacement provisioning path, not the password itself.
Record Proxy host as the name or IP address of the proxy for this Wi-Fi connection, and record Proxy port separately. A Global HTTP proxy is not a proven equivalent replacement for this connection-specific proxy.

For every existing VPN configuration, record Connection name (the name visible on the device), Server (the gateway’s hostname or IP address) and the actual Connection type. The legacy description distinguishes the following dependencies:

L2TP/IPsec (PSK): Document the user association under User and the password dependency under Password separately from the pre-shared authentication key in the L2TP/IPsec (PSK) field.
L2TP/IPsec (certificate): Record the selected Client certificate and Root certificate, as well as User and the Password dependency. In this legacy branch, certificate selection does not replace the user/password dependency.
Cisco AnyConnect: Inventory the existing VPN profile XML and NVM profile XML (Network Visibility Module) separately, each with its owner, version and a reference to its secure storage location; mark an absent profile as missing. Do not infer automatic XML import or equivalent network visibility in the target.

Record identity bindings only in the access-controlled migration log. For passwords, PSKs and private keys, include only references to secure storage/provisioning; do not include secrets or sensitive real identities in public evidence. Map every Wi-Fi legacy value in use and every VPN dependency to a separately verified target replacement, or explicitly document its absence. For VPN, check app, OS, gateway and authentication support rather than inferring it from the legacy connection type. Check target field meanings, certificate roles and VPN app configuration in the linked Android connectivity article; the following certificate checks are still required.

Record Client certificate, Root certificate and SCEP separately. Legacy client certificates and trust anchors are tied to the policy; SCEP requires the SCEP server’s CA as a root-certificate configuration. Verify target identity, issuance/renewal, CA trust and Wi-Fi/VPN authentication afresh; never disable certificate validation as a troubleshooting measure.

Under the legacy Android device policy, the root certificate configured in Root certificate was installed on the device when the policy was assigned. For the legacy inventory, document the configured X.509 certificate file and its PEM or DER encoding. Each additional root certificate required a separate Root certificate configuration, so include every existing root configuration individually in the source-to-target matrix. The old assignment alone proves neither the actual certificate state of the specific device nor automatic transfer to Android Enterprise.

For every existing Root certificate configuration, also record the legacy policy and the other configurations within that same policy that actually use this root certificate, including Wi-Fi/EAP server trust where present. Distinguish server trust from client identity and the SCEP server’s CA. Map each dependency to the selected target policy and target mode, or document the lack of a supported replacement. In the authorised target pilot, verify the expected server identity, CA trust and connectivity/authentication; do not assume automatic transfer.

For interpreting legacy SCEP fields only: URL could be bound through %_SCEPPROXYURL_% to the server URL on the SCEP tab of the Sophos setup page; Challenge could refer through %_CACHALLENGE_% to the challenge URL configured there. After placeholders are replaced with actual data, Subject must be a valid X.500 name. The legacy SAN choices mean: RFC 822 name = a valid email address; DNS name = the CA server’s DNS name; Uniform resource identifier = the CA server’s fully qualified URL. Record configured and unconfigured fields and the actual resolved identity in the access-controlled inventory; for secrets, use only secure storage/provisioning references. This is not an instruction to provision the legacy mode anew or reuse challenge secrets. Neither infer target SAN meanings from this nor copy these old CA-related meanings into a new client identity.

For every existing SCEP configuration, record the following dependencies with the responsible PKI/MDM team without changing legacy entries to obtain the information:

Certificate retrieval: Document the server and challenge endpoints, their dependencies and, where applicable, variable bindings resolved through setup. Do not include challenge passwords or other secrets in the log or article.
Identity and selection: Record the legacy alias or selection reference, user/device association, Subject expression and resolved name, and configured SAN types/values and AD-UPN. Explicitly mark unconfigured fields as absent. In the pilot, compare these with the required service identity and actual target certificate selection; leave unsupported mappings unresolved.
Trust binding: Unambiguously identify the root certificate actually selected in the current legacy policy, using its fingerprint if needed. Check SCEP server trust separately from trust in the issued client certificate and trust in the service’s server. Do not remove a trust anchor that is still needed before observing successful target acceptance.
Key and purpose: Record the existing Key size, the CA’s compatibility requirement and the separate selections/purposes for digital signature and encryption. Clarify target requirements with the PKI team and the service using the certificate, and check the issued certificate and its required use in the pilot. Neither enable both purposes indiscriminately nor automatically carry over the legacy key value.

Independently check the supported target certificate-retrieval path, certificate roles and intended uses against the Android connectivity guide and the certificate/SCEP runbook linked there. These target guides replace neither the inventory nor verification of the actual effects in the target.

Additionally, identify the existing Client certificate unambiguously through a secure reference to the actual PKCS #12 (.pfx) file and the Certificate name read from it. In the certificate inventory, record which configurations within the same legacy policy select it. Other legacy policies required separate uploads; this is a legacy dependency, not an instruction to provision the legacy mode anew. Do not publish or export a private key or assume automatic target transfer.

Apps, permissions and the app password

Restrictions app filter: Record Filter type separately from App Control: document Allowed apps or Forbidden apps, the associated app group and its members, and the apps actually affected. According to the legacy source, apps installed through Sophos Mobile are exempt from this filter; the App Control launch block is therefore not a proven replacement. The legacy source also states that blocking the native browser does not affect third-party browsers. Verify the target scope and actual effects separately for the required app/browser protection objective.
App Control: Document the selected legacy app group and its members. This block prevents launching, including manufacturer apps that cannot be uninstalled; it does not remove the apps. For each blocked app, record the target mode and new group assignment. This establishes neither automatic Play Store migration nor a block on personal apps in the target mode.
App permissions: For each legacy app, record its exact identity and every configured runtime permission with its value: Selectable means the user can change it, Granted grants it and Denied denies it. For each app and permission, map the target mode, target app, intended effect and permitted user changes, or identify the lack of a replacement. In work profiles on Android 12 and later, location, camera, microphone, body sensors and physical activity permissions can be denied on the user’s behalf, but not granted. Account for this limit in the target decision.
App Protection: Record the legacy app group and its members, Password complexity, Grace period in minutes and Allow fingerprint authentication. All protected apps share one password, which the user sets when first opening any of them. During the configured grace period after a protected app is closed, protected apps can be opened without another password prompt. Fingerprint authentication is a possible alternative to the app password. Other apps/system functions or multi-window mode can bypass the legacy protection; it does not establish equivalent corporate protection. Compare the supported settings for fully managed devices and work profiles independently.

Email account and user handoff

For Email account, check the mail app, Exchange cloud, supported OAuth sign-in and actual mail flow separately. A legacy password field or Allow all certificates is not an Exchange Online fallback. Alongside the server, certificates and user assignment, record the following legacy values:

Account label, route, transport and content

Record existing Account name and actual Server name; distinguish a direct Exchange endpoint from an EAS proxy URL. outlook.office365.com applies to the worldwide Microsoft 365 cloud, not universally to other Microsoft clouds. Observe the actual approved mail route rather than replacing it without verification.
Record resolved Email address and Sender independently of User; %_EMAILADDRESS_% is replaced by the actual email address in both fields. Identity data stays in the access-controlled log.
For Password, record only the secure storage/provisioning reference and existing dependency: an empty legacy field required the user to enter the password on the device. This is not a recommendation for a password fallback instead of supported OAuth.
Record existing SSL/TLS and Allow all certificates states, selected Client certificate and Synchronize content types. The legacy bypass option is not a safe target value. Map every used mail field to a supported target effect or an explicitly missing replacement. In the authorized target pilot, verify actual account/sender and server identity, TLS trust and the selected synchronized content using harmless data; use neither a password fallback nor a certificate bypass.

Identity in the legacy account and the target

First record the legacy User value and the sign-in name it actually resolves to. For the placeholders %_USERNAME_% and %_EMAILADDRESS_%, the assigned user’s Exchange Login and Email Address fields must be populated in Sophos Fusion. The legacy source generally specifies %_EMAILADDRESS_% for Exchange Online and %_USERNAME_% for Exchange Server. The email address and actual sign-in name are still not automatically identical.

Also record Domain. According to the legacy description, this field is empty for Exchange Online and contains the user account’s domain for Exchange Server. These details explain the identity used by the legacy account. Before approval, compare the resolved legacy values and user assignment with the selected target identity. Check how the username and domain are represented in the target; supported authentication must be checked separately as described above.

Setup on the legacy device

Document the OEM/API and whether account setup was automatic or manual. The legacy description lists LG GATE, Samsung Knox and Sony Enterprise API for automatic setup. On other devices, the user had to configure the mail app using the configuration details in Sophos Mobile Control. Plan a separate user handoff and app pilot for the target client rather than repeating the old setup.

Synchronization and default account

Record Synchronization interval as the time between synchronizations, separately from Synchronization period, the age of messages included. Document the target mechanism for retrieval frequency or the lack of a replacement. Also record Default account and establish how the target app selects the default account or whether a managed setting is unavailable.

Data flow, format and message size

For Allow forwarding emails and Allow use of HTML format, record the existing values and previous decisions about business needs and privacy. For both settings, document whether the target app or Exchange can enforce them. Otherwise, explicitly identify the lack of a replacement.

Record the value of Maximum attachment size in MB exactly. Despite the field name, Sophos describes it as the maximum size of a single email message, not explicitly just an attachment. Check separately which effect matters operationally and which limit the target app or Exchange applies.

Legacy Sony exception

The German source specifies Enterprise API Level 6.x or earlier, while the English source specifies Level 6 or earlier. On affected devices, the Exchange account information must match the assigned user. Mobile Control cannot transmit the ActiveSync ID there. At the first EAS proxy contact, the proxy therefore looks for a device with an unknown ActiveSync ID and a matching user assignment. If it finds one, it associates the ID sent by the mail client and forwards the request; otherwise, it rejects it. Check the API version, assigned user and actual client identity before approving the legacy account. Observe the existing authorized mail path without resetting identities or bypassing access controls. Verify the target path separately; do not apply this legacy condition to Android Enterprise Gmail.

Kiosk and authorized exit

For Kiosk mode, record the existing Select source value (Custom, App list or No app), exact App ID, actual installation, assignment status and device state. For App list, document the selected Android app entry already added to Sophos Mobile and, before mapping it to the target, compare its resolved package identity with App ID and the app actually installed. If the configured kiosk app is missing when the legacy policy is assigned, the policy-assignment task remains Incomplete / Unvollständig until the app is installed. For this legacy status, check identity and installation first; a reset is not speculative troubleshooting. No app, by contrast, means the restrictions are transferred but no app launches. Do not equate this with a missing package or an Enterprise option named None.

Unless device functions are disabled, the user can leave the legacy kiosk app and use the device normally; selecting an app alone does not prove confinement. In particular, document the existing states of Allow Home button and Allow task manager, along with authorized physical or alternative administrator access. Check the kiosk app, launch behavior and exit before reset, and verify them separately for the target mode.

For Sony Enterprise API Level 9 or later, the legacy source states that disabling even one of Allow volume up, Allow volume down or Allow volume mute disables all volume buttons. Record the affected model, API level and legacy state. In the authorized target pilot, check which audio and button controls are supported for this model and the selected management mode. Test the required audio and buttons on the device rather than assuming the legacy behavior carries over.

Knox Premium, boot protection and administrator apps

Record the existing Allow firmware auto update options value, its responsible owner and device/license support. The legacy option makes the device automatically check for firmware updates; the user cannot change this in device settings. It does not mean that every firmware update is installed automatically. Record the supported target replacement or its absence separately, and observe actual target update behavior in the authorized pilot without enabling legacy options anew.

Legacy Knox Premium restrictions affect the Samsung Knox device, not the Knox container. Enforcement requires a Samsung Knox Premium license registered in Sophos Mobile. Check the device type, license registration and actual device effect separately. For the selected Enterprise target mode, establish independently which license is required and which device effects are supported; the legacy license registration does not prove transfer.

Record the existing state of Enable ODE Trusted Boot verification. According to the legacy description, the data partition is decrypted at startup only with an official binary and kernel. Establish data access and an authorized recovery path before restarting or resetting; do not disable verification as a migration or recovery shortcut.

Record Prevent installation of another administrator app and Prevent activation of another administration app separately. The first legacy option prevents installation of apps with device administrator privileges, except apps installed by Sophos Mobile; the second prevents activation of those privileges. Check the actual impact on required apps and the intended enrollment path beforehand without broadly relaxing the blocks.

If Allow Common Criteria mode is present, also record all six legacy prerequisites:

Device encryption enabled;
Fast encryption disabled;
External storage encryption enabled;
Failed-attempt threshold for a device wipe set;
Certificate revocation enabled;
Password history disabled.

According to the legacy source, CC Mode is not applied without these prerequisites. These are dependencies of the starting configuration, not instructions to enable legacy options anew or weaken password protection in the target. Do not test failed-attempt wipes on production devices. Check current support, the target replacement and recovery separately in the authorized pilot; the legacy description is not evidence of current certification.

Screen lock and restrictions

For the existing screen lock under Password policies, record Password type and its legacy meaning: Pattern, PIN or password requires a screen lock without additional restrictions; Simple password requires a password with at least one letter, with digits permitted; PIN or password permits those two lock types. Alphanumeric password and Complex password require a password containing letters and digits. Only Complex password adds the six minimum composition requirements listed below. This describes the source policy, not how to create a new legacy policy or identical Android Enterprise behaviour.

For Simple password, PIN or password, Alphanumeric password and Complex password, also record the values present for each: Minimum password length (total number of characters), Maximum idle time before password prompt (configured inactivity period; the device may enforce a shorter period), Maximum password age in days (change interval; legacy range 0–730 days, with 0 meaning no change is required), Maximum sign-in attempts (failed attempts before the legacy device wipe) and Password history (number of previous passwords stored that must not be reused). Do not invent values for fields absent from the selected type. Before approval, document the supported target effect or explicit lack of support, OS/OEM and selected device or work profile lock for the type and every field; do not automatically carry over legacy values.

For Password policies, record all six minimums separately for an existing Complex password: letters, lowercase letters, uppercase letters, non-alphabetic characters, digits and special characters. Non-alphabetic characters and special characters are separate legacy values, not a combined requirement. Compare each value with the selected fully managed device mode, device lock or work profile lock, and the OS/OEM applicability labels. For each minimum, document the supported replacement or its absence and enforcement observed without destructive testing.

Also record Allow fingerprint authentication and Allow iris authentication, including their existing selections. The legacy unlock methods apply only on devices that support them. Check availability and the unlock methods actually permitted in the target mode separately by OS and OEM. App Protection fingerprint access or Weak biometric recognition does not establish an identical replacement.

For Password policies and Restrictions, check recovery, backup and the OS/mode-specific effects of every relevant block and restriction; do not assume the same effects on personal and corporate devices. A failed-sign-in threshold can wipe the device; do not test it on production devices.

For the Restrictions actually in use, complete the matrix down to each relevant setting: legacy value, effect observed on the device, business protection objective, OS/OEM and parent/child dependencies, supported target replacement or explicit deviation with approval. In particular, cover data sharing and recording, wireless/sharing and peripheral use, connectivity/emergency communications/roaming, updates/recovery, accounts including Google account removal, and app installation sources and uninstallation. Exclude unused or inapplicable settings with a reason. Do not assess restrictions by name alone: according to the legacy source, a video-recording prohibition permits photos and streaming; the shared clipboard requires Allow clipboard. Where Bluetooth is used, also check existing pairings and profiles; for tethering or the lock-screen camera, check the parent option too. Record relevant SD/USB child values together with their parent options as well. A legacy Beam restriction does not control Quick Share. In the authorised target pilot, verify required functions and prohibited data flows using harmless test data; if a replacement is missing or the effect differs, stop the rollout until the decision is documented.

The historical child pages describe source settings, some dating from 2022–2023; they do not establish current support for legacy protocols or OEM features on target devices. These areas show which dependencies to check before migration. Check both complete target policy families and your own tenant before making specific policy recommendations. The separate KB topics on fully managed device policies, work profile policies, Android connectivity, BYOD and FRP do not replace migration approval. The article on Exchange migration also covers mail authentication.

Pilot, stop conditions and recovery

Only after ownership, tenant and licensing have been clarified and an authorized recovery path established, pilot on expendable, representative devices for each mode. First back up device data and existing policies, and prepare the new policy and enrollment method separately. During the pilot, confirm the task on the device, check the new management mode and actual assignment, and observe apps, account sign-in/mail flow, kiosk operation (if applicable), Wi-Fi/VPN, certificate issuance and renewal, and personal data after a BYOD transition. Decide whether to proceed with other devices only after verifying the effects.

Record specific expected and observed results for the inventoried legacy values during the pilot:

Cellular connectivity

With the intended SIM on the intended carrier, test cellular data access separately from the independent recovery/management connection tested earlier. Then check management check-in. If data access fails, do not migrate further devices; use the independent connection and escalation path authorized in advance.

Apps and permissions

First check the launch behavior of every previously blocked app, along with required operational and emergency apps. Then use test data to check each target app and its runtime permissions. Compare the expected state with actual app functionality when a permission is granted or denied. Also check whether the user can change the permission as intended or is prevented from doing so. Account for the Android 12 work profile limits.

Before a change, log the settings and assignment. Use only the supported update or replacement path tested beforehand. If a policy change must be reversed, confirm synchronization and repeat the same permission checks.

Do not grant permissions indiscriminately just to make an app work. Revoking access later does not recover data already disclosed.

App password and screen lock

In the target, check the expected password prompt, permitted alternative access, grace period without another prompt and authentication. For the device or work profile lock, check the individual minimum requirements and available biometric methods without destructive testing or exhausting the failed-attempt threshold.

For the selected target lock, compare permitted lock types and total length with the documented decision, and observe the actual inactivity period before the password prompt, including any shorter device limits. Where supported, check password-change and reuse behaviour on an authorised test account/device or using supported status evidence; explicitly record missing support. On production devices, do not accelerate password changes, weaken protection or exhaust failed attempts. Keep the prepared recovery path available and stop the rollout if results differ from expectations.

Mail

Using an authorized test account and harmless content, check delivery time, the default account when composing, permitted/prohibited forwarding, HTML behavior and relevant message sizes. Do not use real confidential data. Compare the results with the documented target decision, even if a previously managed setting is absent in the target.

Stop when results differ

Stop the rollout if results differ from expectations. A visible target configuration alone is not enough; first establish the cause, supported replacement and safe recovery path.

If connectivity is lost, the state of the data is unclear, the device or mode is wrong, sign-in fails, or a reset lock appears, stop and escalate. Identify the responsible support contact, a working independent connection and a reprovisioning path before acting. Rollback cannot undo a factory reset or a deleted work profile: Recovery is possible only from demonstrably usable backups and through authorized reenrollment; neither immediate remote task delivery nor identical policy effects have been established. Without tenant and device testing, this is not a production migration procedure or a guarantee of success.