Skip to content

Migración de MDM de Apple: guía para administradores de TI

Última actualización: 13 de noviembre de 2026

Cambiar de proveedor de MDM cuando se gestionan cientos o miles de dispositivos Apple en producción es uno de los proyectos más complejos desde el punto de vista operativo a los que se enfrenta un equipo de TI. La capacidad de migración nativa del sistema operativo 26 de Apple cambia significativamente el panorama, pero una migración limpia sigue requiriendo una planificación minuciosa, documentación de la configuración y un flujo de trabajo sólido para la validación posterior a la migración.

Esta guía abarca todo, desde el inventario previo a la migración hasta la verificación del cumplimiento normativo tras la misma, prestando especial atención a los escenarios que suelen plantear más dificultades a la mayoría de los equipos: la conservación de los datos de las aplicaciones, la sincronización de las claves de recuperación de FileVault y la gestión de los dispositivos que no cumplen los requisitos para la nueva ruta de migración del sistema operativo 26.

¿Qué ha cambiado en la migración MDM con el sistema operativo 26 de Apple?

Antes del OS 26, la migración de dispositivos Apple supervisados entre soluciones MDM implicaba casi siempre un restablecimiento de fábrica, una nueva inscripción y la reinstalación de todas las aplicaciones gestionadas. Para una flota de 500 MacBook, eso supone un proyecto de varias semanas que afecta a todos los usuarios.

El OS 26 de Apple introduce un flujo de migración nativo gestionado a través de Apple Business (antes Apple Business Manager/ASM). El mecanismo funciona así:

1. Un administrador reasigna los dispositivos de un servidor MDM a otro directamente desde Apple Business.

2. El MDM de origen envía una notificación de migración a los dispositivos inscritos.

3. Los usuarios reciben un aviso con un plazo configurable para completar la transición.

4. El dispositivo se da de baja del MDM de origen y se inscribe automáticamente en el MDM de destino, sin que sea necesario borrar sus datos.

Para los equipos de gestión de dispositivos de Apple que operan íntegramente a través de Apple Business con dispositivos inscritos en ADE, esto supone un cambio transformador. La restricción clave: tanto el servidor MDM de origen como el de destino deben ser compatibles con la API de migración de OS 26, y los dispositivos deben ejecutar OS 26 o una versión posterior.

Dispositivos y escenarios que la migración a OS 26 no cubre:

  • Dispositivos que ejecutan iOS/iPadOS/macOS anteriores a la versión OS 26 (en estos casos, sigue siendo necesario dar de baja el dispositivo y volver a registrarlo manualmente, o bien borrar su contenido).
  • Implementaciones de iPad compartidos
  • Dispositivos inscritos en Apple Business Essentials
  • Dispositivos no registrados en Apple Business o Apple School Manager
  • Dispositivos inscritos por el usuario (BYOD), que siguen un proceso independiente

Si tu parque de dispositivos incluye un porcentaje significativo de dispositivos con versiones anteriores a la 26, planifica una vía de migración paralela. No dejes que las características más destacadas te hagan olvidar que un entorno con sistemas operativos mixtos requiere un enfoque con métodos mixtos. Si gestionas dispositivos BYOD junto con hardware propiedad de la empresa, estos necesitarán una planificación de migración totalmente independiente.

Planificación previa a la migración: qué documentar antes de tocar nada

La causa más habitual de una migración de MDM problemática no es la migración en sí misma, sino una documentación deficiente de lo que realmente hace el MDM de origen. Antes de iniciar cualquier acción en Apple Business o en tu MDM de destino, exporta y documenta lo siguiente:

Perfiles de configuración

  • Exporta todos los perfiles de configuración del MDM de origen, incluyendo el tipo de carga útil, el alcance y cualquier excepción específica del dispositivo.
  • Marca los perfiles que gestionan ajustes sensibles en materia de seguridad: FileVault, bloqueo de pantalla, cortafuegos, confianza en certificados y filtrado de contenidos.
  • Anota los perfiles distribuidos por el MDM frente a los perfiles que se instalaron manualmente. Los perfiles instalados manualmente no se migran automáticamente y es posible que no se puedan volver a distribuir sin la intervención del usuario.

Inventario de aplicaciones y asignación de VPP/Apps and Books

  • Obtenga una lista completa de las aplicaciones gestionadas, incluidas las aplicaciones de la App Store asignadas a través de «Apps and Books» y cualquier aplicación personalizada o empresarial instalada de forma alternativa a través del MDM.
  • Documenta qué aplicaciones están asignadas a dispositivos y cuáles a usuarios.
  • Comprueba que tu token de «Apps and Books» esté asociado a tu cuenta de Apple Business y no esté vinculado de forma fija al proveedor de MDM de origen. Tendrás que revocar el token e invitarlo de nuevo en el MDM de destino.

