Resumen rápido: qué se puede migrar entre tenants Microsoft 365

En una frase: Microsoft 365 puede trasladarse a otro tenant, pero el proyecto real combina migración nativa, identity mapping, herramientas especializadas, Microsoft Graph, PowerShell, recreación y, cuando procede, rediseño.

Tabla completa: qué se puede migrar entre tenants de Microsoft 365

La siguiente tabla sirve como referencia inicial para valorar una migración. “Se puede migrar” no significa necesariamente que el objeto vaya a quedar idéntico en el nuevo tenant. Algunos servicios conservan contenido y metadatos; otros necesitan crear previamente el contenedor destino, remapear identidades o reconstruir parte de la configuración.

Las capacidades, requisitos de licencia, límites y disponibilidad de Microsoft 365 pueden cambiar. La estrategia definitiva debe verificarse contra la documentación vigente y las características reales de los tenants de origen y destino.

¿Qué significa realmente que una carga se pueda migrar?

Que un servicio pueda migrarse no significa necesariamente que todo su historial, configuración, permisos, identificadores y dependencias aparezcan idénticos en el nuevo tenant.

En una migración Microsoft 365 conviene distinguir cinco situaciones diferentes:

¿Se puede migrar Exchange Online entre tenants?

Sí. Microsoft dispone de Cross-Tenant Mailbox Migration para trasladar buzones de Exchange Online entre tenants. Exchange es además uno de los workloads que Microsoft 365 Migration Orchestrator puede coordinar dentro de una migración multi-workload.

El proceso mueve el contenido del buzón, pero no traslada la identidad de Microsoft Entra ID. Antes de iniciar la migración, el usuario correspondiente debe existir y estar preparado correctamente en el tenant destino.

¿Qué contenido de Exchange puede moverse?

Dentro del alcance compatible se encuentra el contenido que el usuario utiliza habitualmente:

• correo electrónico;
• estructura de carpetas;
• contactos;
• calendario;
• tareas;
• notas y otros elementos compatibles.

El detalle técnico de la migración depende del escenario, de las identidades preparadas y de las configuraciones existentes en ambos tenants.

¿Se pueden migrar Shared Mailboxes?

Sí. Los buzones compartidos pueden incluirse en una estrategia cross-tenant, pero conviene separar dos conceptos: contenido del buzón y delegaciones.

Un shared mailbox puede tener Full Access, Send As, Send on Behalf, aliases, reglas y relaciones con usuarios que se migrarán en diferentes oleadas. Por tanto, no debe considerarse terminado únicamente porque sus correos ya aparezcan en destino.

¿Qué ocurre con Online Archive?

Los archive mailboxes deben incluirse expresamente en la preparación del usuario y en el identity mapping. Atributos como ArchiveGuid, el licenciamiento, la configuración de archivo y las políticas de retención pueden condicionar el movimiento.

Holds y compliance

Los Holds pueden bloquear movimientos cross-tenant. Esta comprobación debe hacerse antes de crear las oleadas. No es recomendable descubrir una retención durante la ventana de cutover.

Además, retirar un Hold no es una decisión meramente técnica. Cualquier cambio debe coordinarse con los responsables de cumplimiento y con las obligaciones legales de la organización.

¿Se mueven aliases, grupos y delegaciones con el mailbox?

No debe suponerse que todos los objetos asociados al buzón viajan con él. Distribution Lists, Microsoft 365 Groups, mail-enabled security groups, transport rules, aliases y determinadas delegaciones necesitan un tratamiento separado.

Fuente oficial: Microsoft Learn — Cross-tenant mailbox migration.

¿Se puede migrar OneDrive entre tenants?

Sí. Microsoft dispone de Cross-Tenant OneDrive Migration y OneDrive también puede formar parte de los lotes coordinados por Microsoft 365 Migration Orchestrator.

La migración utiliza Cross-Tenant Identity Mapping para relacionar los usuarios y grupos del tenant origen con sus equivalentes en destino. Esto permite transformar permisos de identidades correctamente mapeadas.

