Sophos Mobile: migrar del administrador de dispositivos de Android a Android Enterprise

Este artículo ayuda a definir la ruta de migración y las comprobaciones necesarias. No autoriza ningún restablecimiento en producción. Sophos considera obsoleto el modo de administrador de dispositivos: en Sophos Mobile solo está disponible para Android 9 o versiones anteriores; los dispositivos con Android 10 o posterior no pueden inscribirse en ese modo. Esto no significa que todas las funciones de Android Device Policy Manager hayan desaparecido en general ni recomienda seguir usando Android 9. No inscriba dispositivos nuevos en el modo antiguo. La migración descrita a continuación presupone que el entorno de Android Enterprise ya está preparado y configurado.

Determine primero la titularidad y el modo de destino

Antes de cualquier cambio, coteje el modo de gestión real, la identidad y titularidad del dispositivo, la versión de Android, el usuario asignado, las políticas, las aplicaciones, la conectividad y el último estado del dispositivo, tanto en el propio dispositivo como en el tenant de Sophos correcto.

Prepare la nueva inscripción antes de intervenir

Esta comprobación se realiza mientras el dispositivo antiguo sigue gestionado. No inicia ningún restablecimiento ni cancelación de la inscripción. Registre en el protocolo de migración los siguientes datos para el modo de destino elegido:

En Sophos Fusion > My Products > Mobile > Setup > Google setup > Android Enterprise, compruebe el Android Enterprise mode existente, los detalles de la cuenta que se muestran y el estado de Use managed Google domain device enrollment. Reutilice el registro existente de la organización; no vuelva a ejecutar Register account ni sustituya la vinculación con Google. Si falta la vinculación o no está clara, aclárela primero siguiendo el apartado Vincular la organización con Google.
Prepare una Android Enterprise device policy para el dispositivo de empresa y una Android Enterprise work profile policy para el dispositivo personal. Anote los nombres de la política de destino y del paquete de tareas asociado. El paquete para cada tipo de dispositivo debe contener, como mínimo, Enroll y Assign policy con esa política exacta. Una política antigua de administrador de dispositivos no sirve como sustituto.
Si utiliza el portal de autoservicio, abra en Setup > Self Service Portal la configuración efectiva para el usuario. En los ajustes de la plataforma Android, Enrollment package debe apuntar al paquete de tareas preparado. Coteje Owner, el Device group de destino, la prioridad del grupo y la cuota de dispositivos restante. Compruebe la configuración existente que corresponda; no cree una nueva ni cambie Default de forma indiscriminada. La preparación se describe en Preparar la política, el paquete y la identidad del usuario.
Compruebe que Sophos Mobile Control esté aprobado en Managed Google Play. Sin esta aprobación, la aplicación gestionada no se actualiza automáticamente. Si está activada la inscripción de dispositivos mediante el dominio, los usuarios previstos deben existir en el dominio de Google gestionado. Esta inscripción mediante el dominio requiere Mobile Control 9.8 o posterior; para los perfiles de trabajo, además deben estar instaladas todas las actualizaciones disponibles del sistema operativo y de las aplicaciones. En una tarea iniciada desde Sophos Mobile, el correo electrónico asignado debe coincidir exactamente con el utilizado para iniciar sesión en Google.
Elija una vía de inscripción permitida en el modo actual de la organización y prepare de antemano con el equipo de TI responsable las instrucciones que se entregarán al usuario. Si la organización se registró antes del 9 de abril de 2024 en el modo managed-Google-domain y no tiene activada la inscripción de dispositivos mediante el dominio, la inscripción por el administrador no está disponible; en ese caso, prepare la vía SSP permitida. No active esa opción como un paso incidental de la migración. Los cambios en la vinculación de la organización o en el modo de inscripción requieren una autorización propia.

Para un dispositivo de empresa con un usuario asignado, la guía de Android Enterprise, en «piloto de administrador» describe la vía compatible mediante el asistente: Devices > Add > Add device wizard, selección del usuario, Platform: Android y el paquete de inscripción preparado. Ejecute esta vía solo después de que el restablecimiento de fábrica se haya autorizado por separado y se haya confirmado en el dispositivo. Si es necesario usar SSP, siga el procedimiento SSP descrito allí. Los métodos QR, Zero-touch y sin usuario son alternativas que requieren su propia preparación, no pasos obligatorios adicionales.

Para un dispositivo cuya titularidad personal esté comprobada, prepare de antemano el apartado Configurar el perfil de trabajo de la guía de Android BYOD para entregar las instrucciones al usuario. Este apartado explica Owner: Personal, el paquete de perfil de trabajo y la configuración de Mobile Control en el dispositivo. Esta nueva inscripción solo comienza tras confirmar la cancelación de la inscripción antigua y eliminar después la entrada antigua correcta. También debe realizarse la comprobación de privacidad y consentimiento del apartado «Antes de la inscripción»; el procedimiento BYOD no se aplica a dispositivos de empresa con perfil de trabajo.

Si falta cualquiera de estos requisitos, deténgase antes de iniciar cualquiera de las dos vías de migración. Antes de intervenir en producción, pruebe la vía elegida en un dispositivo de prueba representativo y autorizado. Tener las cuentas preparadas, un paquete guardado u opciones visibles en el portal no demuestra que la inscripción del dispositivo se haya completado correctamente. Tras la inscripción, compruebe el modo de gestión, el usuario asignado, el estado de las tareas y la política efectiva en Sophos Mobile y en el dispositivo.