Estado de inscripción y supervisión

Para cada dispositivo, documenta:

  • Tipo de inscripción (ADE/inscripción de usuario/manual)
  • Estado de supervisión
  • Versión del sistema operativo
  • Número de serie y estado del registro en Apple Business

Este es también un buen momento para cotejar el inventario de dispositivos MDM con los registros de gestión de inventario de hardware. Los dispositivos que aparecen en un sistema pero no en el otro son un problema que hay que resolver antes de la migración, no después.

Pautas de seguridad

Asigna tus perfiles de configuración actuales a los controles de seguridad que aplican. Si tu organización cumple con los criterios de referencia CIS para macOS o las recomendaciones del NIST SP 800-179, documenta qué perfiles se corresponden con cada control. Necesitarás esta asignación para validar tu estado de seguridad en el MDM de destino tras la migración.

Configuración del MDM de destino antes del día de la migración

El MDM de destino debe estar totalmente configurado y probado antes de que se traslade ni un solo dispositivo de producción. Llevar a cabo una migración a un MDM que no esté preparado es la forma de crear un periodo en el que los dispositivos estén inscritos pero sin control.

Configuración necesaria en el MDM de destino

Certificado del Servicio de Notificaciones Push de Apple (APNs): los certificados APNs son específicos de cada proveedor. El certificado APNs de tu MDM de origen no se puede transferir. Genera un nuevo certificado a través del Portal de certificados push de Apple utilizando el Apple ID de tu organización y, a continuación, súbelo al MDM de destino. El certificado debe renovarse anualmente, por lo que debes anotar la fecha de caducidad y el Apple ID utilizado.

Integración de ADE (inscripción automatizada de dispositivos): En Apple Business, asigna el MDM de destino como servidor para los dispositivos que vas a migrar. Este es el paso que configura el flujo de migración a OS 26. Los dispositivos asignados al nuevo servidor MDM recibirán la solicitud de migración una vez que tu MDM de origen la inicie.

Configuración de la inscripción en PreStage: En el MDM de destino, configura tu PreStage (o perfil de inscripción equivalente) antes de que lleguen los dispositivos. Esto incluye:

  • Configuración del panel del Asistente de configuración
  • Asignaciones iniciales de perfiles
  • Ajustes de instalación del perfil MDM

Token de Apps y Libros: Revoca el token del MDM de origen y vuelve a invitarlo al MDM de destino. Ten en cuenta que revocar el token del MDM de origen eliminará inmediatamente la capacidad de enviar nuevas asignaciones de aplicaciones VPP desde ese sistema, por lo que debes coordinar este momento con tu ventana de migración.

Perfiles de configuración: Vuelve a crear todos los perfiles de configuración necesarios en el MDM de destino. No te limites a reproducir al pie de la letra la arquitectura de perfiles del MDM antiguo. Aprovecha la migración como una oportunidad para racionalizar tu estructura de políticas. Los entornos MDM heredados suelen acumular años de perfiles superpuestos, conflictivos o redundantes. Una migración es una ocasión ideal para poner orden en todo esto.

Ejecución de la migración: el proceso de OS 26 paso a paso

Una vez configurado el MDM de destino y asignados los dispositivos en Apple Business, esta es la secuencia operativa:

1. Inicia la migración desde el MDM de origen. El MDM de origen envía un comando MDM a los dispositivos inscritos para indicar la migración. El mecanismo exacto varía según el proveedor, pero el resultado es el mismo: aparece una notificación en el dispositivo.

2. Los usuarios reciben un aviso de migración. La migración del OS 26 de Apple incluye un plazo de inscripción configurable. Puedes establecer un periodo de gracia (normalmente de 24 a 72 horas para los dispositivos corporativos gestionados) tras el cual el dispositivo aplica la migración automáticamente. Informa a los usuarios antes de que aparezca el aviso. Un cuadro de diálogo del sistema sin explicación previa en el que se solicite cambiar la gestión del dispositivo generará incidencias de soporte técnico.

3. El dispositivo se da de baja del MDM de origen. El dispositivo elimina el perfil de gestión del MDM de origen y cualquier perfil de configuración proporcionado por dicho MDM.

4. El dispositivo se inscribe en el MDM de destino. El dispositivo se conecta a los servidores de Apple, recupera el perfil de inscripción asignado para el MDM de destino y completa la inscripción.