¿Se conservan permisos y enlaces?

Los permisos pueden conservarse cuando las identidades implicadas están correctamente preparadas y mapeadas. Microsoft también puede colocar redirecciones desde la ubicación anterior hacia la nueva.

Esto resulta especialmente útil cuando todavía existen enlaces antiguos en correos, documentos o aplicaciones.

La gran limitación: OneDrive nativo es one-and-done

Este detalle condiciona el cutover. Si la estrategia elegida necesita copiar inicialmente los datos, dejar que el usuario siga trabajando y ejecutar después varias sincronizaciones diferenciales, el mecanismo nativo puede no ser el método más adecuado para ese proyecto concreto.

Holds y Customer Key

Un OneDrive sujeto a determinadas retenciones puede quedar bloqueado para el movimiento. Microsoft también documenta restricciones relacionadas con Service Encryption y Microsoft Purview Customer Key en el tenant origen.

Estas condiciones deben formar parte del assessment técnico previo.

¿Debe existir ya el OneDrive destino?

La identidad y el licenciamiento deben estar correctamente preparados, pero el aprovisionamiento del sitio destino debe respetar los requisitos de la herramienta. Crear estructuras de destino sin comprobar previamente cómo se realizará la migración puede complicar posteriormente el movimiento.

Si necesitas entrar en detalle sobre esta carga, puedes consultar nuestra guía de migración de OneDrive entre tenants de Microsoft 365.

Fuente oficial: Microsoft Learn — Cross-tenant OneDrive migration.

¿Se puede migrar SharePoint Online entre tenants?

Sí, con condiciones. Microsoft dispone de Cross-Tenant SharePoint Migration, una capacidad específica para trasladar sitios SharePoint entre tenants. Este proceso es independiente de Microsoft 365 Migration Orchestrator.

La herramienta utiliza identity mapping para transformar permisos y puede mantener redirecciones hacia determinadas ubicaciones del nuevo tenant.

¿Qué tipos de sitios pueden formar parte de una migración?

Microsoft documenta soporte para diferentes tipos de sitios SharePoint, incluyendo escenarios modernos y sitios conectados a Microsoft 365 Groups, siempre que se cumplan los prerrequisitos correspondientes.

¿Es incremental?

No. Al igual que Cross-Tenant OneDrive Migration, el proceso nativo de SharePoint se plantea como un movimiento one-and-done y no como una herramienta de sincronización delta continua.

¿Puede existir ya contenido en el sitio destino?

Cross-Tenant SharePoint Migration no debe interpretarse como un mecanismo de merge entre dos sitios existentes. La preparación del destino debe realizarse siguiendo los requisitos documentados antes de iniciar el movimiento.

¿Qué ocurre con Power Apps, Power Automate y workflows?

Mover un sitio SharePoint no garantiza que las automatizaciones relacionadas queden funcionando automáticamente en destino.

Hay que revisar, entre otros:

• Power Automate flows;
• Power Apps;
• connections;
• connection references;
• owners;
• URLs;
• web parts;
• integraciones externas;
• workflows heredados.

También puedes ampliar esta información en nuestra guía completa de migración de SharePoint entre tenants.

Fuente oficial: Microsoft Learn — Cross-tenant SharePoint migration.

¿Qué se puede migrar de Microsoft Teams entre tenants?

Se pueden trasladar diferentes componentes de Microsoft Teams, pero Microsoft Teams no se mueve como una única unidad. Microsoft 365 Migration Orchestrator contempla chats y reuniones de usuario dentro de su ámbito, mientras que Teams, Channels y sitios SharePoint compartidos requieren un tratamiento separado.

La razón es sencilla: bajo el nombre “Teams” conviven múltiples servicios de Microsoft 365.

Teams Chats

Los chats forman parte del alcance actual de Microsoft 365 Migration Orchestrator. Aun así, el resultado debe interpretarse dentro de las limitaciones documentadas para participantes, identidades y threads.