Vías de migración documentadas

No mezcle las dos vías documentadas:

Propiedad de la empresa, hasta ahora en modo administrador de dispositivos → Android Enterprise: gestión completa del dispositivo. En Gerät anzeigen > Aktionen > Zurücksetzen, el dispositivo se restablece a los valores de fábrica; después debe volver a inscribirse. Sophos menciona como posibles vías el asistente «Gerät hinzufügen», el portal de autoservicio de Sophos Fusion, los códigos QR y la inscripción Zero-Touch. Ejecute esta intervención solo con una autorización específica.
Personal, hasta ahora en modo administrador de dispositivos → Android Enterprise: gestión del perfil de trabajo. En Gerät anzeigen > Aktionen > Deregistrieren y después Aktionen > Löschen; solo entonces vuelva a inscribir el perfil de trabajo. Sophos menciona el asistente «Gerät hinzufügen» o el portal de autoservicio de Sophos Fusion. Esta intervención también requiere una autorización específica. No haga un restablecimiento de fábrica como paso habitual para BYOD.

Estos nombres proceden de la ayuda de Sophos en alemán del 22 de septiembre de 2026; en una consola configurada en inglés figuran Show device > Actions > Wipe, Unenroll y Delete. Compruebe de antemano los menús concretos, los permisos y las vías de inscripción disponibles en el tenant de destino. Un Wipe de Sophos Fusion, un Zurücksetzen de Mobile Admin y la eliminación de un perfil de trabajo ya configurado no son nombres ni pasos de migración intercambiables. Los dispositivos de empresa que ya tienen un perfil de trabajo y otros modos requieren una decisión aparte: no los asigne automáticamente a una de estas dos vías.

Deténgase antes de cualquier acción destructiva

Dispositivo de empresa: Obtenga autorización por escrito para ese dispositivo concreto y su restablecimiento de fábrica; compruebe los datos locales, las cuentas corporativas, las aplicaciones, la autenticación y que tanto la copia de seguridad como la restauración sean viables. Un restablecimiento planificado destruye los datos locales que no estén respaldados. Deben estar disponibles una vía de reinscripción en Android Enterprise que funcione realmente, acceso por Wi-Fi o datos móviles y las credenciales y permisos necesarios. Compruebe previamente las cuentas de Google y los bloqueos tras el restablecimiento para el dispositivo y la vía de restablecimiento específicos. Sophos documenta Factory Reset Protection para dispositivos Android Enterprise totalmente gestionados; de ello no se deduce que esa misma configuración de FRP controlase ya el restablecimiento en el antiguo modo de administrador de dispositivos. No prometa eludir FRP.
Dispositivo personal: Aclare con el usuario su consentimiento, qué datos personales y corporativos hay y qué efectos tendrá la cancelación de la inscripción antigua. La cancelación de la inscripción antigua desactiva el administrador de dispositivos de Sophos Mobile Control, elimina las credenciales de acceso al servidor y los datos recibidos, y restablece Sophos Intercept X for Mobile. Primero confirme la cancelación de la inscripción y solo después elimine la entrada correspondiente; ni una tarea pendiente ni la desaparición de una entrada de la consola demuestran que la gestión se haya retirado del dispositivo. Si posteriormente se elimina el perfil de trabajo configurado, se pierden sus aplicaciones y datos locales: no se recupera con ello el perfil antiguo. No garantice que los datos personales se conservarán sin comprobar el dispositivo.
Dispositivo sin conexión, con estado desconocido o bloqueado: No dé la operación por terminada ni envíe por sospecha una segunda orden de eliminación o restablecimiento. Aclare con el usuario y con el soporte de Sophos o del dispositivo el estado real de este, la entrega de la orden y la vía de recuperación autorizada. Una orden enviada desde la nube no prueba que se haya ejecutado.

Antes de intervenir, si existen Restrictions, registre el estado real del cifrado del dispositivo y de la tarjeta SD, así como una vía de copia de seguridad y restauración permitida y cuya utilidad esté comprobada. En algunos dispositivos antiguos, el cifrado solicitado de la tarjeta SD puede haberse interrumpido; la asignación no demuestra el estado real. Según la fuente antigua, desactivar Allow backup deshabilita la copia de seguridad de Google, no todas las alternativas de copia de seguridad. Los bloqueos de USB/MTP pueden impedir la transferencia de archivos necesaria. No flexibilice bloqueos por sospecha. Allow factory reset afecta al restablecimiento que realiza el usuario; no deduzca de esa opción ni la autorización ni la viabilidad del Wipe desde la consola, que requiere una autorización aparte.

Use la política antigua solo como inventario, no como plantilla de Android Enterprise

La política de dispositivos Android se aplica al antiguo modo de administrador de dispositivos. Android Enterprise full device y Android Enterprise work profile tienen familias de políticas propias. Antes de autorizar la migración, elabore una matriz documentada de origen y destino para las 14 subconfiguraciones antiguas; anote en cada fila el modo de destino, la nueva opción compatible o la ausencia expresa de equivalente, el sistema operativo/OEM/licencia, la prueba, los efectos y la vía de recuperación:

