La migración entre inquilinos de Microsoft 365 (tenant-to-tenant) se ha convertido en el pan de cada día en fusiones, adquisiciones, escisiones y reorganizaciones internas. Ya no hablamos solo de mover buzones: hablamos de trasladar identidades, correo, archivos, Teams, dispositivos, automatizaciones y políticas de seguridad sin romper el negocio por el camino.
Si estás en IT y te han dicho aquello de “no puede fallar y que el lunes todo el mundo entre como si nada”, esta guía es para ti. Aquí verás cómo funciona la migración cross-tenant de Microsoft 365, qué herramientas tienes (nativas y de terceros), qué límites impone la plataforma y cómo orquestar todo para que usuarios, seguridad y negocio queden cubiertos.+
Qué es una migración entre inquilinos de Microsoft 365 y cuándo se hace necesaria
Una migración tenant-to-tenant de Microsoft 365 es el proceso de mover usuarios, buzones, OneDrive, SharePoint, Teams, dominios, dispositivos y configuraciones de seguridad desde un tenant de Microsoft 365 a otro, intentando que el impacto en el día a día sea el mínimo posible.
En la práctica, esta situación aparece cuando coinciden cambios de negocio con entornos ya maduros en la nube: las empresas llevan años en Microsoft 365, han creado automatizaciones, intranets, equipos de Teams, políticas de retención y dispositivos gestionados con Intune, y de repente hay que “mover todo eso” a otro tenant.
Escenarios típicos: por qué una organización decide mover de tenant
Los motivos más habituales para una migración entre inquilinos de Microsoft 365 suelen repetirse y condicionan por completo el alcance del proyecto.
En un escenario de fusión o adquisición, dos compañías ya usan Microsoft 365, cada una con su tenant, y la dirección quiere que todos acaben colaborando en un único entorno: mismo dominio de correo, mismos Teams, mismo modelo de seguridad, mismas políticas de gobierno.
En un carve-out o spin-off, ocurre justo lo contrario: una parte del negocio se independiza y necesita su propio tenant, con nuevo dominio, nuevas licencias y solo una porción de usuarios y datos. Aquí el reto suele estar en definir qué se lleva la nueva entidad, qué se queda en origen y qué hay que recrear desde cero.
También son frecuentes las reorganizaciones internas y consolidaciones históricas: grupos que han ido acumulando tenants por país, por filial o por partner y ahora quieren simplificar. Unificar varios tenants ayuda a reducir costes, riesgos de configuración dispar y dolores de cabeza de soporte.
Por último, están los escenarios de cambio de dominio corporativo o rebranding: se modifica el nombre comercial, cambian las direcciones de correo y se aprovecha para rediseñar identidades (UPN), dominios y, en muchos casos, limpiar años de acumulación de sitios y equipos.
Metodología y gobierno: sin proyecto no hay migración que aguante
Una migración de este tipo no es solo “lanzar scripts”: requiere metodología, gobierno y una coordinación muy fina entre IT, seguridad, negocio y, a menudo, legal/compliance. La forma de organizar el proyecto marca más la diferencia que la herramienta concreta que se use.
Lo más sano es trabajar por oleadas de migración: un piloto representativo (usuarios reales, procesos de negocio reales), varias oleadas progresivas que permitan afinar y un corte final controlado del dominio. Cada oleada debería incluir plan de comunicación, requisitos de negocio, pruebas de usuario (UAT) y métricas claras.
En paralelo, conviene montar un comité de seguimiento con responsables de IT, seguridad, negocio y, cuando aplica, legal/compliance. Este comité sirve para revisar riesgos, dependencias, decisiones sobre retención de datos, tratamiento de información sensible, dispositivos críticos, etc.
Un punto clave del gobierno es dejar claro que la migración no es “un tema solo de sistemas”. Decisiones como qué se migra, qué se archiva y qué se deja morir son decisiones de negocio, no técnicas. Si esto no se alinea bien desde el principio, luego llegan las sorpresas.
Assessment inicial: inventario, dependencias y límites de la plataforma
Antes de tocar nada hay que responder, con datos, a tres preguntas: qué hay, qué se puede mover y qué bloquea la migración. Es la fase de assessment o descubrimiento, y suele marcar la calidad del plan posterior.
En identidad y correo, interesa identificar usuarios, grupos, dominios, relaciones híbridas, políticas de acceso condicional, MFA y licencias. En paralelo hay que inventariar buzones Exchange Online (tamaño, archivado, retenciones, cuotas, suspensiones legales, uso de cifrado con clave de cliente, etc.).
En colaboración y archivos, el foco está en OneDrive, SharePoint y Teams. En OneDrive: tamaño por usuario, número de elementos (el límite práctico son 1 millón por cuenta), enlaces compartidos internos/externos, cuentas con retenciones legales y cuentas que superan los 5 TB que impone Microsoft. En SharePoint: tipos de sitios (modernos, clásicos, de comunicación, conectados a grupos y a Teams), tamaño de colecciones (no más de 5 TB ni más de 1 millón de elementos por sitio en los escenarios nativos), flujos de trabajo legado (2010/2013), Power Apps y automatizaciones asociadas.
En Teams, conviene listar equipos, canales, pestañas, apps integradas, grabaciones de reuniones (Stream on SharePoint) y dependencias con procesos clave. Es habitual descubrir que muchas áreas han montado su propio “mini ERP” apoyado en Teams, SharePoint y Power Platform.
Finalmente, hay que mirar dispositivos e Intune: cuántos equipos están gestionados, qué plataformas (Windows, macOS, móviles), qué perfiles de cumplimiento existen, si hay Windows Autopilot en uso, qué apps se despliegan desde Intune y qué estrategias BYOD están en marcha. Todo ello condiciona cómo se planteará el reenrolamiento en el tenant destino.
Coexistencia: identidad, calendarios y correo mientras se migra
Para que negocio no se pare, hay que diseñar una coexistencia entre tenants que cubra, como mínimo, identidad, disponibilidad de calendarios (Free/Busy) y enrutamiento de correo entre origen y destino.
En identidad, Microsoft Entra ID ofrece cross-tenant access y cross-tenant synchronization. Con estas capacidades se pueden establecer relaciones de confianza entre tenants, definir cómo se trata a los usuarios B2B y, si hace falta, automatizar el aprovisionamiento de invitados con determinados atributos sincronizados.
En calendarios, Exchange Online permite configurar Organization Relationships para que los usuarios de ambos tenants vean la disponibilidad de sus compañeros mientras dura la coexistencia. Esto es crítico para que ventas, soporte, dirección o equipos de proyecto sigan pudiendo agendar sin volverse locos.
En correo, una práctica habitual es mantener el registro MX apuntando al tenant de origen hasta el momento del corte, usar CTUDM o lotes de migración para tener los buzones en sincronización y, cuando llegue la ventana acordada, mover MX, SPF, DKIM y DMARC al tenant destino. Ensayar este corte en un entorno controlado o con dominios de prueba ayuda mucho.
CTUDM y licenciamiento: la pieza nativa para migrar buzones y OneDrive
Microsoft ha introducido el add-on Cross-Tenant User Data Migration (CTUDM), que es hoy el pilar de las migraciones soportadas entre inquilinos para buzones de Exchange Online y cuentas de OneDrive. Cada usuario que se migra necesita esa licencia asociada, y es de “uso único” por objeto.
A la hora de planificar, no basta con calcular solo CTUDM: el coste total de proyecto mezcla licencias Microsoft 365, esfuerzo interno del equipo, posibles servicios de un partner y tiempo empleado en pruebas y soporte. Migrar 200 buzones de 20 GB no es lo mismo que mover 5 000 usuarios con buzones grandes, millones de archivos en SharePoint y docenas de flujos de Power Platform críticos.
Además, hay un componente legal que no se puede obviar: mover datos personales entre tenants implica revisar contratos de tratamiento de datos, acuerdos con partners, ubicaciones de datacenter y cumplimiento (GDPR, sector financiero, sanitario, administración pública, etc.). Legal y compliance tienen que estar informados de qué se mueve, cuándo y con qué garantías.
Migración de Exchange Online entre tenants
El correo y los calendarios suelen ser la carga más sensible: si fallan, el proyecto “está roto” aunque todo lo demás haya ido bien. Por eso la migración tenant-to-tenant de Exchange Online se suele diseñar con especial mimo.
Con las capacidades de cross-tenant mailbox migration, los administradores configuran en el tenant destino una aplicación de migración en Microsoft Entra, un endpoint de migración y una relación de organización con el tenant origen. En el origen, se concede consentimiento a esa aplicación, se limitan los buzones que se pueden mover mediante grupos de seguridad habilitados para correo y se establece la relación de salida.
Los usuarios que se quieren migrar deben existir en el tenant destino como MailUser, con atributos críticos copiados: ExchangeGUID y ArchiveGUID (si hay archivo habilitado), LegacyExchangeDN transformado en direcciones X500, UPN y dirección SMTP principal alineadas con el nuevo dominio y targetAddress apuntando al buzón actual en el tenant origen.
Una vez todo preparado, desde el tenant destino se crean lotes de migración (MigrationBatch) con CSV, se habilita la sincronización y se dejan corriendo hasta el corte. El día D, se completan los lotes, se valida el estado de cada buzón (incluyendo permisos de acceso completo, “Enviar como”, “Enviar en nombre de”, buzones compartidos y de recursos) y se coordina el cambio de perfil de Outlook, que en muchos casos habrá que recrear porque el buzón estará ahora en otro tenant con otra identidad.
Entre los límites importantes de Exchange Online en estos escenarios están la imposibilidad de mover buzones con ciertos tipos de suspensión aplicada, la limitación a un máximo de 12 archivos auxiliares para buzones con archivo autoexpandido, y el hecho de que no se migran carpetas públicas ni mensajes de Teams almacenados en carpetas de chat del buzón.
Migración de OneDrive entre inquilinos
En OneDrive el problema no suele ser mover ficheros, sino los enlaces compartidos y las expectativas de los usuarios sobre dónde está “lo suyo” y qué va a ocurrir con documentos compartidos con clientes y proveedores.
En el escenario nativo de cross-tenant OneDrive migration, los administradores de SharePoint Online establecen una relación entre tenants con Set-SPOCrossTenantRelationship, preparan un archivo de asignación de identidades origen-destino y lanzan las migraciones de cuentas con Start-SPOCrossTenantUserContentMove. Se pueden tener hasta 4 000 cuentas en cola a la vez, con la ventaja de que los datos nunca salen de la nube de Microsoft y OneDrive solo pasa unos minutos en modo solo lectura.
Hay que vigilar varios límites: ruta máxima de 400 caracteres, máximo 5 TB y 1 millón de elementos por cuenta, y problemas con ciertos caracteres (por ejemplo, apóstrofos en URLs). Cuentas en suspensión legal no se pueden migrar hasta quitar la retención y volver a aplicarla en el tenant destino.
Una vez completada la migración, Microsoft coloca redirecciones automáticas desde la URL antigua hacia la nueva, de forma que los enlaces existentes siguen funcionando mientras el tenant origen exista. Los permisos se mantienen siempre que los usuarios y grupos estén correctamente mapeados en el archivo de identidades.
Migración de SharePoint Online entre tenants
Con SharePoint, el foco se desplaza a no romper la estructura de sitios, permisos y automatizaciones que soportan procesos de negocio. Aquí viven intranets, sitios de proyectos, documentación de calidad, formularios y flujos críticos.
Microsoft ha incorporado capacidades de migración de sitios de SharePoint entre inquilinos usando PowerShell de SharePoint Online. Se pueden programar hasta 4 000 migraciones de sitios en cola, y al completarse se mantiene una redirección para que los enlaces antiguos sigan llevando al contenido en su ubicación nueva.
Los tipos de sitio soportados incluyen sitios modernos (con o sin grupo de Microsoft 365), sitios conectados a Teams, sitios clásicos y sitios de comunicación. Se migran documentos, estructura de carpetas, permisos a nivel de usuario y grupo, versiones e información básica de metadatos (fechas de creación/modificación y autores).
No se mueven ciertos elementos: aplicaciones, flujos de trabajo 2010/2013, tareas de Power Automate o Power Apps embebidas, que hay que recrear en el tenant destino. Tampoco se soportan sitios con más de 5 TB o más de 1 millón de elementos, y los problemas de rutas largas (más de 400 caracteres) se resuelven, igual que en OneDrive, moviendo o renombrando carpetas y archivos.
Especial atención requieren las etiquetas de confidencialidad. Si los archivos están protegidos con etiquetas que aplican cifrado, es posible que la experiencia sea mala después de migrar. Se recomienda descifrar o retirar etiquetas antes del movimiento (por ejemplo, con Unlock-SPOSensitivityLabelEncryptedFile) y aplicar después nuevas etiquetas alineadas con las políticas del tenant destino. Las etiquetas con permisos definidos por el usuario directamente bloquean la migración hasta que se retiren.
Entornos Multi-Geo y particularidades cross-tenant
Cuando los tenants son Multi-Geo, la cosa se complica un poco: hay que configurar confianzas entre todas las instancias geográficas implicadas, cargar el archivo de asignación de identidades en cada destino y recordar que el límite de 4 000 migraciones en cola se aplica por instancia de origen. Además, si un sitio acaba en la geo equivocada, no se puede mover entre instancias del mismo tenant usando la misma característica cross-tenant; habría que usar los comandos específicos multi-geo para recolocarlo.
Microsoft Teams: lo que se puede mover y lo que se suele recrear
En Teams, la realidad a día de hoy es que no existe un botón mágico que copie tal cual todos los equipos, canales y chats entre tenants. La estrategia típica combina varias piezas.
Por un lado, los archivos asociados a equipos y canales se mueven con la migración de SharePoint/OneDrive, ya que viven en sitios de SharePoint y carpetas concretas. Por otro, se recrean equipos y canales en el tenant destino, bien de forma manual, bien con PowerShell/Graph o con herramientas de terceros.
Las conversaciones históricas de canal y, sobre todo, los chats 1:1 o de grupos pequeños, se suelen abordar caso por caso. Las APIs de migración de Teams permiten importar mensajes desde plataformas externas, pero no hay una experiencia masiva automatizada y pulida para mover todo el historial entre tenants. Muchas organizaciones optan por mantener el tenant origen accesible durante un tiempo para consultas históricas, mientras que los nuevos equipos y conversaciones nacen ya en el tenant destino.
Es importante gestionar expectativas: los usuarios deben saber qué se mantiene, qué se recrea y qué quedará accesible solo durante un periodo de gracia. Y, de paso, es una oportunidad fantástica para limpiar equipos obsoletos, unificar nomenclatura y aplicar reglas de caducidad.
Power Platform: que no se rompan los flujos invisibles
Una de las mayores fuentes de sustos en migraciones tenant-to-tenant son los procesos automatizados en Power Apps, Power Automate y Power BI. Muchas veces nadie tiene un inventario claro, pero los usuarios dependen de ellos a diario para tareas que van desde aprobar gastos hasta disparar notificaciones de incidencias.
La estrategia recomendable es hacer un inventario de aplicaciones y flujos críticos, sus propietarios de negocio y los conectores que usan. Después, empaquetarlos en soluciones, exportarlos del entorno origen e importarlos en el destino, donde habrá que reconfigurar conexiones y credenciales.
Aprovechando la migración, tiene sentido estandarizar un mínimo de ALM (Application Lifecycle Management) en Power Platform: separar entornos de desarrollo, pruebas y producción en el nuevo tenant, usar soluciones administradas donde proceda y documentar qué depende de qué. Así se reduce mucho el riesgo de que un cambio aparentemente menor rompa un proceso crítico después del movimiento.
Intune y dispositivos: reenrolar sin dejar a la gente tirada
Con Intune, no hay una “migración de Intune entre tenants” automática como tal. Lo que se hace es recrear la configuración en el tenant destino y planificar el reenrolamiento de dispositivos, apoyándose en Windows Autopilot cuando es posible.
Primero se exportan o documentan políticas de cumplimiento, perfiles de configuración, despliegues de aplicaciones, perfiles de seguridad y ajustes de Defender en el tenant origen. Luego se crean equivalentes en el destino, alineados con la nueva estrategia de seguridad y gobierno.
En cuanto a los equipos, se decide si se van a reprovisionar con Autopilot (ideal cuando se puede aprovechar para dejar los dispositivos “limpios” y unidos ya al nuevo tenant) o si se usará un proceso de salida y entrada manual con la experiencia “Conectar a trabajo o escuela” y el Portal de Empresa. Para dispositivos personales (BYOD) hace falta comunicación muy clara sobre qué se borra, qué no y cómo volver a registrar el dispositivo.
Movimiento de dominio: MX, SPF, DKIM y DMARC sin sustos
El cambio de dominio suele ser el momento más visible de una migración entre inquilinos de Microsoft 365. Si el correo deja de entrar o empiezan los rebotes extraños, todo el mundo lo nota.
La teoría es conocida: semanas antes del corte se baja el TTL de los registros DNS del dominio principal, se verifica el dominio en el tenant destino (sin poder usarlo todavía como principal), se preparan las configuraciones de SPF, DKIM y DMARC y se prueban con dominios secundarios si hace falta.
En el momento del cambio, hay que asegurarse de que el dominio no está en uso en ningún objeto del tenant origen (UPN, direcciones de correo, grupos, aplicaciones, etc.), se elimina del tenant antiguo, se agrega en el nuevo y se actualizan los registros MX/SPF/DKIM/DMARC en el proveedor DNS. Tras eso, se monitoriza el flujo de correo, se revisan cuarentenas y se ajusta la política DMARC (empezar con p=none y subir a quarantine/reject cuando todo esté estable).
Disponer de un plan de rollback documentado, aunque no se llegue a usar nunca, da mucha tranquilidad a todo el mundo: dirección, soporte y, sobre todo, al equipo técnico que estará vigilando durante la ventana de cambio.
Herramientas de terceros para migración entre tenants
Aunque las capacidades nativas de Microsoft han mejorado mucho (CTUDM, cross-tenant migrations de Exchange, OneDrive y SharePoint, APIs de Teams, etc.), en muchos proyectos grandes se complementan con herramientas de terceros especializadas.
Soluciones como Quest On Demand Migration, Cloudiway o BitTitan MigrationWiz ofrecen paneles centralizados para diseñar oleadas, mapear identidades, mover correo, documentos, Teams y, en algunos casos, historiales de conversación, con informes muy detallados para auditoría y troubleshooting.
Estas herramientas ayudan especialmente cuando se requiere reporting avanzado, reintentos automatizados, coexistencia prolongada o migraciones entre múltiples plataformas (por ejemplo, cuando parte del entorno viene de Google Workspace u otros servicios). Suelen trabajar en combinación con las APIs y capacidades de Microsoft, no en contra de ellas.
Frente a los enfoques puramente manuales (PST, IMAP, scripts caseros), el uso de herramientas maduras reduce el riesgo operativo y acelera mucho las migraciones con miles de usuarios, siempre y cuando se configuren bien y se prueben antes con pilotos realistas.
Seguridad y cumplimiento: endurecer el tenant destino desde el día uno
Una migración tenant-to-tenant bien planteada se aprovecha para subir el listón de seguridad en el tenant destino. Es el momento ideal para revisar autenticación multifactor (MFA), reglas de acceso condicional, configuración de Defender, protección frente a phishing y políticas de gobernanza de información en Microsoft Purview.
Ese refuerzo técnico debe ir acompañado de formación básica a los usuarios: cómo reconocer correos sospechosos, cómo compartir documentos de forma segura, qué hacer ante un comportamiento extraño de la cuenta, etc. Unas cuantas sesiones breves y bien hechas evitan muchos incidentes justo después del cambio, que es cuando más vulnerables están los usuarios a la confusión.
Checklists operativos y errores frecuentes
Convertir todo lo anterior en checklists claros (antes, durante y después de cada oleada) es lo que acaba marcando la diferencia en la ejecución diaria. Así se evita que pasos críticos se pierdan en un correo o en una conversación improvisada.
Entre los errores más habituales están comprar CTUDM demasiado tarde, improvisar el movimiento de dominio, infravalorar Power Platform, olvidarse de Intune y no recrear bien las políticas de retención y etiquetado. Otro clásico es una comunicación pobre con usuarios, que se traduce en pánico generalizado por cambios de contraseña, perfiles de Outlook que no conectan y Teams donde “faltan cosas”.
Trabajar con KPIs claros (porcentaje de buzones migrados sin incidencias, número de tickets por usuario, tiempo medio de resolución, estabilidad del correo tras el corte, etc.) y acordar criterios de aceptación con negocio ayuda a mantener la migración bajo control y demostrar que el proyecto no es solo “mover datos”, sino proteger cómo trabaja la organización.
Una migración entre tenants de Microsoft 365 bien ejecutada combina buen análisis inicial, coexistencia cuidada, uso inteligente de CTUDM y/o herramientas de terceros, gobierno sólido y una comunicación honesta con los usuarios. Cuando todas estas piezas encajan, el cambio de tenant deja de ser un salto al vacío y se convierte en una transición controlada, donde el negocio sigue funcionando mientras IT reordena, endurece la seguridad y deja la casa más limpia que antes.