Una migración debe buscar conservar el historial compatible y la continuidad del usuario, no prometer que cada conversación se comporte exactamente igual que en el tenant anterior.

Teams Meetings

Las reuniones también pueden formar parte del proceso coordinado por Microsoft 365 Migration Orchestrator y tienen dependencias con Exchange Online.

Por eso no conviene diseñar Exchange y Teams Meetings como dos proyectos completamente independientes.

Teams y Channels

El Team compartido y sus Channels requieren una estrategia específica. La creación de la estructura destino, sus miembros, grupos, sitios SharePoint, aplicaciones y otros componentes debe coordinarse fuera del simple movimiento de chats de usuario.

Conversaciones de canales

Microsoft Graph dispone de APIs de migración para importar mensajes históricos en Teams y canales dentro de escenarios soportados.

Estas APIs pueden conservar propiedades históricas como autor y timestamp cuando el escenario y el contenido son compatibles. Sin embargo, importar mensajes no equivale a mover automáticamente todo el Team.

Archivos de Teams

Los archivos de los canales se almacenan en SharePoint. Por tanto, la estrategia de Teams debe coordinarse con SharePoint. Los archivos compartidos dentro de chats privados dependen además de OneDrive.

Planner

Un Team puede utilizar uno o varios planes de Planner. Estos planes no deben darse por trasladados simplemente porque se haya creado el Team equivalente en destino.

OneNote, Lists, tabs y aplicaciones

También deben inventariarse individualmente. Algunas pestañas son únicamente referencias hacia otro recurso; otras contienen aplicaciones o configuraciones que dependen de IDs del tenant anterior.

Grabaciones de reuniones

Las grabaciones modernas suelen almacenarse en OneDrive o SharePoint. El archivo puede formar parte de la estrategia de esos workloads, pero la relación con la reunión original y la experiencia posterior del usuario deben validarse por separado.

Para profundizar puedes consultar nuestra guía completa de migración de Microsoft Teams entre tenants.

Fuentes oficiales: Microsoft 365 Migration Orchestrator · Microsoft Graph — Teams migration APIs.

¿Se puede migrar Microsoft Planner entre tenants?

Parcialmente. Microsoft Graph permite trabajar con planes básicos, buckets y tareas, pero Microsoft Planner no dispone de una migración tenant-to-tenant equivalente a Cross-Tenant Mailbox Migration o Cross-Tenant OneDrive Migration.

Copy Plan no es Tenant Migration

La función de copiar un plan puede ser útil en determinados escenarios, pero no debe confundirse con una migración completa entre organizaciones.

Un Planner real puede incluir:

• planes;
• buckets;
• tasks;
• assignments;
• fechas y prioridades;
• descripciones;
• checklists;
• labels;
• attachments;
• comentarios;
• relación con el Microsoft 365 Group o Team.

Microsoft Graph permite leer y recrear distintos elementos, lo que hace posible diseñar una migración programática. Sin embargo, deben analizarse las propiedades que realmente tienen equivalencia en destino.

Planner Premium

Los planes Premium necesitan un análisis independiente. No debe asumirse que una estrategia desarrollada para Planner Basic sirve automáticamente para cualquier tipo de plan de Planner.

Conclusión: Planner puede formar parte de una migración completa, pero normalmente requiere recreación, Microsoft Graph o capacidades especializadas y no un simple “Move plan”.

Fuente oficial: Microsoft Graph — Planner.

¿Se puede migrar Power BI entre tenants?

Parcialmente. Microsoft documenta diferentes patrones para trasladar artefactos de Power BI y Fabric entre tenants, pero también advierte de que el proceso puede requerir un esfuerzo manual significativo.

Power BI debe analizarse por componentes. Contar únicamente informes suele infravalorar la complejidad real.

El informe es solo la parte visible

Un report puede abrir correctamente en destino y seguir estando incompleto porque su semantic model no refresca, faltan credenciales o el gateway todavía pertenece al tenant anterior.

