Migración Microsoft 365 entre tenants (tenant-to-tenant): guía completa paso a paso para hacerlo sin perder datos

Resumen rápido: migración Microsoft 365 entre tenants en 7 puntos

1. Cuándo se requiere: fusiones y adquisiciones, rebranding o cambio de dominio, cambio de partner, carve-out o spin-off, consolidación de varios tenants de Office 365/Microsoft 365 en uno solo.
2. Qué cargas se mueven: Exchange Online (correo y calendarios), OneDrive, SharePoint, Microsoft Teams, dispositivos gestionados con Intune, automatizaciones de Power Platform (Power Apps, Power Automate, Power BI) y políticas de seguridad/compliance.
3. Qué usa Microsoft hoy: CTUDM (Cross-Tenant User Data Migration) para buzones y OneDrive, funcionalidades cross-tenant de Entra ID, capacidades nativas de migración de SharePoint y herramientas complementarias cuando el caso lo requiere.
4. Pilares del proyecto: assessment honesto del entorno actual, coexistencia bien diseñada, seguridad y cumplimiento desde el día 1 y movimiento de dominio cuidadosamente ensayado.
5. Riesgos típicos: compra tardía de CTUDM, movimiento de dominio improvisado, subestimación de Power Platform, enlaces de OneDrive/SharePoint rotos, políticas de retención y etiquetado no recreadas, comunicación insuficiente con usuarios.
6. Esfuerzo y roles implicados: equipo de IT, seguridad, negocio (responsables de procesos), legal/compliance en sectores regulados y, en muchos casos, un partner especializado que coordine la parte técnica y la gestión del cambio.
7. Cuándo tiene sentido apoyarse en un partner: cuando la organización está en un proceso de M&A, cuando hay requisitos regulatorios fuertes, cuando existen varios tenants históricos o cuando se desea minimizar el riesgo de interrupción y pérdida de datos.

¿Cuándo se necesita una migración Microsoft 365 entre tenants?

No todas las organizaciones necesitan una migración Office 365 entre tenants. Sin embargo, hay escenarios muy claros en los que este tipo de proyecto se vuelve casi inevitable. Identificar el propio caso ayuda a entender el nivel de esfuerzo, los riesgos y las alternativas disponibles.

Escenarios habituales

• Fusiones y adquisiciones (M&A): una empresa compra otra que ya utiliza Microsoft 365. Hay dos tenants y se desea consolidar personas, correo, documentos y seguridad en un único entorno.
• Carve-out o spin-off: una parte del negocio se separa y necesita su propio tenant (nuevo CIF, nuevo dominio, nuevo equipo directivo), trasladando solo una parte de usuarios y datos.
• Rebranding o cambio de dominio corporativo: se cambia el nombre comercial y el dominio de correo en toda la organización, lo que obliga a revisar dominios, UPN e identidades.
• Consolidación de tenants históricos: hay varios tenants de Office 365/Microsoft 365 heredados de adquisiciones anteriores y se quiere simplificar gestión, licenciamiento y gobierno.
• Cambio de partner o modelo de licenciamiento: se cambia de CSP/partner y se decide reordenar el tenant o mover parte de la organización a otro inquilino donde se centralizan las decisiones.
• Reorganización global: grupos multinacionales que quieren pasar de un modelo por país a un modelo regional o corporativo, unificando tenants por regiones o líneas de negocio.

En todos estos casos, la pregunta práctica no es solo “cómo migrar”, sino “qué se migra, qué se deja en origen, qué se recrea desde cero y en qué orden se hace” para minimizar el impacto en las operaciones.

Introducción a la migración Microsoft 365 entre tenants

Esta guía acompaña paso a paso para ejecutar una migración Microsoft 365 entre tenants (tenant-to-tenant) sin pérdida de datos. Se irán hilando cada fase —assessment, coexistencia, licencias CTUDM, Exchange, OneDrive/SharePoint, Teams, Intune y DNS— con explicaciones claras, ejemplos y enlaces oficiales. El objetivo es que el go-live sea predecible, la adopción fluya y el riesgo quede controlado.

La necesidad de una migración tenant-to-tenant de Microsoft 365 o de una migración Office 365 entre tenants suele aparecer en escenarios muy concretos: fusiones y adquisiciones, escisiones de negocio, reorganizaciones internas, cambios de partner o consolidación de varios tenants en uno solo para simplificar la gestión. En todos estos casos, no se trata solo de mover buzones o archivos: se trata de trasladar la forma en la que los equipos trabajan, colaboran y comparten información.

Por eso, además de la parte técnica, esta guía pone el foco en la perspectiva de negocio y en el impacto a las personas: qué notarán los usuarios en su día a día, cómo reducir la fricción en la adopción del nuevo tenant y qué decisiones conviene acordar con dirección antes de tocar nada. El propósito es que esta guía se convierta en una hoja de ruta práctica para los equipos de IT, seguridad y gobierno de datos que se plantean un cambio de tenant de Microsoft 365.