Los siguientes ámbitos de comprobación deben incluirse en esa matriz. Registre los valores existentes, no configuraciones nuevas de administrador de dispositivos. Si no hay un equivalente, deje visible esa decisión pendiente; que las opciones de destino tengan nombres parecidos no demuestra que surtan el mismo efecto.

Conexiones y certificados

Para cada configuración APN existente, inventaríe también estos campos:

User-friendly name, el nombre adicional mostrado en el dispositivo; las dos entradas Server por separado como servidor HTTP para tráfico web y pasarela WAP, más el Port del servidor web.
User name y la dependencia de User password, solo mediante una referencia de identidad con acceso restringido y una referencia segura al secreto; MMSC (Multimedia Messaging Service Center), MMS proxy server y MMS proxy port por separado para la ruta MMS.
Authentication type para la autenticación PPP, APN type para los tipos de conexión de datos, Bearer para la tecnología de acceso radio y Protocol y Roaming protocol para los protocolos del operador en la red de origen y en itinerancia.

Salvo APN, los campos antiguos son opcionales; marque los no utilizados como no configurados, sin rellenarlos con valores supuestos. En APN type, * o un campo vacío significa todos los tipos de datos. Solo una configuración APN puede usar Use as default APN. Estos significados explican el estado antiguo, no cómo crear un nuevo APN heredado. Asigne cada valor utilizado a un sustituto de destino cuya compatibilidad se haya comprobado por separado o indique expresamente su ausencia, y confirme con el operador la aceptación para la SIM/suscripción de destino. Sigue siendo necesaria una conexión independiente de recuperación.

Para APN, registre el punto de acceso anterior, el operador y la SIM o suscripción utilizada. Confirme con el operador si acepta ese APN para la suscripción prevista. Registre y coteje también los valores existentes de Mobile Country Code (MCC) y Mobile Network Code (MNC): estos limitan el uso del APN antiguo al operador indicado. Un Use as default APN incorrecto puede cortar los datos móviles. Por eso, antes de intervenir, conserve los valores del operador y asegure una conexión independiente; no cambie el APN predeterminado para probar.

Para Wi-Fi y VPN, registre los certificados anteriores de Wi-Fi/EAP, el SSID y los tipos de VPN, y compruebe por separado el acceso de destino; WEP no es un estándar seguro para el destino. Pruebe también la comunicación con la plataforma de gestión mediante un acceso independiente.

Para cada configuración Wi-Fi existente, incluya los siguientes valores antiguos en la matriz:

SSID y el Security type real: None, WEP, WPA/WPA2 PSK, EAP/PEAP, EAP/TLS o EAP/TTLS. None y WEP no son recomendaciones para el destino. La descripción antigua excluye la asignación de políticas con WEP a Android 12 o posterior; esta condición histórica no habilita ninguna vía de inscripción en el modo de gestión antiguo.
Phase 2 authorization, solo para EAP/PEAP y EAP/TTLS: registre la opción existente, None, PAP, CHAP, MSCHAP o MSCHAPv2. No añada un valor antiguo de este campo para EAP/TLS.
Para EAP, documente por separado las correspondencias de Identity y Anonymous identity. Esta última es el seudónimo que se envía sin cifrar en la fase 1 de la negociación EAP. Para Password, documente la dependencia de la contraseña Wi-Fi existente y la vía segura para custodiarla o proporcionar una sustituta, no la contraseña en sí.
Registre Proxy host como el nombre o la dirección IP del proxy de esta conexión Wi-Fi, y Proxy port por separado. No está demostrado que Global HTTP proxy sea un equivalente de este proxy específico de la conexión.

Para cada configuración VPN existente, registre Connection name (nombre visible en el dispositivo), Server (nombre de host o dirección IP de la puerta de enlace) y el Connection type real. La descripción antigua distingue estas dependencias:

L2TP/IPsec (PSK): documente la vinculación con el usuario en User y la dependencia de la contraseña en Password por separado de la clave de autenticación previamente compartida del campo L2TP/IPsec (PSK).
L2TP/IPsec (certificate): incluya los valores seleccionados de Client certificate y Root certificate, además de User y la dependencia de Password. En esta variante antigua, seleccionar los certificados no sustituye la dependencia del usuario y la contraseña.
Cisco AnyConnect: inventaríe por separado el XML del perfil VPN y el XML del perfil NVM (Network Visibility Module) existentes, cada uno con su responsable, versión y referencia a una ubicación segura; indique expresamente si falta un perfil. No deduzca de ello una importación automática de XML ni la misma visibilidad de red en el destino.

Registre las vinculaciones de identidad únicamente en el protocolo de migración con acceso restringido. Para contraseñas, PSK y claves privadas, incluya solo referencias a vías seguras de custodia o suministro; no incorpore secretos ni identidades reales sensibles a evidencias públicas. Asigne cada valor Wi-Fi antiguo utilizado y cada dependencia VPN a un equivalente de destino comprobado por separado, o documente expresamente su ausencia. Para VPN, compruebe la compatibilidad de la aplicación, el sistema operativo, la puerta de enlace y la autenticación; no la deduzca del tipo de conexión antiguo. Compruebe los significados de los campos de destino, las funciones de los certificados y la configuración de la aplicación VPN en el artículo de conectividad de Android enlazado; las siguientes comprobaciones de certificados siguen siendo necesarias.