Por eso un inventario serio debe incluir:

• workspaces;
• reports;
• semantic models;
• dataflows;
• gateways;
• datasources;
• credenciales;
• refresh schedules;
• RLS;
• capacidades;
• Power BI Apps;
• artefactos Fabric.

También puedes consultar nuestra guía de migración de Power BI.

Fuente oficial: Microsoft Learn — Power BI tenant migration patterns and strategies.

¿Se puede migrar Microsoft Intune entre tenants?

Parcialmente. Determinadas políticas y configuraciones de Microsoft Intune pueden exportarse, automatizarse o reconstruirse mediante Microsoft Graph y PowerShell, pero los dispositivos deben volver a inscribirse en el tenant destino.

Políticas y Configuration Profiles

Microsoft proporciona orientación y ejemplos para exportar e importar parte de la configuración de Intune, pero esto no equivale a copiar todo el tenant de administración de endpoints.

Deben revisarse por separado:

• Configuration Profiles;
• Compliance Policies;
• Endpoint Security;
• aplicaciones;
• assignments;
• scripts;
• remediations;
• certificados;
• Wi-Fi;
• VPN;
• BitLocker;
• Windows Autopilot;
• Company Portal;
• Defender;
• Conditional Access.

Los dispositivos deben volver a inscribirse

Esta es la principal diferencia frente a una migración de correo o archivos.

El endpoint mantiene una relación de administración con el tenant origen. Para gestionarlo desde el tenant destino debe establecer una nueva relación con Microsoft Entra ID e Intune.

El procedimiento puede variar según:

• Windows;
• macOS;
• iOS / iPadOS;
• Android;
• tipo de dispositivo;
• método de enrollment;
• propiedad corporativa o BYOD.

Autopilot, Entra Join y BitLocker

Estos elementos requieren un runbook específico. Debe quedar definido cómo pasará el dispositivo al nuevo tenant, qué ocurrirá con Autopilot, qué claves de recuperación deben conservarse y cuándo volverá el endpoint a estar compliant.

Fuente oficial: Microsoft Learn — Intune migration guide.

¿Se pueden migrar Power Apps, Power Automate y Dataverse entre tenants?

Sí, en determinados escenarios. Microsoft dispone de capacidades tenant-to-tenant para mover ciertos entornos de Power Platform entre organizaciones, aunque no todos los tipos de entorno ni todos los componentes están soportados.

Production y Sandbox

Microsoft documenta escenarios de movimiento para determinados entornos Production y Sandbox con Dataverse. Otros tipos de entorno requieren un tratamiento diferente.

Dataverse

El entorno y sus datos pueden formar parte del proceso soportado, pero siguen existiendo dependencias del directorio y tareas posteriores a la migración.

Por ejemplo, deben revisarse:

• usuarios;
• Security Groups;
• Application Users;
• connections;
• connection references;
• custom connectors;
• environment variables;
• Managed Environments;
• triggers;
• integraciones externas.

Power Apps

Una aplicación puede estar presente después del movimiento y, aun así, necesitar cambios porque su conexión apunta a un recurso, usuario o tenant antiguo.

Power Automate

Los flows deben validarse especialmente. Connections, credenciales, triggers y connection references son algunos de los elementos que pueden necesitar reconfiguración.

Security Groups y Application Users

Estos objetos pertenecen al directorio y deben prepararse o recrearse en el tenant destino cuando el escenario así lo requiera.

Fuente oficial: Microsoft Learn — Move an environment from one tenant to another.

¿Se migran los usuarios y grupos de Microsoft Entra ID?

No de la misma forma que el contenido. Las migraciones cross-tenant mueven datos y servicios, mientras que las identidades deben existir en el nuevo directorio y mapearse con las identidades del tenant origen.

Los usuarios tienen un nuevo Object ID

Un usuario puede conservar finalmente el mismo nombre y la misma dirección corporativa, pero el objeto de Entra ID pertenece a otro directorio y tiene un identificador diferente.