A lo largo del artículo se utilizan conceptos como Cross-Tenant User Data Migration (CTUDM), Entra ID (antiguo Azure AD), Exchange Online, OneDrive, SharePoint, Teams, Intune o Microsoft Purview. Se explica cuándo entran en juego, por qué son relevantes y qué buenas prácticas conviene seguir en una migración tenant-to-tenant de Office 365 / Microsoft 365 moderna.

1. Metodología y gobierno del proyecto

En la práctica: el objetivo de la metodología es que la migración Microsoft 365 entre tenants sea predecible, medible y entendible tanto para IT como para negocio.

Una metodología sólida reduce fricción, mejora la comunicación con negocio y acelera la adopción. Trabajar por oleadas permite aprender con un piloto, escalar con confianza y reservar un corte final bien ensayado. En una migración tenant-to-tenant de Microsoft 365, los errores de coordinación suelen impactar más que los errores puramente técnicos.

MSAdvance ejecuta por oleadas: piloto representativo → oleadas progresivas → corte y estabilización. Cada oleada incluye validaciones con negocio (UAT), sincronizaciones cuando aplican, métricas y comunicación por rol.

Un enfoque habitual es combinar marcos de trabajo ágiles con una planificación tradicional por hitos: talleres de arranque, diseño de arquitectura, ejecución técnica y fase de adopción. Para cada fase se definen claramente responsables, aprobadores y expectativas, evitando que la migración se perciba como un proyecto “solo de IT”.

Un buen gobierno del proyecto incluye también un comité de seguimiento (semanal o quincenal) con representantes de IT, negocio y seguridad, en el que se revisan riesgos, dependencias y decisiones pendientes. De este modo, se evita que temas clave como la retención legal, la clasificación de la información o la gestión de dispositivos se queden “para el final”.

2. Assessment: inventario, dependencias y límites

En la práctica: el assessment responde a “qué hay”, “qué se puede mover” y “qué bloquea una migración Office 365 tenant-to-tenant sin sorpresas”.

El inventario inicial marca la precisión del plan. Aquí se detectan bloqueos (retenciones, permisos especiales) y se dimensionan oleadas y tiempos antes de mover un solo dato. Una migración Microsoft 365 entre tenants sin un assessment riguroso suele derivar en sorpresas de último minuto y en conflictos entre equipos.

Es recomendable documentar también los requisitos regulatorios (sector financiero, sanitario, administración pública, etc.) y la ubicación de los datos (regiones de datacenter) para confirmar que el tenant destino cumple con las políticas de soberanía de datos de la organización.

Un buen resultado del assessment es un mapa de dependencias: qué aplicaciones dependen del correo, qué procesos de negocio usan flujos de Power Automate, qué áreas comparten sitios de SharePoint y qué usuarios son especialmente sensibles al cambio (dirección, atención al cliente, operaciones 24×7, etc.). Este mapa servirá para priorizar oleadas y preparar un plan de comunicación realista.

3. Coexistencia: identidad, Free/Busy y correo

En la práctica: la coexistencia bien diseñada permite que negocio siga trabajando mientras IT mueve datos entre tenants de Microsoft 365.

La coexistencia permite que la organización siga operando mientras se migra. Con identidad, calendarios y correo coordinados, las interrupciones se reducen al mínimo. Para el usuario final, lo ideal es que el cambio de tenant se perciba como un “ajuste” más que como una mudanza completa.

3.1 Identidad (Entra ID)

Se recomienda habilitar Cross-tenant access para colaboración B2B y, si es necesario automatizar altas/actualizaciones, utilizar Cross-tenant synchronization para provisionar invitados (B2B) con atributos mapeados.

• Cross-tenant synchronization (overview)
• Configurar sincronización

Una buena práctica es definir de antemano cómo quedarán los User Principal Name (UPN) y los alias de correo en el tenant destino. Esto evita que los usuarios sufran cambios de dirección innecesarios y simplifica la comunicación externa con clientes y proveedores.

3.2 Calendarios (Free/Busy)

Se recomienda configurar Organization Relationships en Exchange para que ambos tenants vean disponibilidad durante la coexistencia.

Connect-ExchangeOnline
New-OrganizationRelationship -Name "Rel-Tenant-Destino" `
  -DomainNames "contoso.com" -FreeBusyAccessEnabled $true `
  -FreeBusyAccessLevel LimitedDetails

Para negocio, la clave es que durante la migración se mantenga la posibilidad de agendar reuniones con normalidad. Antes de iniciar cada oleada conviene probar que los calendarios entre origen y destino muestran correctamente la disponibilidad (Free/Busy), especialmente en áreas críticas como ventas, soporte o dirección.

3.3 Correo y enrutamiento