5. El MDM de destino distribuye perfiles de configuración y aplicaciones. El dispositivo recibe los perfiles que se le han asignado y comienza a instalar las aplicaciones gestionadas. Los dispositivos no se borran. Se conservan los datos del usuario, las aplicaciones instaladas localmente y los ajustes no relacionados con la configuración distribuida por el MDM.

Nota sobre la conservación de aplicaciones: Las aplicaciones gestionadas asignadas a través de «Aplicaciones y libros» se conservan durante la migración a OS 26 si el MDM de destino está configurado para reclamar la gestión de dichas aplicaciones. Si el MDM de destino no reclama las aplicaciones, estas pueden pasar del estado «gestionado» al estado «no gestionado», lo que tiene implicaciones para los datos de las aplicaciones gestionadas y el comportamiento del borrado selectivo. Comprueba la configuración de reclamación de gestión de aplicaciones de tu MDM de destino antes de realizar la migración.

Continuidad de FileVault y la configuración de seguridad

Las claves de recuperación de FileVault se almacenan en el MDM de origen. Cuando un Mac migra al MDM de destino, el MDM de origen pierde su conexión de gestión y la clave de recuperación almacenada en él queda huérfana.

Para mantener la continuidad de la clave de recuperación de FileVault:

  • Tras la migración, el MDM de destino debe emitir un comando de rotación de la clave de recuperación de FileVault. Esto genera una nueva clave de recuperación y la deposita en el MDM de destino.
  • Hasta que se produzca dicha rotación, la clave anterior almacenada en el MDM de origen sigue siendo válida para la recuperación, pero ya no está gestionada.
  • Da prioridad a los Mac con FileVault activado en tu lista de comprobación de validación de la migración. Confirma que la nueva clave de recuperación se haya depositado en el MDM de destino para cada dispositivo.

En cuanto al resto de configuraciones de seguridad, comprueba lo siguiente en el MDM de destino tras la migración:

  • Aplicación de la política de bloqueo de pantalla y contraseña
  • Estado del cortafuegos
  • Estado de la Protección de Integridad del Sistema (SIP) en los Mac con procesador Intel
  • Configuración de Gatekeeper
  • Perfiles de confianza de certificados

Si tu organización sigue un marco de cumplimiento normativo, este es el momento adecuado para realizar una comprobación de cumplimiento en cada dispositivo. Entender la gestión de dispositivos y la seguridad como una disciplina integrada, en lugar de como flujos de trabajo separados, hace que la validación posterior a la migración sea más sistemática.

Estrategias de migración para dispositivos con versiones anteriores a OS 26

Para los dispositivos que ejecutan iOS/iPadOS o macOS con versiones anteriores a la 26, tienes tres opciones:

Opción 1: Actualizar a la versión 26 del sistema operativo y, a continuación, realizar la migración. Si el dispositivo es compatible con la versión 26 del sistema operativo, envía la actualización desde el MDM de origen antes de iniciar la migración. Esta es la opción más sencilla para el hardware compatible.

Opción 2: Dar de baja el dispositivo del MDM de origen y volver a inscribirlo en el MDM de destino. En el caso de los dispositivos inscritos en ADE, puede dar de baja el dispositivo del MDM de origen y este se volverá a inscribir en el MDM de destino según su asignación de Apple Business. Esto no requiere un borrado completo, pero sí que el usuario complete los pasos del Asistente de configuración, a menos que los haya configurado para omitirlos.

Opción 3: Restablecimiento a los valores de fábrica y nueva inscripción. Para los dispositivos que no estén en Apple Business o aquellos con configuraciones locales complejas que deban borrarse, el borrado completo y la nueva inscripción son la opción más limpia. Esta es la opción que requiere mayor coordinación con los usuarios finales.

Documenta la distribución de las versiones del sistema operativo en tu parque de dispositivos en una fase temprana de la planificación. Si el 30 % de tus Macs tienen macOS Sequoia y no son compatibles con el sistema operativo 26, eso supone una línea operativa importante que debes planificar por separado.

Planificación de la reversión y procedimientos de contingencia

La mayoría de las guías de migración omiten esta sección. No lo hagas.

Antes de iniciar cualquier migración en producción, define tu umbral de reversión: ¿en qué momento detienes o reviertes la migración? Entre los desencadenantes habituales se incluyen:

  • Más del X % de los dispositivos migrados no reciben perfiles de configuración en un plazo de Y horas
  • Pérdida de aplicaciones gestionadas que supere un umbral definido
  • Informes de faltas en las claves de recuperación de FileVault por encima de un porcentaje establecido
  • La instalación de herramientas de seguridad (EDR, protección de terminales) falla en los dispositivos migrados