Este cambio afecta a:

• permisos;
• grupos;
• Enterprise Applications;
• App Registrations;
• Conditional Access;
• Power Platform;
• Power BI;
• aplicaciones que guarden referencias a Object IDs.

Cross-Tenant Identity Mapping

Microsoft utiliza identity mapping para relacionar usuarios y grupos de origen con los nuevos objetos de destino. Esta correspondencia es especialmente importante para cargas como Exchange, OneDrive y SharePoint.

Microsoft 365 Groups, Security Groups y Distribution Lists

Los grupos deben inventariarse según su tipo:

• Microsoft 365 Groups;
• Security Groups;
• mail-enabled security groups;
• Distribution Lists;
• Dynamic Groups;
• objetos sincronizados desde Active Directory.

No todos tienen el mismo procedimiento de recreación ni las mismas dependencias.

Objetos híbridos y Active Directory on-premises

Cuando existen usuarios sincronizados, el proyecto debe decidir cuál será la fuente de autoridad, cómo se realizará el matching y cuál será la configuración futura de Microsoft Entra Connect o Cloud Sync.

Enterprise Applications

Las Enterprise Applications contienen service principals específicos del tenant. Es necesario revisar SSO, assignments, provisioning, certificados, claims y consentimientos.

App Registrations

También deben analizarse por separado. Client IDs, redirect URIs, secretos, certificados, API permissions y admin consent pueden requerir una configuración nueva en destino.

Fuentes oficiales: Cross-Tenant Identity Mapping · Application objects and service principals.

¿Se puede mantener el mismo dominio al cambiar de tenant?

Sí, pero requiere un cutover controlado. El dominio corporativo debe liberarse del tenant origen antes de incorporarse al tenant destino y volver a utilizarse con normalidad.

¿Por qué no se cambia simplemente el DNS?

Porque el dominio puede estar utilizado por muchos objetos internos:

• UPN de usuarios;
• ProxyAddresses;
• aliases;
• shared mailboxes;
• Distribution Lists;
• Microsoft 365 Groups;
• mail contacts;
• Teams;
• cuentas administrativas;
• aplicaciones e integraciones.

Mientras existan referencias incompatibles, Microsoft puede impedir retirar el dominio del tenant anterior.

MX, SPF, DKIM, DMARC y Autodiscover

Una vez trasladado el dominio hay que comprobar también el flujo de correo y las configuraciones DNS:

• MX;
• SPF;
• DKIM;
• DMARC;
• Autodiscover;
• connectors;
• gateways de terceros;
• relays SMTP;
• aplicaciones que envían correo.

Fuente oficial: Microsoft Learn — Remove a domain from Microsoft 365.

¿Se migran Conditional Access, Purview y Defender?

No automáticamente con el contenido. Las políticas de seguridad y cumplimiento pertenecen al tenant y deben inventariarse, reconstruirse y adaptarse a las nuevas identidades, grupos, aplicaciones y dispositivos.

Conditional Access

Microsoft Graph permite consultar y crear políticas de Conditional Access, lo que facilita automatizar parte de la reconstrucción.

Sin embargo, copiar una política literalmente no garantiza que funcione en destino porque pueden cambiar:

• usuarios;
• grupos;
• roles;
• aplicaciones;
• Object IDs;
• exclusiones;
• dependencias con Intune.

Microsoft Purview

DLP, retention, sensitivity labels, eDiscovery y otras configuraciones deben analizarse como parte del proyecto. Migrar los datos no significa que las políticas de cumplimiento queden automáticamente configuradas en el tenant nuevo.

Holds

Además de su función de cumplimiento, los Holds tienen una implicación directa sobre la migración: determinados movimientos de Exchange, OneDrive y SharePoint pueden quedar bloqueados mientras exista una retención incompatible.

Microsoft Defender

Defender agrupa múltiples productos. Defender for Office 365, Defender for Endpoint y otras capacidades deben revisarse según lo que realmente utilice la organización.