Es recomendable mantener MX en el origen hasta el corte. Si se necesita redirigir temporalmente, se pueden usar conectores y reglas controladas y ensayar la entrega de extremo a extremo.

En escenarios complejos (por ejemplo, cuando conviven varios dominios o subempresas) es útil documentar claramente qué dominios se mueven, en qué orden y cómo se comportará el correo en cada fase. Un simple diagrama de flujo de enrutamiento ahorra muchas dudas a soporte de primer nivel.

4. Licenciamiento CTUDM y consideraciones legales

En la práctica: CTUDM es la pieza clave para una migración Office 365 tenant-to-tenant soportada por Microsoft, pero requiere planificación de licencias y cumplimiento.

La vía nativa requiere el Cross-Tenant User Data Migration (CTUDM) add-on por usuario migrado (cubre buzón y OneDrive). Es de “un solo uso” por objeto migrado. Se recomienda planificar compras con antelación y validar cumplimiento (GDPR, auditoría, retención) antes de iniciar la migración Microsoft 365 entre tenants.

A nivel legal, la migración de datos personales entre tenants suele implicar revisar acuerdos de tratamiento de datos, contratos con partners y documentación de cumplimiento. Es importante que el área legal conozca qué información se mueve, en qué plazos y con qué garantías de seguridad, especialmente en organizaciones sujetas a auditorías externas.

Aunque existen estrategias alternativas (exportaciones a PST, migraciones IMAP u otras aproximaciones), el enfoque con CTUDM ofrece soporte oficial, trazabilidad y menos riesgo operativo. En general, los enfoques alternativos deberían reservarse para escenarios residuales o excepcionales, no como estrategia principal.

Costes y esfuerzo de una migración Microsoft 365 entre tenants

El coste de una migración Microsoft 365 tenant-to-tenant no se limita a las licencias CTUDM. Intervienen factores como:

• Número de usuarios y buzones a migrar.
• Volumen de datos en Exchange Online, OneDrive y SharePoint.
• Complejidad de Power Platform, integraciones y aplicaciones de terceros.
• Cantidad de dispositivos gestionados por Intune y sistemas heredados.
• Requisitos regulatorios, de auditoría y retención de la información.
• Necesidad de soporte extendido, formación y gestión del cambio.

Por eso, en muchas organizaciones se opta por un enfoque mixto: parte del esfuerzo lo asume el equipo interno de IT y parte se delega en un partner especializado que ya ha realizado otros proyectos de migración entre organizaciones de Microsoft 365.

5. Migrar Exchange Online entre tenants de Microsoft 365

En la práctica: en Exchange Online el objetivo es que el correo siga fluyendo y que el usuario apenas note que se ha cambiado de tenant.

Migrar el correo de forma ordenada minimiza incidencias y consultas. Trabajar con lotes bien definidos y sincronizaciones antes del corte permite llegar al día cero con todo replicado. En una migración tenant-to-tenant de Exchange Online el diseño de los lotes suele marcar la diferencia entre un corte tranquilo y un fin de semana eterno.

1. Confianzas y consentimientos: cumplir los prerequisitos de la guía oficial.
2. Identidad destino: asegurarse de que el usuario existe/mapea en destino (B2B o cuenta local).
3. Lotes de migración: usar New-MigrationBatch con CSV y habilitar sincronización hasta el corte.
4. Post-corte: validar reglas, delegaciones, buzones compartidos y flujos SMTP.

Es recomendable separar en lotes diferentes a usuarios críticos (dirección, operaciones 24×7, atención al cliente) para poder dedicarles un soporte más cercano. También conviene etiquetar cada lote con un identificador claro (por área, país o unidad de negocio) que facilite leer los informes y correlacionar incidencias.