Registre por separado Client certificate, Root certificate y SCEP. Los certificados de cliente y anclajes de confianza antiguos están vinculados a la política; SCEP necesita la CA del servidor SCEP como configuración raíz. Demuestre de nuevo la identidad de destino, la emisión y renovación, la confianza en la CA y el inicio de sesión en Wi-Fi/VPN; nunca desactive la validación de certificados para resolver problemas.

En la antigua política de dispositivos Android, el certificado raíz configurado en Root certificate se instalaba en el dispositivo al asignar la política. Para los dispositivos antiguos, documente el archivo de certificado X.509 configurado y su codificación PEM o DER. Cada certificado raíz adicional requería su propia configuración Root certificate; por ello, incluya por separado todas las configuraciones raíz existentes en la matriz de origen y destino. La asignación antigua, por sí sola, no demuestra ni el estado real de los certificados en ese dispositivo concreto ni su transferencia automática a Android Enterprise.

Para cada configuración Root certificate existente, registre también la política antigua y las otras configuraciones de esa misma política que realmente utilizan ese certificado raíz, incluida la confianza en el servidor Wi-Fi/EAP, si existe. Distinga la confianza en el servidor de la identidad del cliente y de la CA del servidor SCEP. Asigne cada dependencia a la política y al modo de destino elegidos, o documente la ausencia de un equivalente compatible. En el piloto de destino autorizado, demuestre la identidad de servidor esperada, la confianza en la CA y la conexión o autenticación; no presuponga una transferencia automática.

Solo para interpretar los campos SCEP antiguos: URL podía vincularse mediante %_SCEPPROXYURL_% a la URL del servidor de la pestaña SCEP de la página Sophos setup; Challenge podía hacer referencia mediante %_CACHALLENGE_% a la URL de desafío configurada allí. Tras sustituir los marcadores por los datos reales, Subject debe ser un nombre X.500 válido. Las opciones SAN antiguas significan: RFC 822 name = una dirección de correo electrónico válida; DNS name = el nombre DNS del servidor de la CA; Uniform resource identifier = la URL completamente cualificada del servidor de la CA. Registre los campos configurados y no configurados y la identidad realmente resuelta en el inventario con acceso restringido; para los secretos, utilice solo referencias seguras de custodia/aprovisionamiento. Esto no es una instrucción para volver a aprovisionar el modo antiguo ni reutilizar secretos de desafío. No deduzca de ello los significados SAN del destino ni copie estos antiguos significados relativos a la CA en una nueva identidad de cliente.

Para cada configuración SCEP existente, registre las siguientes dependencias con el equipo responsable de PKI/MDM, sin modificar las entradas antiguas para obtener los datos:

Obtención: Documente los endpoints del servidor y del challenge, sus dependencias y, cuando corresponda, la vinculación de variables resuelta mediante la configuración. No incluya contraseñas de challenge ni otros secretos en el registro ni en el artículo.
Identidad y selección: Registre el alias antiguo o la referencia de selección, la vinculación con el usuario o dispositivo, la expresión Subject y el nombre resuelto, así como los tipos y valores SAN configurados y el AD-UPN. Indique expresamente qué campos no están configurados. En el piloto, compárelos con la identidad que necesita el servicio y con la selección real del certificado de destino; deje pendientes las correspondencias no compatibles.
Vinculación de confianza: Identifique de forma inequívoca el certificado raíz realmente seleccionado en la política antigua actual, mediante su huella si es necesario. Compruebe la confianza en el servidor SCEP por separado de la confianza en el certificado de cliente emitido y de la confianza en el servidor del servicio. No retire un anclaje de confianza que siga siendo necesario antes de observar y validar el funcionamiento en el destino.
Clave y finalidad: Registre el valor existente de Key size, el requisito de compatibilidad de la CA y las selecciones y finalidades separadas de firma digital y cifrado. Aclare los requisitos de destino con el equipo de PKI y el servicio que utiliza el certificado; compruebe en el piloto el certificado emitido y el uso requerido. No active ambas finalidades indiscriminadamente ni adopte automáticamente el tamaño de clave antiguo.

Compruebe de forma independiente la vía compatible de obtención en el destino, las funciones de los certificados y sus finalidades de uso siguiendo el artículo de conectividad de Android y el procedimiento de certificados/SCEP enlazado allí. Estas guías de destino no sustituyen ni el inventario ni la demostración del efecto real en el destino.

Identifique además el Client certificate existente mediante una referencia segura al archivo real PKCS #12 (.pfx) y al Certificate name leído de él. En el inventario de certificados, registre qué configuraciones de la misma política antigua lo seleccionan. Otras políticas antiguas requerían cargas separadas; es una dependencia antigua, no una instrucción para volver a aprovisionar el modo heredado. No publique ni exporte una clave privada ni presuponga su transferencia automática al destino.

Aplicaciones, permisos y contraseña de aplicaciones