Una oportunidad para no copiar deuda histórica

Una migración de tenant es también una buena ocasión para revisar configuraciones que llevan años acumulándose.

No siempre tiene sentido reproducir:

• exclusiones temporales antiguas;
• grupos sin propietarios;
• políticas duplicadas;
• reglas creadas para sistemas ya retirados;
• excepciones que nadie puede justificar.

Fuentes oficiales: Microsoft Graph — Conditional Access policy · Microsoft Purview.

¿Qué cambia para el usuario después de una migración entre tenants?

El objetivo es que el cambio afecte lo mínimo posible al trabajo diario, pero una migración entre tenants implica nuevas identidades, nuevos endpoints de servicio y, en algunos casos, nuevas autenticaciones. La experiencia exacta depende de los workloads incluidos y del diseño del cutover.

Los cambios más habituales pueden afectar a:

¿Se puede hacer sin downtime?

No es recomendable prometer “cero downtime” de forma absoluta. Lo correcto es minimizar la interrupción mediante preparación previa, pilotos, oleadas, coexistencia cuando sea posible y una ventana de cutover bien diseñada.

¿Se puede evitar pérdida de datos?

Una migración profesional debe trabajar con criterios de validación y aceptación para comprobar que el contenido esperado está presente en destino. Sin embargo, también es importante identificar previamente los elementos que no tienen equivalencia 1:1 para no confundir una limitación conocida con un fallo de migración.

¿Qué ocurre con Forms, Loop, Viva, Bookings, Lists y otros servicios?

Deben analizarse por separado. Microsoft 365 incluye muchos más servicios que Exchange, OneDrive y Teams, y varios de ellos no disponen de una migración tenant-to-tenant 1:1.

Dependiendo de la organización, el inventario puede encontrar:

• Microsoft Forms;
• Microsoft Loop;
• OneNote;
• Microsoft Lists;
• Stream sobre SharePoint;
• Viva Engage;
• Viva Connections;
• Bookings;
• Project;
• Power Pages;
• Copilot Studio;
• Teams Phone;
• aplicaciones SaaS integradas mediante Entra ID.

Que un servicio no disponga de movimiento directo no significa necesariamente que deba perderse. Puede ser posible exportarlo, reconstruirlo, dejarlo temporalmente en origen o diseñar otra solución en destino.

Lo importante es que esa decisión sea explícita antes del cutover.

¿Por qué las herramientas nativas de Microsoft no cubren por sí solas una migración completa?

Porque Microsoft 365 no es una única aplicación. Es un ecosistema formado por servicios independientes que comparten identidad y se relacionan entre sí, pero utilizan modelos de datos, APIs y mecanismos de administración diferentes.

Microsoft dispone de herramientas nativas muy importantes:

• Microsoft 365 Migration Orchestrator para coordinar determinados workloads de usuario;
• Cross-Tenant Mailbox Migration para Exchange Online;
• Cross-Tenant OneDrive Migration;
• Cross-Tenant SharePoint Migration;
• Cross-Tenant Identity Mapping;
• Microsoft Graph para múltiples objetos y configuraciones;
• Power Platform tenant-to-tenant environment migration.

Sin embargo, siguen existiendo tratamientos diferentes para Teams compartidos, Planner, Power BI, Intune, identidad, dominios, aplicaciones y seguridad.

Esto no es una deficiencia extraña de Microsoft 365. Un buzón, un dispositivo administrado, un workspace de Power BI y una App Registration son objetos radicalmente distintos.

La dificultad surge cuando se espera que exista un único botón llamado “Migrar tenant” capaz de reproducir todo el entorno de forma idéntica.

¿Cómo resuelve MSAdvance una migración Microsoft 365 completa?

MSAdvance actúa como capa de orquestación del proyecto. El cliente no tiene que decidir qué herramienta utilizar para cada workload ni coordinar manualmente varios procesos independientes.

Nuestra aproximación parte del resultado final que debe conseguir la organización:

1. Assessment: analizamos tenant origen, destino y restricciones.
2. Inventario: identificamos datos, objetos, workloads y dependencias.
3. Arquitectura: definimos cómo debe quedar el tenant destino.
4. Identity mapping: preparamos las correspondencias necesarias.
5. Selección de método: vía nativa de Microsoft, herramienta especializada, Graph, PowerShell o combinación.
6. Piloto: probamos el diseño con usuarios y cargas representativas.
7. Migración: trasladamos los elementos que admiten movimiento.
8. Recreación: reconstruimos los objetos sin migración directa.
9. Rediseño: mejoramos componentes cuando copiar la arquitectura anterior no aporta valor.
10. Validación: comprobamos contenido, permisos y funcionamiento.
11. Cutover: coordinamos identidades, dominio, correo y acceso.
12. Hypercare: resolvemos incidencias posteriores al cambio.

No sería técnicamente correcto prometer que “absolutamente todo puede copiarse de forma idéntica”. Algunos objetos no tienen una migración 1:1.

Lo importante es otra cosa: nos encargamos de conseguir el resultado completo. Cuando un elemento no puede trasladarse literalmente, definimos previamente cómo debe conservarse, reconstruirse o rediseñarse.

El objetivo no es únicamente que una herramienta muestre todos los jobs en verde. El objetivo es que el nuevo tenant esté operativo y que los usuarios puedan seguir trabajando.

¿Qué información necesitamos para presupuestar una migración tenant-to-tenant?

Para estimar una migración correctamente necesitamos conocer el entorno por workload, no solamente el número de usuarios.

El número de empleados sirve como referencia, pero no refleja por sí solo la cantidad de datos, dependencias o trabajo de recreación.

Con esta información puede decidirse qué utilizará una vía nativa, qué workload necesita una plataforma especializada y qué elementos requieren recreación o automatización.

¿En qué orden se migran las cargas de Microsoft 365?

No existe un orden universal, pero identidad y arquitectura deben prepararse antes del contenido, mientras que el dominio suele reservarse para la fase de cutover.

Un orden orientativo para un entorno empresarial puede ser:

1. Discovery e inventario.
2. Definición de alcance.
3. Diseño del tenant destino.
4. Licenciamiento y permisos administrativos.
5. Provisioning de usuarios y grupos.
6. Identity mapping.
7. Preparación de aplicaciones y seguridad base.
8. Piloto técnico.
9. Precargas cuando la tecnología seleccionada las permita.
10. SharePoint y componentes de colaboración.
11. Teams y canales.
12. Planner, Power BI y Power Platform.
13. Preparación de Intune y dispositivos.
14. Cutover de identidades, Exchange, dominio y DNS.
15. Reenrollment de endpoints cuando aplique.
16. Validación funcional.
17. Hypercare.
18. Retirada controlada del tenant origen.

Microsoft 365 Migration Orchestrator ya conoce determinadas dependencias entre los workloads que coordina. El resto del ecosistema sigue necesitando una planificación global.

¿Es mejor utilizar las herramientas nativas de Microsoft o una herramienta especializada?

Depende del workload, del volumen de información y del modelo de cutover. Una migración bien diseñada no debería empezar eligiendo una marca de herramienta y obligando después a que todo el tenant encaje en ella.

Una herramienta de terceros puede mejorar automatización, reporting, coexistencia, precargas o cobertura de determinados workloads. Sin embargo, ninguna plataforma puede saltarse una limitación fundamental de una API o de un servicio de Microsoft que no exponga la información necesaria.

Por eso la mejor estrategia puede utilizar un método para Exchange, otro para Teams y automatización específica para determinadas configuraciones.

Para ampliar esta comparación puedes consultar nuestra guía de herramientas y scripts para migrar tenants Microsoft 365.

¿Cuáles son los errores más habituales en una migración entre tenants Microsoft 365?