Connect-ExchangeOnline
$csv = [System.IO.File]::ReadAllBytes("C:\ctm\usuarios.csv")
New-MigrationBatch -Name "CTM-Oleada-01" -CSVData $csv `
  -TargetDeliveryDomain "contoso.mail.onmicrosoft.com" -AutoStart -AutoComplete:$false
Get-MigrationBatch -Identity "CTM-Oleada-01" | Get-MigrationUser | Get-MigrationUserStatistics -IncludeReport

Antes de cerrar definitivamente los buzones en el tenant origen, es buena práctica dejar un margen de observación, revisar que no existan rebotes extraños y confirmar con negocio que todas las listas de distribución, buzones de recursos y buzones compartidos siguen funcionando como se espera.

Cómo migrar Exchange Online entre tenants (en la práctica)

Con herramientas nativas de Microsoft (CTUDM)

1. Preparar la relación entre tenants: configurar acceso cross-tenant en Entra ID y revisar los prerequisitos de Cross-tenant mailbox migration (permisos, dominios verificados, etc.).
2. Definir el endpoint y los lotes: desde Exchange Online PowerShell, crear el endpoint de migración y los lotes con New-MigrationEndpoint y New-MigrationBatch (como en el ejemplo anterior).
3. Sincronizar antes del corte: mantener los lotes en sincronización incremental hasta la ventana de cambio acordada.
4. Cortar y validar: durante el corte, completar los lotes, revisar rebotes, delegaciones, buzones compartidos y reglas de transporte.

Con herramientas de terceros (Quest, BitTitan, etc.)

Cuando el proyecto es muy grande o se requiere reporting avanzado, suele combinarse CTUDM con soluciones de terceros:

• Quest On Demand Migration (Exchange): conecta ambos tenants, descubre buzones, mapea identidades, crea oleadas y ofrece paneles con el estado de cada buzón, errores y reintentos.
• BitTitan MigrationWiz (Mailbox Project): permite crear proyectos de buzones, configurar endpoints de origen/destino, importar usuarios por CSV, ejecutar un pre-stage (90–95 % del correo) y hacer un cutover final.
• Otros fabricantes: existen herramientas similares centradas en escenarios específicos (archivos de archivo, coexistencia prolongada, requisitos de auditoría, etc.).

Documentación oficial de Microsoft: Cross-tenant mailbox migration (Exchange Online).

6. Migrar OneDrive entre tenants de Microsoft 365

En la práctica: en OneDrive el mayor riesgo no es mover ficheros, sino los enlaces compartidos y las expectativas del usuario sobre “dónde está lo mío”.

OneDrive suele contener archivos de trabajo diario, borradores personales y documentación que aún no ha encontrado su lugar definitivo en SharePoint. Definir el tratamiento de versiones y comparticiones evita sorpresas el “día después” de la migración.

Cross-tenant OneDrive migration mueve contenido de usuarios al tenant destino. Es aconsejable planificar cómo tratar enlaces externos y comunicar a usuarios qué ocurrirá con vínculos existentes, sobre todo aquellos compartidos con clientes y proveedores.

1. Establecer la confianza y permisos entre tenants.
2. Precrear usuarios/grupos en destino y mapear identidades.
3. Ejecutar movimiento por usuario y validar acceso, versiones y comparticiones.

Desde el punto de vista del usuario, es importante aclarar que los archivos no “desaparecen”, sino que cambian de tenant. Un pequeño manual visual con capturas de pantalla sobre cómo localizar su nuevo OneDrive, cómo revisar la sección “Compartido” y cómo volver a compartir documentos clave suele reducir muchas consultas de soporte.

Cómo migrar OneDrive entre tenants (en la práctica)

Con herramientas nativas de Microsoft (CTUDM)

1. Preparar permisos cross-tenant: habilitar el escenario de Cross-tenant user data migration en Entra ID y en el centro de administración de OneDrive.
2. Validar OneDrive de destino: comprobar que los usuarios existen en el tenant nuevo, tienen licencia y su OneDrive está aprovisionado.
3. Configurar los mapeos: para cada usuario, definir origen y destino (normalmente mediante CSV o scripts) y lanzar la migración desde el centro de administración o vía PowerShell, según la versión disponible.
4. Verificar contenido y comparticiones: revisar versiones, carpetas críticas y enlaces compartidos internos; para enlaces externos, acordar con negocio qué ficheros se deben re-compartir tras la migración.

Con herramientas de terceros (Quest, BitTitan, etc.)

En organizaciones con mucho contenido en OneDrive, es habitual usar herramientas específicas de migración de documentos:

• Quest On Demand Migration (OneDrive): descubre los OneDrive de origen, mapea usuarios destino y permite mover contenido respetando permisos y comparticiones allí donde la API lo permite.
• BitTitan MigrationWiz (Document Project): crea proyectos por lotes, define endpoints, importa usuarios y ejecuta migraciones por fases, con informes por usuario y por archivo.

7. Migrar SharePoint Online entre tenants de Microsoft 365

En la práctica: en SharePoint el foco está en no romper la estructura de sites, permisos y automatizaciones sobre las que se apoyan los procesos de negocio.

SharePoint agrupa bibliotecas críticas, automatizaciones y permisos complejos. Es esencial auditar y diseñar cómo quedará la estructura en destino para preservar productividad y seguridad. En muchas organizaciones, una parte importante de la intranet, la documentación de proyectos y los procedimientos internos vive en SharePoint.

La migración de sites entre tenants está disponible con capacidades específicas (se recomienda revisar su estado y límites). Como alternativa, pueden usarse herramientas con mapeo de permisos y estructura de información.

• Auditar sites (propietarios, herencia, apps, uso real).
• Decidir el tratamiento de versiones y enlaces compartidos.
• Planificar recertificación de accesos tras el movimiento.

Un buen momento para plantear la migración SharePoint tenant-to-tenant es cuando la organización desea también ordenar su ecosistema de sites: archivar lo que ya no aplica, consolidar sites muy fragmentados y establecer una estructura clara (por área, país, producto, etc.) con hub sites y reglas de nomenclatura.

Cómo migrar SharePoint Online entre tenants (en la práctica)

Con herramientas nativas de Microsoft

1. Clasificar sites: identificar sites de equipo, de comunicación, hubs y sus dependencias (Power Automate, Power Apps, etc.).
2. Configurar el escenario cross-tenant: preparar la relación entre tenants y seguir los prerequisitos de Cross-tenant SharePoint migration.
3. Usar Migration Manager / APIs: desde el centro de administración de SharePoint, definir tareas de migración de sites y bibliotecas, o usar las APIs de migración cuando se buscan flujos más automatizados.
4. Validar permisos: tras el movimiento, revisar propietarios, miembros y visitantes, así como compartición externa y vínculos públicos.

Con herramientas de terceros (Quest, BitTitan, etc.)

• Quest On Demand Migration (SharePoint): descubre sites y colecciones, los mapea a estructuras de destino, migra contenido, permisos y algunas personalizaciones, con informes detallados.
• BitTitan MigrationWiz (Document/SharePoint): crea proyectos por site o por colección de sitios, define filtros de contenido y programa migraciones por ventanas para minimizar impacto.

Documentación oficial de Microsoft: Cross-tenant SharePoint migration.

8. Migrar Microsoft Teams entre tenants de Microsoft 365

En la práctica: en Teams lo importante es preservar los espacios de trabajo clave (equipos y canales) y gestionar expectativas sobre qué conversaciones se conservarán.

En Teams conviven archivos, chats, reuniones y apps. Suele funcionar bien mover archivos, recrear espacios clave y formar a cada rol para asegurar continuidad. Las decisiones sobre qué se replica y qué se vuelve a crear desde cero influyen directamente en la sensación de orden o caos tras la migración.

• Identificar equipos por proceso (ventas, finanzas, proyectos) y por criticidad.
• Recrear governance (nomenclatura, expiración, invitados) en destino.
• Planificar grabaciones (Stream on SharePoint) y pestañas/app integradas.

Conviene explicar que algunos elementos, como los chats 1:1 o las conversaciones antiguas de canales, pueden no migrarse de forma nativa en todos los escenarios. En esos casos, se puede optar por conservar la información en el tenant origen durante un tiempo acordado o exportar evidencias específicas si hay requisitos legales o de auditoría.

Cómo migrar Microsoft Teams entre tenants (en la práctica)

Con herramientas nativas de Microsoft

A día de hoy no existe un asistente nativo que migre de forma completa y automática todos los equipos, canales y chats de Microsoft Teams entre tenants. La estrategia suele combinar:

• Archivos y pestañas: migrar los archivos asociados a Teams usando la migración de SharePoint/OneDrive (los documentos viven en sitios de SharePoint).
• Equipos y canales: recrear equipos y canales en el tenant destino, de forma manual o mediante PowerShell/Graph.
• Mensajes de canal (opcional): cuando hay requisitos de cumplimiento, usar las APIs de migración de Teams para importar mensajes históricos al nuevo tenant.

Connect-MicrosoftTeams

$newTeam = New-Team -DisplayName "Ventas EU" -MailNickname "ventas-eu"
New-TeamChannel -GroupId $newTeam.GroupId -DisplayName "General"

Con herramientas de terceros (Quest, BitTitan, etc.)

Para simplificar el trabajo, muchas organizaciones optan por soluciones especializadas en migración de Teams:

• Quest On Demand Migration (Teams): descubre equipos, canales y miembros, permite mapearlos a grupos destino y migra archivos, pestañas y parte del historial según capacidades de la API.
• BitTitan MigrationWiz (Teams): crea proyectos específicos de Teams, mapea equipos origen/destino, migra archivos, pestañas, miembros y, en ciertos casos, conversaciones de canal.

Documentación oficial de Microsoft (APIs de migración de Teams): Import third-party platform messages to Teams.

9. Power Platform y otras cargas (Power Apps/Automate/BI)

En la práctica: el objetivo en Power Platform es que los procesos automatizados no se rompan por cambios de credenciales, conectores o entornos.

Muchas automatizaciones dependen de credenciales y conectores con permisos que cambiarán de tenant. Por eso, antes de cortar, es fundamental revisar propietarios y dependencias. Una migración Microsoft 365 entre tenants que ignore Power Platform puede romper procesos clave sin que el usuario lo vea venir.

• Inventario de apps/flows críticos y propietarios de negocio.
• Reautenticación de conexiones y actualización de credenciales en destino.
• Pruebas end-to-end con datos de ejemplo y validación con usuarios.

Además, es buena idea definir una estrategia de entornos (desarrollo, pruebas, producción) en el nuevo tenant si todavía no existe. De este modo, cada nueva automatización que nazca después de la migración podrá seguir un ciclo de vida más controlado y alineado con las políticas de gobierno de datos.

Cómo migrar Power Platform entre tenants (en la práctica)

Con herramientas nativas de Microsoft (ALM y soluciones)

1. Convertir aplicaciones y flujos en soluciones: empaquetar Power Apps, Power Automate y componentes relacionados en soluciones administradas o no administradas.
2. Exportar desde el entorno origen: descargar la solución (ZIP) desde el centro de Power Platform o usar pipelines/DevOps.
3. Importar en el entorno destino: subir la solución al entorno del nuevo tenant, resolver dependencias (conectores, roles, tablas de Dataverse, etc.) y aplicar actualizaciones.
4. Actualizar conexiones y credenciales: reconfigurar conectores (SharePoint, Exchange, SQL, etc.) con cuentas y permisos del nuevo tenant.

Con herramientas de terceros o automatización avanzada

En escenarios con muchos entornos y soluciones, se puede complementar con:

• Power Platform pipelines / Azure DevOps / GitHub: para automatizar exportación e importación de soluciones entre entornos y, cuando aplica, entre tenants.
• Scripts con PowerShell y Power Platform CLI: para repetir siempre igual tareas como exportar soluciones, aplicar variables de entorno o activar/desactivar flujos.

Documentación oficial de Microsoft: Mover recursos entre entornos o tenants de Power Platform · Microsoft Learn: Power Platform.

10. Migrar dispositivos e Intune entre tenants de Microsoft 365

En la práctica: en Intune la clave es que los dispositivos sigan cumpliendo políticas y que los usuarios puedan trabajar sin bloqueos inesperados.

Es necesario definir si se hará reenrolamiento, Autopilot desde cero o migración gradual. El objetivo es mantener el acceso y las políticas de seguridad sin fricciones apreciables para el usuario final, especialmente en equipos de campo o con trabajo remoto.

• Exportar configuración y recrear políticas equivalentes en destino.
• Evaluar Windows Autopilot (import de hashes, perfiles en el nuevo tenant).
• Planificar la experiencia de usuario (desasociación y unión al nuevo tenant).

Es recomendable diferenciar entre dispositivos corporativos y BYOD (propiedad del usuario). En estos últimos, la comunicación clara es clave: qué se va a hacer, cómo se verán afectados sus datos personales y qué pasos deberán seguir para volver a registrar el dispositivo si procede.

Cómo migrar dispositivos e Intune entre tenants (en la práctica)

Con herramientas nativas de Microsoft

No existe una “migración de Intune tenant-to-tenant” automática. En la práctica, la estrategia pasa por recrear la configuración en el nuevo tenant y reenrolar los dispositivos:

1. Exportar configuración: documentar o exportar políticas de cumplimiento, perfiles, apps y configuraciones desde el tenant origen para poder recrearlas en el destino.
2. Preparar el nuevo tenant: crear grupos, políticas y perfiles equivalentes, configurar Intune, Defender y, si aplica, co-gestión con Configuration Manager.
3. Usar Windows Autopilot cuando sea posible: registrar los dispositivos en Autopilot en el tenant nuevo y planificar un Autopilot reset o reprovisión para que salgan del tenant antiguo y se unan al nuevo.

Install-Script -Name Get-WindowsAutopilotInfo -Force
Get-WindowsAutopilotInfo -OutputFile .\AutopilotDevices.csv

4. Reenrolar dispositivos existentes: para equipos que no se puedan reprovisionar de cero, coordinar con los usuarios la salida del dispositivo del tenant origen y su unión al nuevo (por ejemplo, usando Company Portal y los asistentes de “Conectar a trabajo o escuela”).

Con herramientas de terceros

Algunas plataformas de migración (por ejemplo, soluciones de Quest orientadas a M365) ayudan a automatizar inventarios, generación de scripts y reporting, pero el paso clave sigue siendo el reenrolamiento del dispositivo en el nuevo tenant.

Documentación oficial de Microsoft: Introducción a Microsoft Intune · Windows Autopilot.

11. Movimiento del dominio: verificación, TTL y DNS

En la práctica: el movimiento de dominio es el momento más visible de la migración tenant-to-tenant: si se hace bien, el correo apenas se interrumpe; si se improvisa, el impacto se multiplica.

El cambio de dominio es el “corte” visible. Ensayar, bajar TTL con tiempo y preparar registros DNS para que el tránsito sea limpio es uno de los factores con más impacto en la percepción de calidad del proyecto.

# MX a Exchange Online Protection
MX @ 0 → contoso-com.mail.protection.outlook.com

# SPF / DKIM / DMARC
TXT @ "v=spf1 include:spf.protection.outlook.com -all"
CNAME selector1._domainkey → selector1-contoso-com._domainkey.contoso.onmicrosoft.com
TXT _dmarc "v=DMARC1; p=quarantine; rua=mailto:dmarc@contoso.com"

El éxito del movimiento de dominio se mide en minutos: cuánto tarda en estabilizarse el correo, cuántos rebotes aparecen y cuántas incidencias se reciben en la mesa de servicio. Tener un plan claro de rollback, aunque no se use nunca, aporta tranquilidad a IT y a dirección.

Guías: Quitar dominio · Agregar dominio · Registros DNS

12. Seguridad y cumplimiento: MFA, Acceso Condicional, Purview

En la práctica: la migración es un buen momento para subir el nivel de seguridad del tenant destino y cerrar brechas heredadas.

Es fundamental endurecer el tenant destino desde el primer día. Evitar atajos inseguros post-migración es clave para sostener el cambio y no abrir brechas temporales que luego cueste cerrar. Una migración Microsoft 365 tenant-to-tenant es una oportunidad para subir el nivel de seguridad.

La parte técnica debe ir acompañada de formación en buenas prácticas de seguridad: cómo identificar correos sospechosos, qué hacer ante un posible ataque de phishing, cómo compartir documentos de forma segura, etc. Unas pocas sesiones bien orientadas reducen mucho el riesgo humano tras el cambio de tenant.

13. Licencias Business Basic, Standard y Premium (y Enterprise)

En la práctica: la migración es una oportunidad para ajustar licencias de Microsoft 365 a la realidad actual de la organización.

El add-on CTUDM es independiente del plan. Tras la migración, es necesario elegir la licencia que equilibra coste, seguridad y productividad según el perfil de cada equipo. En muchas migraciones Microsoft 365 tenant-to-tenant se aprovecha para racionalizar licencias y ajustar el modelo a la realidad actual del negocio.

No es necesario que toda la organización use el mismo plan. Combinar diferentes licencias (por ejemplo, Business Premium para puestos críticos y Business Basic para perfiles esporádicos) permite optimizar costes sin renunciar a la seguridad allí donde más importa.

Se recomienda revisar las tablas oficiales de planes periódicamente para detalles y cambios.

14. Rendimiento, concurrencia y escalabilidad

En la práctica: el rendimiento determina si la migración avanza al ritmo esperado sin saturar ni a la plataforma ni al equipo de soporte.

Respetar límites de servicio, planificar horarios valle y monitorizar la salud de los lotes evita cuellos de botella y sorpresas en el corte. En una migración Microsoft 365 tenant-to-tenant, el rendimiento no depende solo del tamaño de los buzones sino también del ancho de banda disponible, la latencia y el número de procesos paralelos.

• Concurrencia de buzones: definir tamaño de lote y porcentaje por oleada (por ejemplo, 10–20% de la plantilla por ventana).
• Throttling y ventanas: ajustar la ejecución a límites del servicio y trabajar en horarios valle para reducir impacto.
• Reintentos y errores: revisar Get-MigrationUserStatistics y planificar reejecuciones granulares.

Es útil acordar desde el principio qué se considera un tiempo de migración aceptable y qué escenarios justificarían mover usuarios a otra ventana. Esto ayuda a tomar decisiones rápidas si se detecta cualquier degradación de rendimiento durante el proceso.

15. Métodos y herramientas de migración (nativo vs terceros)

En la práctica: no existe una única herramienta perfecta; se elige combinación según alcance, riesgo y plazos.

Conviene elegir la herramienta por alcance y riesgo, no solo por coste. La vía nativa suele ser la primera opción; se puede complementar con terceros o scripts cuando el caso lo requiera. Cada organización tiene un punto diferente entre flexibilidad, soporte oficial y tiempo disponible para la automatización.

En proyectos grandes, lo habitual es una combinación: enfoque nativo para la mayor parte de buzones y OneDrive, alguna herramienta de terceros para casos especiales (por ejemplo, escenarios de cumplimiento muy estrictos o consolidaciones complejas) y scripts a medida para tareas repetitivas que conviene estandarizar.

16. Checklists operativos (pre, durante, post)

En la práctica: los checklists convierten la migración en un proceso repetible y facilitan que nuevos miembros se incorporen sin perder contexto.

Checklists claros reducen el margen de error y hacen repetible el proceso entre oleadas y geografías. Además, sirven como guía para nuevos miembros del equipo o partners que se incorporen al proyecto.

16.1 Antes de migrar

• CTUDM adquirido y asignado a usuarios que migran.
• Cross-tenant access y sincronización (si aplica) configurados.
• Relaciones de organización (Free/Busy) creadas.
• Usuarios/licencias destino y OneDrive aprovisionados.
• Plan de comunicación y soporte por oleada.
• Backups/snapshots y planes de reversa documentados.
• Aprobación formal de negocio para el calendario de cortes.

16.2 Durante la migración

• Monitorizar lotes; tratar errores y reintentos.
• Resolver conflictos (delegaciones, reglas, alias).
• Ejecutar sincronizaciones incrementales hasta el corte.
• Informar periódicamente a negocio del progreso de cada oleada.

16.3 Después

• Actualizar MX/SPF/DKIM/DMARC y validar entrega.
• Revisar permisos en SharePoint/OneDrive; recertificar accesos.
• Deshabilitar POP/IMAP heredados y cerrar brechas temporales.
• Recoger feedback de usuarios y ajustar documentación y FAQs.

17. KPIs, UAT y aceptación con negocio

En la práctica: definir KPIs y UAT desde el principio ayuda a que negocio perciba la migración como un proyecto controlado y no como un riesgo.

Lo que no se mide no mejora. Definir KPIs antes de la primera oleada y alinear con negocio qué significa “éxito” en cada hito ayuda a que la migración se perciba como un proyecto controlado y orientado a resultados, no solo a tareas técnicas.

Las pruebas de aceptación con negocio (UAT) deben centrarse en escenarios reales: cómo se atiende una petición de un cliente, cómo se gestiona una incidencia, cómo se coordina un proyecto internacional, etc. Cuanto más se parezcan las pruebas al día a día, más valiosa será la validación.

18. Riesgos frecuentes y mitigaciones

En la práctica: anticipar riesgos permite decidir qué se quiere evitar a toda costa y qué se puede asumir con un plan de contingencia.

Anticipar riesgos ofrece margen de maniobra. Definir medidas preventivas y planes de contingencia simples y ensayados ayuda a que la migración se perciba como un proceso robusto, incluso cuando surgen imprevistos.

19. Scripts y snippets útiles (PowerShell/JSON) para migraciones tenant-to-tenant

En la práctica: los scripts no sustituyen al diseño, pero ahorran muchas horas en tareas repetitivas.

Estos ejemplos ayudan a estandarizar tareas recurrentes y a monitorizar el progreso de la migración entre tenants. No sustituyen a la planificación, pero sí reducen el tiempo necesario para ejecutar acciones repetitivas.

Connect-ExchangeOnline
Get-MigrationBatch | Select-Object Name,Status,TotalCount,InitialSyncCompleteTime
Get-MigrationUser | Get-MigrationUserStatistics -IncludeReport | `
  Select-Object Identity,ItemsTransferred,PercentComplete,ErrorSummary