La reversión del flujo de migración a OS 26 implica reasignar los dispositivos al servidor MDM de origen en Apple Business y activar una migración inversa. Esto es técnicamente posible, pero requiere que el MDM de origen siga activo y cuente con licencia. No canceles tu contrato con el MDM de origen hasta que hayas confirmado que la migración se ha realizado con éxito y hayas completado la validación posterior a la migración de toda la flota.

En el caso de flotas grandes, la práctica habitual es realizar un despliegue por fases: migrar un grupo piloto de entre 10 y 20 dispositivos de un equipo no crítico, validar minuciosamente y, a continuación, proceder por lotes. Cada lote debe pasar por un punto de control de validación antes de que comience el siguiente.

Validación posterior a la migración y verificación del cumplimiento

La validación posterior a la migración es un aspecto en el que muchos equipos invierten menos de lo necesario. Un dispositivo que parece estar registrado en el MDM de destino no tiene por qué cumplir con los requisitos. Comprueba cada uno de estos aspectos en tus dispositivos migrados:

  • Perfiles de configuración entregados y aplicados (consulte el dispositivo para ver los perfiles instalados)
  • Aplicaciones gestionadas instaladas y en estado gestionado
  • Clave de recuperación de FileVault depositada en el MDM de destino
  • Herramientas de seguridad (agente EDR, protección de terminales) instaladas y generando informes
  • Dispositivo conforme con todas las políticas requeridas
  • Perfiles de certificado instalados y válidos

Incorpora todo esto en una lista de comprobación de validación formal y aplícala a cada lote de migración antes de darlo por completado. Si tu MDM de destino dispone de un panel de cumplimiento o una vista de informes, utilízalo. Los dispositivos que aparezcan como inscritos pero no conformes requieren un seguimiento inmediato.

Cómo aborda Iru la migración de Apple MDM

La migración suele ser el momento en el que los equipos se replantean toda su arquitectura de políticas, no solo su proveedor de MDM. Iru se basa en un concepto denominado «mapas de asignación», que permite definir una jerarquía estructurada de políticas que asigna los atributos de los dispositivos y los usuarios a conjuntos de configuración. A la hora de migrar desde un MDM heredado, esto resulta especialmente útil, ya que obliga a diseñar las políticas de forma deliberada, en lugar de limitarse a recrear 1:1 todo lo que se haya acumulado en el antiguo sistema a lo largo de los años.

En lo que respecta específicamente a la distribución de aplicaciones, la implementación automática de aplicaciones de Iru está configurada para distribuir las aplicaciones gestionadas antes de que finalice el comando «DeviceConfigured». Esto significa que los dispositivos que pasan por el flujo de migración a OS 26 reciben sus aplicaciones como parte de la secuencia de inscripción inicial, en lugar de como un proceso en segundo plano que los usuarios podrían percibir como una interrupción.

Iru se conecta directamente a Apple Business para la integración de ADE y la gestión de APNs, lo que simplifica el flujo de migración. Basta con asignar los dispositivos al servidor MDM de Iru en Apple Business, configurar los perfiles de inscripción y los mapas de asignación, y la migración se lleva a cabo siguiendo el flujo estándar de Apple.

Para la validación del estado de seguridad tras la migración, la biblioteca de cumplimiento normativo de Iru incluye elementos predefinidos que se corresponden con los criterios de referencia CIS para macOS y los controles comunes del NIST. Tras la migración, puede generar un informe de cumplimiento normativo para todo su parque de dispositivos y ver inmediatamente cuáles necesitan correcciones, en lugar de tener que crear esa correspondencia desde cero.

Para los equipos que migran desde plataformas heredadas complejas, la interfaz de Iru está diseñada en torno al funcionamiento real de los marcos de gestión de Apple, lo que reduce el tiempo de adaptación de los administradores que han pasado años trabajando con las abstracciones de otra herramienta.

Sacar el máximo partido a la migración a MDM de Apple

Una migración a MDM de Apple es, por definición, disruptiva. Los equipos que salen de ella en la mejor posición la tratan como un rediseño intencionado de su arquitectura de gestión, no solo como un cambio de proveedor. Eso significa racionalizar la estructura de perfiles, validar las bases de referencia de seguridad frente a un marco real y confirmar que todos los dispositivos cumplen realmente con los requisitos antes de dar el proyecto por finalizado.