Filtro de aplicaciones de Restrictions: Registre el valor de Filter type por separado de App Control: documente Allowed apps o Forbidden apps, el grupo de aplicaciones asociado y sus miembros, y las aplicaciones realmente afectadas. Según la fuente antigua, las aplicaciones instaladas por Sophos Mobile quedan excluidas de este filtro; por tanto, el bloqueo de inicio de App Control no constituye un equivalente demostrado. Según esa misma fuente, el bloqueo del navegador nativo tampoco afecta a los navegadores de terceros. Demuestre por separado el alcance de destino y el efecto real para la protección de aplicaciones o navegadores que se necesita.
App Control: Documente el grupo de aplicaciones antiguo seleccionado y sus miembros. Este bloqueo impide iniciar las aplicaciones, incluidas las del fabricante que no se pueden desinstalar; no las elimina. Para cada aplicación bloqueada, registre el modo de destino y la nueva asignación al grupo. Esto no implica una transferencia automática desde Play Store ni el bloqueo de aplicaciones personales en el destino.
App permissions: Para cada aplicación antigua, anote su identidad exacta y cada permiso en tiempo de ejecución configurado, junto con su valor: Selectable permite al usuario modificarlo, Granted lo concede y Denied lo deniega. Para cada aplicación y permiso, indique el modo de destino, la aplicación de destino, el efecto deseado y si se permite al usuario modificarlo, o señale que no hay equivalente. En los perfiles de trabajo de Android 12 o posterior, se pueden denegar en nombre del usuario los permisos de ubicación, cámara, micrófono, sensores corporales y actividad física, pero no concederlos. Esta limitación debe tenerse en cuenta al decidir la configuración de destino.
App Protection: Registre el grupo de aplicaciones antiguo y sus miembros, Password complexity, Grace period in minutes y Allow fingerprint authentication. Todas las aplicaciones protegidas utilizan la misma contraseña, que el usuario establece al abrir una de ellas por primera vez. Durante el período configurado tras cerrar una aplicación protegida, las aplicaciones protegidas se pueden abrir sin que se solicite de nuevo la contraseña. La huella digital es una posible alternativa a la contraseña de aplicaciones. La protección antigua puede eludirse mediante otras aplicaciones, funciones del sistema o modos multiventana; no implica una protección empresarial equivalente. Compare por separado los ajustes compatibles para la gestión completa del dispositivo y para el perfil de trabajo.

Cuenta de correo e instrucciones para el usuario

Para Email account, compruebe por separado la aplicación de correo, la nube de Exchange, un inicio de sesión OAuth compatible y el flujo real del correo. Ni un campo de contraseña antiguo ni Allow all certificates son una alternativa para Exchange Online. Además del servidor, los certificados y el usuario asignado, incluya en el registro los siguientes valores antiguos:

Nombre de cuenta, ruta, transporte y contenido

Registre Account name y el Server name real; distinga un punto de conexión directo de Exchange de la URL de un EAS proxy. outlook.office365.com corresponde a la nube mundial de Microsoft 365, no universalmente a otras nubes de Microsoft. Observe la ruta de correo realmente autorizada, sin sustituirla a ciegas.
Registre los valores resueltos de Email address y Sender independientemente de User; %_EMAILADDRESS_% se sustituye por la dirección real en ambos campos. Los datos de identidad quedan en el registro con acceso restringido.
Para Password, documente solo la referencia segura de custodia/aprovisionamiento y la dependencia existente: un campo antiguo vacío exigía que el usuario introdujera la contraseña en el dispositivo. No es una recomendación de recurrir a una contraseña en lugar de OAuth compatible.
Registre los estados existentes de SSL/TLS y Allow all certificates, el Client certificate seleccionado y Synchronize content types. La opción antigua de omitir la validación no es un valor de destino seguro. Asigne cada campo de correo utilizado a un efecto de destino compatible o indique expresamente la falta de sustituto. En el piloto autorizado, verifique la identidad real de cuenta/remitente y servidor, la confianza TLS y los contenidos seleccionados para sincronización con datos inofensivos; no use alternativas por contraseña ni omita la validación de certificados.

Identidad de la cuenta antigua y de destino

Registre primero el valor antiguo de User y el nombre de inicio de sesión que realmente se obtiene de él. Para los marcadores %_USERNAME_% y %_EMAILADDRESS_%, el usuario asignado debe tener cumplimentados los campos Exchange Login y Email Address en Sophos Fusion. La fuente antigua indica normalmente %_EMAILADDRESS_% para Exchange Online y %_USERNAME_% para Exchange Server. Aun así, la dirección de correo y el nombre real de inicio de sesión no son automáticamente iguales.

Incluya también Domain en el registro. Según la descripción antigua, el campo se deja vacío para Exchange Online y contiene el dominio de la cuenta del usuario para Exchange Server. Estos datos explican qué identidad utiliza la cuenta antigua. Antes de autorizar la intervención, compare los valores antiguos resueltos y el usuario asignado con la identidad de destino elegida. Compruebe cómo se representan el nombre de usuario y el dominio en el destino; la compatibilidad del inicio de sesión se verifica por separado, como se ha indicado.

Configuración en el dispositivo antiguo

Documente el OEM/API y si la cuenta se configuraba de forma automática o manual. La descripción antigua cita LG GATE, Samsung Knox y Sony Enterprise API para la configuración automática. En otros dispositivos, el usuario tenía que configurar la aplicación de correo a partir de los detalles mostrados en Sophos Mobile Control. Prepare instrucciones propias para el usuario y un piloto de la aplicación de destino; no repita simplemente la configuración antigua.