Get-CASMailbox -ResultSize Unlimited | Set-CASMailbox -ImapEnabled:$false -PopEnabled:$false

{
  "displayName": "MFA para apps modernas",
  "conditions": {
    "users": { "includeUsers": ["All"] },
    "clientAppTypes": ["browser", "mobileAppsAndDesktopClients"]
  },
  "grantControls": { "operator": "OR", "builtInControls": ["mfa"] }
}

EmailAddress
ana.perez@empresa.com
juan.garcia@empresa.com

20. Preguntas frecuentes (FAQ ampliadas) sobre migración Microsoft 365 entre tenants

21. Recursos oficiales y enlaces externos para migración Microsoft 365 entre tenants

• Cross-tenant mailbox migration
• Cross-tenant OneDrive migration
• Cross-tenant SharePoint migration
• Entra ID — Cross-tenant access
• Entra ID — Cross-tenant synchronization
• Quitar dominio del tenant · Agregar dominio · Crear registros DNS
• Defender for Office 365
• Microsoft Information Protection (Purview)
• Microsoft Intune
• FastTrack — Cross-tenant migration
• Comparativa de planes M365

Se pueden explorar también los servicios relacionados de MSAdvance: migración Microsoft 365, arquitectura Azure, modern workplace y todo el catálogo en servicios.

