Hacer una migración entre inquilinos en Microsoft 365 (también llamada migración tenant-to-tenant u Office 365 tenant-to-tenant) no es solo mover buzones de un sitio a otro: implica trasladar identidades, correo, archivos, Teams, automatizaciones, dispositivos y políticas de seguridad sin que el negocio se pare ni se pierda información.
Este tipo de proyecto suele aparecer en fusiones y adquisiciones, escisiones, cambios de dominio o consolidaciones de varios tenants históricos, y combina piezas nativas como CTUDM, capacidades cross-tenant de Entra ID, migraciones de Exchange/SharePoint/OneDrive… En muchos casos, herramientas de terceros y partners especializados que ayudan a que todo sea más llevadero.
Qué es una migración entre inquilinos de Microsoft 365 y en qué casos se hace
Una migración entre inquilinos de Microsoft 365 es el proceso de mover usuarios, buzones de Exchange Online, sitios y archivos de SharePoint y OneDrive, equipos de Teams, automatizaciones de Power Platform, dispositivos gestionados con Intune y configuraciones de seguridad/compliance de un tenant a otro.
La razón número uno para este tipo de migraciones son los escenarios de MAD (fusiones, adquisiciones y desinversiones), donde hay que integrar o separar compañías que ya usan Microsoft 365, aunque también aparecen por rebrandings, cambios de dominio, consolidación de tenants antiguos o cambios de partner/licenciamiento.
Entre los escenarios más habituales encontramos:
- Fusiones y adquisiciones en las que se quiere un único entorno corporativo.
- Carve-out o spin-off de una parte del negocio.
- Cambio global de dominio de correo.
- Unificación de tenants regionales en uno corporativo y reorganizaciones en grupos multinacionales que pasan de modelo por país a modelo global.
En todos estos casos la pregunta clave no es solo “cómo migro”, sino qué se migra tal cual, qué se deja en origen, qué se reconstruye desde cero en el tenant destino y en qué orden se ejecutan los cambios para no dejar colgados procesos críticos ni usuarios sensibles.
Detrás de cada migración tenant-to-tenant hay también una componente legal y de cumplimiento: protección de datos personales, retenciones legales, auditoría, requisitos sectoriales y soberanía de datos que hay que revisar antes de mover un solo bit.
Metodología, gobierno del proyecto y fase de assessment
La diferencia entre una migración tranquila y un desastre suele estar en la metodología. Trabajar por oleadas, con un piloto representativo, UAT con negocio y métricas claras. Con un comité de seguimiento que se reúna de forma periódica para tomar decisiones y priorizar.
Es interesante combinar prácticas ágiles con una planificación por hitos: descubrimiento y assessment, diseño de arquitectura, configuración de coexistencia, ejecución técnica por cargas (correo, archivos, Teams, Power Platform, Intune), movimiento de dominio y fase de estabilización.
El assessment inicial responde a tres preguntas básicas:
- Qué hay ahora (inventario).
- Qué bloquea la migración (retenciones, límites de servicio, regulaciones).
- Qué dependencias críticas unen a usuarios, aplicaciones y datos dentro y entre los tenants.
En la parte de colaboración y archivos conviene inventariar volúmenes y patrones de uso en OneDrive por usuario, sitios de SharePoint (clásicos, modernos, de comunicación, conectados a grupos/Teams) y equipos de Microsoft Teams con sus canales, pestañas, grabaciones y uso de Stream en SharePoint.
En el terreno de dispositivos y aplicaciones hay que mapear políticas y flotas en Intune, aplicaciones que usan Graph/EWS/SMTP OAuth contra el tenant, entornos y soluciones de Power Platform y cualquier integración externa que dependa de identidades o buzones concretos.
Coexistencia: identidad, calendarios y correo entre tenants
La coexistencia bien pensada permite que la organización siga trabajando con normalidad mientras se mueven datos en segundo plano. Así se evitan “apagones” de correo o calendarios.
En identidad, Entra ID es la pieza clave. Se configuran políticas de acceso entre tenants (cross-tenant access), se habilita cross-tenant synchronization si se quiere automatizar el alta y actualización de usuarios B2B, y se decide de antemano el formato de UPN y alias en el entorno destino.
Para calendarios, Exchange Online permite configurar relaciones de organización entre tenants para que los usuarios vean el Free/Busy de sus compañeros aunque aún estén repartidos, ajustando el nivel de detalle y validando que dirección, ventas y soporte pueden seguir agendando sin obstáculos.
En correo, lo más prudente es mantener el registro MX apuntando al origen durante la fase de coexistencia. Solo hay que moverlo al tenant destino cuando los buzones críticos ya estén migrados y comprobados. Mientras tanto, se puede recurrir a conectores y reglas de transporte para enrutar según convenga.
CTUDM, licencias y aspectos legales de la migración
Hoy por hoy, el enfoque de referencia para correo y OneDrive es usar el complemento Cross-Tenant User Data Migration (CTUDM), que habilita migraciones nativas entre tenants de Exchange Online y OneDrive con soporte de Microsoft y altas capacidades de trazabilidad.
CTUDM se licencia por usuario migrado. Está pensado para un único uso por objeto. Por eso conviene planificar qué usuarios realmente van a moverse, cuándo y en qué oleada. La idea es evitar comprar licencias de más ni quedarse corto a última hora.
Desde el punto de vista legal y de cumplimiento es obligatorio revisar contratos de encargado de tratamiento, acuerdos con partners, políticas de protección de datos, retenciones legales y requisitos regulatorios que afecten a la transferencia de datos entre tenants y regiones.
Existen alternativas manuales o híbridas (PST, IMAP, herramientas de terceros sin CTUDM, exportaciones a ficheros intermedios). Estas suelen implicar más riesgo operativo, menos soporte oficial y más trabajo de supervisión. Lo mejor es reservarlas para casos concretos.
Migración de Exchange Online entre inquilinos
Cuando se integra FastTrack o se usa CTUDM, el proceso de mover buzones entre tenants de Exchange Online sigue una secuencia bastante clara: preparar relaciones de confianza, verificar dominios, asegurarse de que el usuario existe en destino y crear lotes de migración.
FastTrack, cuando está disponible, ofrece soporte 24×7 en inglés para clientes comerciales. Suministra directrices de planificación, ayudas para preparar los tenants y servicios de migración que incluyen lanzamiento y monitorización de eventos de migración con informes de estado.
En cuanto a lo que realmente se mueve en Exchange Online, suelen migrarse mensajes de correo, reglas del lado servidor, contactos y calendarios, tareas, buzones archivados asociados, elementos recuperables, salas, buzones de recursos y correos protegidos o cifrados por tecnologías de Microsoft, siempre que no haya bloqueos de cifrado en origen.
Por el contrario, hay elementos que no entran en la migración estándar. Hablamos de carpetas públicas, mensajes que superen el límite de tamaño permitido, soluciones de archivo de terceros, elementos dañados, reglas de cliente, mensajes de Teams, buzones en retención o con más de cierto número de archivos auxiliares de Outlook, perfiles de Outlook, permisos de Entra ID o configuraciones de “Enviar como” y “Enviar en nombre de”.
Antes de mover un buzón conviene limpiar cifrados problemáticos, así como revisar retenciones y suspensiones legales. También asegurar que las listas de distribución y contactos externos existen en el destino. Y que los buzones a migrar están activos y con licencia.
Migración de OneDrive y SharePoint Online entre inquilinos
Mover archivos personales y corporativos implica entender los límites de almacenamiento, las cuotas de SharePoint y OneDrive y las restricciones de tamaño y número de elementos por sitio o cuenta. Existen techos como 5 TB o 1 millón de elementos por OneDrive o site que no podemos ignorar.
En SharePoint
Una migración tenant-to-tenant puede incluir sitios conectados a grupos de Microsoft 365 (incluidos los asociados a Teams), sitios modernos y clásicos, sitios de comunicación, estructuras de carpetas, documentos, permisos a nivel de usuario y grupo, vínculos compartidos, historial de propiedad, versiones y metadatos básicos como fechas de creación/modificación y autores.
Sin embargo, hay exclusiones importantes. Sitios con más de 5 TB o con más de un millón de elementos, documentos dañados o inaccesibles, rutas superiores a 400 caracteres, flujos de trabajo heredados de SharePoint, aplicaciones y componentes como Power Apps o automatizaciones que viven “encima” del contenido.
En OneDrive
El patrón es similar. Se trasladan documentos, carpetas, permisos, enlaces compartidos, versiones y metadatos principales. Pero se quedan fuera cuentas en suspensión legal, contenidos por encima de los límites, rutas excesivamente largas o ficheros corruptos a los que el sistema no puede acceder.
FastTrack o las herramientas nativas de Microsoft para SharePoint/OneDrive ofrecen ayuda para planificar, configurar relaciones de confianza entre tenants, programar eventos de migración, monitorizar el progreso y generar informes. Siempre dentro de los límites de servicio de la plataforma.
Herramientas de terceros y soluciones automatizadas
Aunque Microsoft ofrece un conjunto sólido de capacidades nativas, muchas organizaciones complementan el enfoque con soluciones de terceros. Especialmente cuando buscan reportes muy detallados, interfaces más amigables o funcionalidades específicas.
Herramientas como SysTools Office 365 to Office 365 permiten seleccionar Microsoft 365 como origen y destino, marcar qué cargas migrar (correo, contactos, calendarios, documentos), aplicar filtros por fecha, habilitar opciones de migración de documentos y gestionar asignaciones de usuario mediante ficheros CSV.
Este tipo de herramientas automatizadas suelen pedir registrar una aplicación en Azure, conceder permisos, generar un ID de aplicación y validar los permisos para el tenant origen y el tenant destino. Así pueden actuar en nombre de los administradores y ejecutar la migración en bloque.
Otras soluciones como Kernel Office 365 Migration se centran en mover buzones entre tenants, listando todos los buzones del inquilino origen, mapeándolos con los del destino. Esto permite migrar buzones de usuario y carpetas públicas o buzones de archivo . Y aplicar filtros antes de lanzar la migración.
Estas herramientas suelen ofrecer ventajas. Algunas de ellas son: migración de múltiples proyectos, soporte para cuentas de dominio, migración delta (solo cambios nuevos), prioridad por cuentas y generación de informes detallados en CSV para auditoría y seguimiento posterior.
DSC de Microsoft 365 y replicación de configuraciones entre tenants
Más allá de mover datos, hay que replicar la configuración del tenant. DEsde políticas de seguridad y reglas de acceso condiciona hasta parámetros de Exchange y configuración de SharePoint, Teams, etc. Ahí entra en juego Microsoft 365 Desired State Configuration (DSC).
DSC se basa en scripts declarativos de PowerShell que describen el estado deseado de la configuración. Un Local Configuration Manager revisa periódicamente el entorno. Si detecta desviaciones, aplica los cambios necesarios mediante recursos específicos incluidos en módulos de PowerShell.
Para usar DSC con seguridad suele crearse una aplicación registrada en Azure AD con permisos sobre las APIs pertinentes, autenticando mediante certificado (PFX) y usando la misma aplicación tanto en el tenant de origen como en el de destino para minimizar riesgos de seguridad.
El despliegue inicial de configuraciones mediante DSC puede llevar un tiempo apreciable. Todp depende del volumen de cargas de trabajo incluidas y de la cantidad de parámetros de configuración a replicar. Por eso conviene probarlo primero en entornos de test que reproduzcan la producción.
Preparación de dominio, DNS y movimiento de MX
Uno de los momentos más delicados del proyecto es el movimiento del dominio principal de correo: quitarlo del tenant origen, agregarlo al destino, ajustar MX, SPF, DKIM y DMARC y asegurarse de que el correo no se pierde por el camino.
En la fase previa hay que hacer esto:
- Verificar el dominio en el tenant destino.
- Agregar registros TXT en DNS.
- Asegurarse de que el dominio solo se usa en un tenant (si no, la verificación falla).
- Tomar nota del TTL del MX para saber cuánto tardarán los cambios en propagarse.
Antes de poder soltar el dominio en el tenant origen es necesario eliminarlo de todos los objetos que lo usan: direcciones de correo primarias y secundarias, grupos, buzones de recursos, políticas, etc., de lo contrario la plataforma no permitirá liberarlo.
Durante el corte se suele detener el flujo de correo entrante apuntando el MX a un valor temporal o a un servicio intermedio. Hay que esperar a que se vacíe la cola del origen. Después, hay que completar migraciones pendientes y finalmente dar de alta el dominio en el tenant destino con sus nuevos registros correctos.
Después del movimiento se validan envíos y recepciones, la firma DKIM, los informes DMARC y la entrega hacia y desde dominios externos, ajustando la política DMARC de un modo conservador (p=none) hacia configuraciones más estrictas (quarantine o reject) cuando todo está estable.
¿Cómo deber ser una migración entre inquilinos en Microsoft 365 bien planteada? Debe combinar un assessment honesto, un diseño sólido de coexistencia, el uso inteligente de CTUDM y capacidades cross-tenant, el apoyo de herramientas y/o partners cuando tiene sentido, una ejecución por oleadas con pruebas serias y un endurecimiento de seguridad y gobierno en el tenant destino. El objetivo es que el cambio se note poco en el día a día de los usuarios. Sin embargo, todo se traducirá en más control, más robustez y menos sustos a medio plazo.