Sincronización y cuenta predeterminada

Registre Synchronization interval como el intervalo entre sincronizaciones, separado de Synchronization period, que define la antigüedad de los mensajes incluidos. Documente el mecanismo de destino para la frecuencia de consulta o la ausencia de equivalente. Incluya también Default account y aclare cómo selecciona la aplicación de destino la cuenta predeterminada o si no existe un ajuste gestionado.

Flujo de datos, formato y tamaño de los mensajes

Para Allow forwarding emails y Allow use of HTML format, registre los valores existentes y las decisiones anteriores sobre las necesidades de la empresa y la privacidad. Indique para ambos ajustes si la aplicación de destino o Exchange pueden aplicarlos. Si no pueden, señale expresamente la ausencia de equivalente.

Anote literalmente el valor de Maximum attachment size in MB. Pese al nombre del campo, Sophos lo describe como el tamaño máximo de un único mensaje de correo, no expresamente solo de un adjunto. Compruebe por separado qué efecto es relevante para el funcionamiento y qué límite impone la aplicación de destino o Exchange.

Caso especial de Sony en los dispositivos antiguos

La fuente alemana indica Enterprise API Level 6.x o anterior; la inglesa, Level 6 o anterior. En los dispositivos afectados, la información de la cuenta de Exchange debe corresponder al usuario asignado. Mobile Control no puede transmitir allí el identificador ActiveSync. Por ello, en el primer contacto con el proxy EAS, este busca un dispositivo con identificador ActiveSync desconocido y un usuario asignado que coincida. Si lo encuentra, vincula el identificador enviado por el cliente de correo y reenvía la solicitud; si no, la rechaza. Antes de autorizar la cuenta antigua, coteje la versión de API, el usuario asignado y la identidad real del cliente. Observe la vía de correo autorizada existente sin restablecer identidades ni eludir controles de acceso. Demuestre por separado que la vía de destino funciona; no traslade esta condición antigua a Gmail en Android Enterprise.

Quiosco y salida autorizada

Para Kiosk mode, registre el valor existente de Select source (Custom, App list o No app), la App ID exacta, la instalación real, el estado de asignación y el estado del dispositivo. Para App list, documente la entrada de aplicación Android seleccionada y ya añadida a Sophos Mobile; antes de establecer su correspondencia en el destino, coteje la identidad de paquete resuelta con App ID y con la aplicación realmente instalada. Si falta la aplicación de quiosco configurada al asignar la política antigua, la tarea de asignación de la política permanece en Incomplete / Unvollständig hasta que se instala la aplicación. Ante ese estado, coteje primero la identidad y la instalación; un restablecimiento no sirve para resolver problemas por sospecha. No app, en cambio, significa que se transfieren las restricciones pero no se inicia ninguna aplicación. No lo confunda con un paquete ausente ni con una opción de Enterprise llamada None.

Si no se han deshabilitado funciones del dispositivo, el usuario puede salir de la aplicación de quiosco antigua y utilizar el dispositivo normalmente; seleccionar una aplicación no demuestra por sí solo que el usuario quede confinado en ella. Documente en particular los estados existentes de Allow Home button y Allow task manager, y el acceso físico autorizado o un acceso alternativo de administrador. Antes del restablecimiento, compruebe la aplicación de quiosco, que se pueda iniciar y que exista una salida; demuéstrelo por separado para el modo de destino.

Según la fuente antigua, en Sony Enterprise API Level 9 o posterior, si se deshabilita siquiera una de las opciones Allow volume up, Allow volume down o Allow volume mute, se deshabilitan todas las teclas de volumen. Registre el modelo afectado, el nivel de API y el estado antiguo. En el piloto de destino autorizado, compruebe qué controles de sonido y teclas son compatibles con ese modelo y el modo de gestión elegido. Pruebe en el dispositivo el sonido y las teclas necesarios, en lugar de dar por supuesto el efecto antiguo.

Knox Premium, protección de arranque y aplicaciones de administrador

Registre el valor existente de Allow firmware auto update options, su responsable y la compatibilidad del dispositivo/licencia. La opción antigua hace que el dispositivo busque actualizaciones de firmware automáticamente; el usuario no puede cambiarlo en los ajustes del dispositivo. No significa que todas las actualizaciones se instalen automáticamente. Documente por separado el sustituto compatible de destino o su ausencia y observe el comportamiento real de actualización en el piloto autorizado, sin activar de nuevo opciones antiguas.

Las antiguas Knox Premium restrictions afectan al dispositivo Samsung Knox, no al contenedor Knox. Su aplicación requiere una licencia Samsung Knox Premium registrada en Sophos Mobile. Compruebe por separado el tipo de dispositivo, el registro de la licencia y el efecto real en el dispositivo. Para el modo de destino Enterprise elegido, aclare qué licencia se necesita y qué efecto en el dispositivo es compatible; el registro de la licencia antigua no demuestra que se transfiera.

Registre el estado existente de Enable ODE Trusted Boot verification. Según la descripción antigua, la partición de datos solo se descifra al arrancar si el binario y el kernel son oficiales. Aclare el acceso a los datos y la vía de recuperación autorizada antes de reiniciar o restablecer; no desactive la verificación como atajo para migrar o recuperar el dispositivo.