22. Conclusión y siguientes pasos en una migración Microsoft 365 entre tenants

Una migración Microsoft 365 entre tenants sin pérdida de datos se apoya en cuatro pilares: assessment honesto, coexistencia bien diseñada, licencias CTUDM a tiempo y un corte de dominio cuidadosamente ensayado. Con pilotos con sentido, oleadas medibles y gobierno de seguridad desde el día 1, el go-live es predecible y la adopción fluye.

Como siguientes pasos, suele ser útil:

• Convertir esta guía en un checklist propio, adaptado al lenguaje y realidad del negocio.
• Definir un piloto acotado pero representativo (uno o dos departamentos clave).
• Establecer un plan de comunicación y formación que acompañe a cada oleada.

Por qué apoyarse en un partner especializado en migraciones tenant-to-tenant

Un partner especializado en migración Office 365 tenant-to-tenant aporta experiencia previa en M&A, conocimiento actualizado de las capacidades nativas de Microsoft y capacidad para coordinar equipos de IT, seguridad, legal y negocio. Esto se traduce en menos riesgo, menos improvisación y más foco interno en la operación diaria.

• Experiencia en escenarios complejos (fusiones internacionales, entornos regulados, múltiples tenants históricos).
• Plantillas, scripts y checklists ya probados en otros proyectos.
• Visión transversal de seguridad, cumplimiento y gestión del cambio.