El error más habitual es tratar Microsoft 365 como si fuese solamente correo y archivos. Los problemas más costosos suelen aparecer en las dependencias que no fueron inventariadas.

1. Asumir que todo Microsoft 365 se mueve mediante una única herramienta.
2. Contar Teams sin analizar los sitios SharePoint asociados.
3. Olvidar los chats y reuniones de Teams.
4. Olvidar Planner dentro de los Teams.
5. Contar Power BI únicamente por informes.
6. Dejar Intune para después del cutover.
7. No detectar Holds y políticas de retención.
8. Ignorar Enterprise Applications y Single Sign-On.
9. No preparar correctamente identity mapping.
10. Intentar liberar el dominio sin eliminar todas sus referencias.
11. Dar por hecho que todos los permisos se conservarán automáticamente.
12. Prometer una experiencia absolutamente idéntica.
13. No realizar un piloto representativo.
14. Empezar a utilizar destinos que deben permanecer libres para la estrategia nativa seleccionada.
15. Migrar grupos, Teams y sitios que llevan años sin utilizarse.
16. Validar únicamente el número de elementos y no su funcionamiento.

Una buena migración no consiste en copiar más cosas. También consiste en saber qué tiene sentido trasladar y qué deuda histórica merece la pena dejar atrás.

Checklist de alcance para una migración Microsoft 365 entre tenants

Antes de cerrar el alcance conviene revisar al menos los siguientes puntos:

Si uno de estos componentes existe en el tenant origen pero no aparece en el alcance, debe decidirse expresamente si se migra, se recrea, se archiva, permanece temporalmente en origen o se retira.

Fuentes oficiales para verificar las capacidades de migración

Microsoft 365 evoluciona continuamente. Antes de ejecutar una migración conviene revisar siempre la documentación oficial aplicable al momento del proyecto.

• Microsoft 365 Migration documentation — documentación general de Microsoft sobre migraciones.
• Microsoft 365 Migration Orchestrator — coordinación de workloads de usuario.
• Cross-Tenant Mailbox Migration.
• Cross-Tenant Identity Mapping.
• Cross-Tenant OneDrive Migration.
• Cross-Tenant SharePoint Migration.
• Microsoft Graph — Teams migration APIs.
• Microsoft Graph — Planner.
• Power BI tenant migration patterns and strategies.
• Microsoft Intune migration guide.
• Power Platform tenant-to-tenant environment migration.

Guías relacionadas de MSAdvance

• Guía completa de migración Microsoft 365 entre tenants.
• Migración de OneDrive entre tenants.
• Migración de SharePoint entre tenants.
• Migración de Microsoft Teams entre tenants.
• Migración de Power BI.
• Herramientas y scripts para migrar tenants Microsoft 365.

Conclusión: qué se puede migrar entre tenants Microsoft 365

Se puede migrar una parte muy amplia de Microsoft 365, pero no existe una única ruta que traslade todo un tenant de extremo a extremo. Exchange Online, OneDrive y SharePoint disponen de mecanismos cross-tenant. Microsoft 365 Migration Orchestrator coordina determinados datos de Exchange, OneDrive y Teams. Teams compartidos, Planner, Power BI, Intune, Power Platform, Entra ID, aplicaciones, dominios y seguridad necesitan tratamientos adicionales.

La complejidad no suele estar en mover un buzón individual. Está en conseguir que todas las dependencias sigan teniendo sentido después del cambio: permisos, grupos, Teams, documentos, aplicaciones, dispositivos, gateways, automatizaciones y dominio.

MSAdvance se encarga de coordinar la migración completa para que el cliente no tenga que gestionar una herramienta distinta para cada servicio. Cuando Microsoft dispone de una vía nativa adecuada, la utilizamos. Cuando el alcance requiere algo más, incorporamos herramientas especializadas, Microsoft Graph, PowerShell o procesos de recreación controlada.

Y cuando un elemento no dispone de una migración 1:1, se define antes de la ejecución cómo debe conservarse, reconstruirse o rediseñarse.