Registre por separado Prevent installation of another administrator app y Prevent activation of another administration app. La primera opción antigua impide instalar aplicaciones con derechos de administrador de dispositivos, excepto las instaladas por Sophos Mobile; la segunda impide activar esos derechos. Compruebe de antemano el efecto real sobre las aplicaciones necesarias y la vía de inscripción prevista, sin flexibilizar los bloqueos de forma indiscriminada.

Si existe Allow Common Criteria mode, registre además las seis condiciones antiguas:

cifrado del dispositivo activado;
cifrado rápido desactivado;
cifrado del almacenamiento externo activado;
umbral de intentos fallidos para borrar el dispositivo establecido;
revocación de certificados activada;
historial de contraseñas desactivado.

Según la fuente antigua, CC Mode no se aplica sin estas condiciones. Son dependencias de origen, no una indicación de activar de nuevo opciones antiguas ni de debilitar la protección por contraseña en el destino. No pruebe el borrado por intentos fallidos en dispositivos de producción. Compruebe por separado en el piloto autorizado la compatibilidad actual, el equivalente de destino y la recuperación; la descripción antigua no acredita una certificación vigente.

Bloqueo de pantalla y restricciones

Para el bloqueo de pantalla existente, registre en Password policies el valor de Password type y su significado antiguo: Pattern, PIN or password exige un bloqueo de pantalla sin restricciones adicionales; Simple password exige una contraseña con al menos una letra y permite cifras; PIN or password permite esos dos tipos de bloqueo. Alphanumeric password y Complex password exigen una contraseña con letras y cifras. Solo Complex password añade los seis valores mínimos de composición indicados a continuación. Esto describe la política de origen, no la configuración de una nueva política antigua ni un comportamiento idéntico en Android Enterprise.

Para Simple password, PIN or password, Alphanumeric password y Complex password, registre además los valores existentes en cada caso: Minimum password length (número total de caracteres), Maximum idle time before password prompt (período de inactividad configurado; el dispositivo puede imponer uno más corto), Maximum password age in days (intervalo de cambio; rango antiguo de 0–730 días, sin cambio obligatorio si el valor es 0), Maximum sign-in attempts (intentos fallidos hasta el borrado del dispositivo antiguo) y Password history (número de contraseñas anteriores guardadas que no se pueden reutilizar). No invente valores para campos que no existan en el tipo elegido. Antes de autorizar la intervención, documente para el tipo y para cada campo el efecto de destino compatible o su ausencia expresa, el sistema operativo/OEM y el bloqueo elegido del dispositivo o del perfil de trabajo; no adopte automáticamente los valores antiguos.

En Password policies, para un Complex password existente, registre por separado los seis valores mínimos: letras, minúsculas, mayúsculas, caracteres no alfabéticos, cifras y caracteres especiales. Los caracteres no alfabéticos y los especiales son valores antiguos distintos, no un requisito combinado. Coteje cada valor con la gestión completa del dispositivo, el bloqueo del dispositivo o del perfil de trabajo elegido, y con las indicaciones de sistema operativo y OEM. Documente para cada mínimo el equivalente compatible o su ausencia y la aplicación observada sin pruebas destructivas.

Incluya también Allow fingerprint authentication y Allow iris authentication, con sus selecciones existentes. Los métodos de desbloqueo antiguos solo se aplican a dispositivos compatibles. Compruebe por separado, según el sistema operativo y el OEM, la disponibilidad y los métodos de desbloqueo realmente permitidos en el modo de destino. La huella digital de App Protection o Weak biometric recognition no demuestran que exista un equivalente idéntico.

Para Password policies y Restrictions, compruebe la recuperación, la copia de seguridad y el efecto de cada bloqueo y restricción relevante según el sistema operativo y el modo; no presuponga el mismo efecto en dispositivos personales y corporativos. Un umbral de intentos fallidos puede borrar el dispositivo; no lo pruebe en dispositivos de producción.

Para las Restrictions que se utilizan realmente, complete la matriz hasta el nivel de cada ajuste relevante: valor antiguo, efecto observado en el dispositivo, objetivo de protección de la empresa, sistema operativo/OEM y dependencias entre opciones principales y subordinadas, equivalente de destino compatible o desviación expresa y autorizada. Incluya en particular la transferencia y grabación de datos, el uso de conexiones inalámbricas, funciones de compartición y periféricos, la conectividad, las comunicaciones de emergencia y el roaming, las actualizaciones y la recuperación, las cuentas —incluida la eliminación de cuentas de Google—, las fuentes de instalación de aplicaciones y su desinstalación. Justifique la exclusión de lo que no se utilice o no sea aplicable. No evalúe los bloqueos solo por su nombre: según la fuente antigua, una prohibición de vídeo permite fotos y streaming; el portapapeles compartido requiere Allow clipboard. Si se utiliza Bluetooth, compruebe también los emparejamientos y perfiles existentes; para el tethering o la cámara en la pantalla de bloqueo, compruebe también la opción principal. Registre igualmente los valores subordinados relevantes de SD/USB junto con sus opciones principales. Un bloqueo antiguo de Beam no controla Quick Share. En el piloto de destino autorizado, demuestre con datos de prueba inofensivos las funciones necesarias y el bloqueo de los flujos de datos prohibidos; si falta un equivalente o el efecto es distinto, detenga el despliegue hasta que se documente la decisión.