La capacidad de migración nativa de OS 26 elimina la necesidad de restablecer los ajustes de fábrica en los dispositivos que cumplan los requisitos, lo que suprime la mayor interrupción para los usuarios. Sin embargo, el trabajo de planificación, la documentación previa a la migración y la validación posterior a la misma siguen siendo esenciales, independientemente de la ruta de migración elegida.

Si tu equipo está evaluando pasarse a Iru o planificando una migración desde otro proveedor de MDM de Apple, solicita una demostración para ver cómo los «Assignment Maps» y la arquitectura nativa de Apple de Iru pueden simplificar tanto la migración como la gestión continua posterior a la misma.

 

Preguntas frecuentes

¿Puedo migrar dispositivos Apple a un nuevo MDM sin restablecerlos de fábrica?

Sí, para dispositivos con OS 26 o posterior que estén registrados en Apple Business o Apple School Manager e inscritos a través de ADE. El flujo de migración nativo de Apple en OS 26 permite mover dispositivos entre proveedores de MDM sin necesidad de borrarlos. Los dispositivos con versiones de sistema operativo anteriores, los iPad compartidos y los dispositivos BYOD (inscritos por el usuario) no cumplen los requisitos para este método y requieren una reinscripción manual o un restablecimiento de fábrica.

¿Cómo migro mis dispositivos Apple a un nuevo MDM si utilizan una versión de sistema operativo anterior?

Para dispositivos inscritos mediante ADE con una versión anterior a OS 26, puedes enviar una actualización del sistema desde el MDM de origen para llevarlos a OS 26 y luego utilizar el flujo de migración nativo. Como alternativa, puedes dar de baja los dispositivos en el MDM de origen y permitir que se vuelvan a inscribir mediante Apple Business según la nueva asignación de servidor MDM, lo cual no requiere borrado pero sí interacción del usuario durante el Asistente de configuración. Los dispositivos que no están en Apple Business suelen requerir un restablecimiento de fábrica y una inscripción desde cero.

¿Qué ocurre con mis aplicaciones gestionadas durante una migración de MDM?

En el flujo de migración de OS 26, las aplicaciones instaladas localmente y los datos de usuario se conservan en el dispositivo. No obstante, las aplicaciones gestionadas asignadas a través de Apps y libros (Apps and Books) pueden pasar de estado gestionado a no gestionado si el MDM de destino no reclama la gestión de dichas aplicaciones tras la migración. Comprueba la configuración de reclamación de gestión de apps en tu MDM de destino y asegúrate de que tu token de Apps y libros se transfiera correctamente al MDM de destino antes de migrar.

¿Necesito configurar un nuevo certificado APNs al cambiar de proveedor de MDM?

Sí. Los certificados APNs están vinculados a la infraestructura de firma del proveedor de MDM y no se pueden transferir entre distintos proveedores. Debes generar un nuevo certificado APNs a través del Apple Push Certificates Portal utilizando el ID de Apple de tu organización y subirlo al MDM de destino. Si utilizas el mismo ID de Apple para las renovaciones periódicas de APNs, documenta qué ID de Apple se utilizó para crear el certificado.

¿Cuánto suele tardar una migración de MDM de Apple?

Para una migración por fases de una flota mediana (500 a 2.000 dispositivos) utilizando el flujo nativo de OS 26, el periodo de migración activa (una vez configurado el MDM de destino) puede durar de 2 a 4 semanas con un despliegue bien planificado. La planificación previa y la configuración del MDM de destino suelen tardar de 2 a 4 semanas previas, según la complejidad del entorno actual. Añade un periodo de validación posterior a la migración de al menos una semana antes de retirar o dar de baja el MDM de origen.

¿Qué debo hacer con las claves de recuperación de FileVault al migrar equipos Mac a un nuevo MDM?

Las claves de recuperación de FileVault custodiadas en el MDM de origen quedan huérfanas tras la migración, ya que el MDM de origen pierde su enlace de gestión. Inmediatamente después de la migración, activa una rotación de claves de recuperación de FileVault desde el MDM de destino para todos los Mac migrados. Esto genera una nueva clave y la custodia en el MDM de destino. Hasta que finalice la rotación, la clave antigua almacenada en el MDM de origen sigue siendo válida para la recuperación de emergencia, lo que constituye otro motivo para mantener activo el MDM de origen hasta finalizar la validación post-migración.

Vea Iru en acción

Descubra por qué miles de equipos eligen Iru

Al enviar este formulario, acepto la Política de Privacidad de Iru y doy mi consentimiento para que Iru se ponga en contacto conmigo en relación con sus productos y servicios.

Mantente al día

La colección quincenal de Iru con artículos, videos e investigaciones para mantener a los equipos de IT y seguridad a la vanguardia.