Las subpáginas históricas describen las opciones de origen, algunas de 2022–2023, pero no acreditan la compatibilidad actual de los protocolos antiguos ni de las funciones OEM en los dispositivos de destino. Estos ámbitos de comprobación muestran qué dependencias deben aclararse antes de la migración. Antes de recomendar políticas concretas, revise las dos políticas de destino completas y su propio tenant. Los artículos independientes sobre políticas para dispositivos totalmente gestionados, políticas para perfiles de trabajo, conectividad de Android, BYOD y FRP no sustituyen la autorización de migración. La autenticación del correo también se trata en el artículo sobre la migración de Exchange.

Piloto, criterios de detención y recuperación

Solo tras aclarar la titularidad, el tenant y las licencias, y disponer de una vía de recuperación autorizada, realice un piloto con dispositivos representativos y prescindibles de cada modo. Antes, respalde los datos del dispositivo y las políticas anteriores y prepare por separado la nueva política y el método de inscripción. En el piloto, confirme la ejecución de la orden en el dispositivo, compruebe el nuevo modo de gestión y la asignación efectiva, y observe las aplicaciones, el acceso a la cuenta y el flujo de correo, el quiosco (si lo hay), Wi-Fi/VPN, la emisión y renovación de certificados y los datos personales tras el cambio de BYOD. Solo amplíe la migración a otros dispositivos cuando se hayan documentado sus efectos.

Registre en el piloto resultados concretos, previstos y observados, para los valores antiguos inventariados:

Datos móviles

Compruebe el acceso a datos móviles con la SIM prevista y el operador previsto, por separado del acceso independiente de recuperación y gestión probado anteriormente. Después compruebe la comunicación con la plataforma de gestión. Si no hay acceso a datos, no migre más dispositivos; utilice el acceso independiente y la vía de escalado autorizados de antemano.

Aplicaciones y permisos

Compruebe primero si se puede iniciar cada aplicación que antes estaba bloqueada, así como las aplicaciones necesarias para el funcionamiento y las emergencias. Después, con datos de prueba, compruebe cada aplicación de destino y sus permisos en tiempo de ejecución. Compare el estado previsto con el funcionamiento real de la aplicación cuando el permiso se concede o se deniega. Compruebe también si el usuario puede modificar el permiso según lo previsto o si se impide el cambio. Tenga en cuenta las limitaciones de Android 12 en el perfil de trabajo.

Antes de hacer un cambio, registre los ajustes y la asignación. Utilice únicamente la vía de actualización o sustitución compatible y probada de antemano. Si debe revertirse una modificación de la política, confirme la sincronización y repita las mismas comprobaciones de permisos.

No conceda permisos indiscriminadamente solo para que funcione una aplicación. Retirarlos después no recupera los datos que ya se hayan divulgado.

Contraseña de aplicaciones y bloqueo de pantalla

En el destino, compruebe la solicitud de contraseña esperada, los accesos alternativos permitidos, el período durante el que no se vuelve a solicitar la contraseña y la autenticación. Para el bloqueo del dispositivo o del perfil de trabajo, compruebe sin acciones destructivas los requisitos mínimos individuales y los métodos biométricos disponibles, sin agotar el umbral de intentos fallidos.

Para el bloqueo de destino elegido, compare los tipos de bloqueo permitidos y la longitud total con la decisión documentada, y observe el tiempo real de inactividad hasta la solicitud de contraseña, incluidos los límites más cortos del dispositivo. Compruebe el comportamiento de cambio y reutilización, cuando sea compatible, en una cuenta o dispositivo de prueba autorizado o mediante evidencias de estado admitidas; registre expresamente cualquier falta de compatibilidad. En dispositivos de producción, no acelere los cambios de contraseña, no debilite la protección ni agote los intentos fallidos. Mantenga la vía de recuperación preparada y detenga el despliegue si hay desviaciones.

Correo

Con una cuenta de prueba autorizada y contenido inofensivo, compruebe el tiempo de entrega, la cuenta predeterminada al redactar, el reenvío permitido o prohibido, el comportamiento de HTML y los tamaños de mensaje relevantes. No utilice datos confidenciales reales. Compare el resultado con la decisión de destino documentada, aunque en el destino falte un ajuste que antes se gestionaba.

Deténgase ante desviaciones

Si observa una desviación, detenga el despliegue. No basta con que la configuración de destino sea visible; aclare primero la causa, el equivalente compatible y una vía segura de recuperación.

Si falta conectividad, se desconoce el estado de los datos, el dispositivo o el modo es incorrecto, falla el inicio de sesión o aparece un bloqueo tras el restablecimiento, deténgase y escale el caso. Antes de intervenir, determine a qué soporte recurrir, asegure una conexión independiente que funcione y defina una vía de nueva puesta en servicio. Revertir no significa deshacer un restablecimiento de fábrica ni recuperar un perfil de trabajo eliminado: la recuperación solo es posible a partir de copias de seguridad cuya utilidad esté comprobada y mediante una nueva inscripción autorizada; no se ha demostrado ni la entrega remota inmediata ni una aplicación idéntica de las políticas. Sin pruebas en el tenant y los dispositivos, no presente esto como una guía de migración para producción ni garantice el éxito.