Migración tenant to tenant de Microsoft 365: guía completa para mover correo, OneDrive, SharePoint, Teams y dominios
Una migración tenant to tenant de Microsoft 365 es mucho más que trasladar buzones de correo de una organización a otra. En una fusión, adquisición, escisión o reorganización empresarial, cambiar de tenant puede afectar simultáneamente a las identidades de los usuarios, Exchange Online, OneDrive, SharePoint, Microsoft Teams, dominios corporativos, aplicaciones, seguridad, licencias y dispositivos.
Por eso, el éxito del proyecto no depende únicamente de que una herramienta consiga copiar datos. Lo realmente complejo es conseguir que, después del cambio, los usuarios puedan seguir trabajando con normalidad, que los permisos sean correctos, que las aplicaciones continúen autenticando, que el correo llegue a su destino y que la seguridad del nuevo tenant esté preparada.
Microsoft ha ampliado considerablemente sus capacidades nativas de cross-tenant migration. Actualmente existen mecanismos específicos para Exchange Online, OneDrive y SharePoint, además de Microsoft 365 Migration Orchestrator para coordinar determinados workloads. Aun así, no todos los elementos de Microsoft 365 se trasladan de la misma manera y, en muchos proyectos, sigue siendo necesario combinar herramientas nativas, soluciones especializadas y trabajos de reconfiguración.
Esta guía explica cómo abordar una migración entre tenants de Microsoft 365 desde el principio hasta la estabilización final: qué debes analizar, qué puede migrarse, cómo tratar los dominios, qué opciones ofrece Microsoft, cuándo tiene sentido utilizar herramientas como Quest On Demand Migration y qué deberías comprobar antes de considerar terminado el proyecto.
La idea principal
Si solo recuerdas una cosa de esta guía, que sea esta: una migración tenant-to-tenant debe diseñarse antes de elegir la herramienta.
| Pregunta | Qué debes tener claro |
|---|---|
| ¿Qué se migra? | Usuarios, buzones, OneDrive, SharePoint, Teams, dominios, aplicaciones y cualquier otro workload incluido en el alcance. |
| ¿Qué no se migra? | Contenido obsoleto, usuarios que no deben pasar al nuevo tenant, aplicaciones retiradas y configuraciones que convenga reconstruir. |
| ¿Cómo convivirán los tenants? | Correo, calendarios, Teams, acceso a documentos e identidad durante el periodo de transición. |
| ¿Cuándo se mueve el dominio? | Solo cuando el origen esté preparado y todas las referencias necesarias hayan sido eliminadas. |
| ¿Cómo se valida? | No basta con comprobar datos: hay que probar permisos, correo, aplicaciones, autenticación, dispositivos y experiencia de usuario. |
¿Estás preparando una migración entre tenants?
Antes de comprar licencias o elegir una herramienta, conviene hacer un assessment de ambos tenants. Un buen inventario permite saber qué realmente hay que migrar, detectar dependencias y evitar sorpresas durante el cutover.
Solicitar un assessment tenant-to-tenantÍndice
- Qué es una migración tenant-to-tenant
- Cuándo suele ser necesaria
- Por qué una migración entre tenants es compleja
- Qué puede migrarse en Microsoft 365
- Qué ofrece Microsoft actualmente
- Cómo elegir la estrategia de migración
- Assessment e inventario previo
- Microsoft Entra ID e identidad
- Dominios, UPN y DNS
- Licencias de migración
- Exchange Online
- OneDrive
- SharePoint Online
- Microsoft Teams
- Coexistencia entre tenants
- Microsoft Purview y cumplimiento
- Power Platform
- Aplicaciones e integraciones
- Herramientas de migración
- Metodología paso a paso
- El piloto
- El cutover
- Validación y hypercare
- Riesgos y errores habituales
- Preguntas frecuentes
Qué es una migración tenant to tenant de Microsoft 365
Un tenant de Microsoft 365 es el entorno lógico en el que una organización gestiona sus usuarios, identidades, dominios, licencias y servicios cloud. Exchange Online, OneDrive, SharePoint, Teams, Microsoft Entra ID, Intune, Defender, Purview y Power Platform están vinculados, directa o indirectamente, a ese tenant.
Cuando una empresa necesita trasladar usuarios y datos hacia otro entorno Microsoft 365, hablamos de una migración tenant-to-tenant o cross-tenant migration.
Microsoft contempla expresamente estos proyectos para escenarios de fusiones, adquisiciones, desinversiones y reorganizaciones internas. La particularidad es que no se está moviendo información entre dos carpetas de la misma organización, sino entre dos límites administrativos, de identidad y seguridad independientes.
Esto explica por qué un usuario que aparentemente “es el mismo” en ambos entornos no lo es técnicamente: su objeto de Microsoft Entra ID, sus identificadores, sus grupos, sus permisos y muchas de sus relaciones con otros servicios cambian de un tenant a otro.
Documentación oficial: Microsoft – Plan a Microsoft 365 tenant-to-tenant migration.
Cuándo suele ser necesaria una migración entre tenants
El escenario más conocido es una adquisición. Una empresa compra otra y, durante un tiempo, ambas continúan trabajando desde tenants independientes. Más adelante se decide consolidar correo, archivos, Teams y usuarios en un único entorno.
El escenario inverso también es frecuente. En una escisión o carve-out, una unidad de negocio debe abandonar el tenant actual y construir su propio entorno. Aquí la dificultad no consiste solo en decidir qué se mueve, sino también qué debe permanecer en la organización original.
| Escenario | Objetivo habitual | Complejidad característica |
|---|---|---|
| Fusión o adquisición | Integrar dos organizaciones en un tenant principal. | Coexistencia, dominios, usuarios duplicados y aplicaciones. |
| Escisión o carve-out | Separar una unidad de negocio en un tenant independiente. | Separación de datos, permisos y dependencias compartidas. |
| Consolidación | Reducir varios tenants históricos a uno. | Muchos dominios, grupos, modelos de seguridad y configuraciones distintas. |
| Reorganización | Mover usuarios o unidades completas entre entornos. | Identidad, aplicaciones y mantenimiento de accesos. |
Por qué una migración tenant-to-tenant es más compleja de lo que parece
El problema es que Microsoft 365 está profundamente interconectado. Un equipo de Microsoft Teams puede tener detrás un Microsoft 365 Group, un sitio de SharePoint, calendarios de Exchange, archivos personales almacenados en OneDrive, un plan de Planner y varias aplicaciones conectadas.
Si se analiza cada servicio de forma aislada, es fácil romper estas relaciones.
Por ejemplo, mover un buzón no significa que sus permisos delegados estén automáticamente resueltos. Copiar un sitio de SharePoint no garantiza que todos los usuarios del nuevo tenant mantengan exactamente los mismos permisos. Migrar un Team tampoco implica necesariamente que Planner, pestañas, bots, apps o chats tengan el mismo comportamiento en destino.
Por eso, la arquitectura de la migración debe contemplar dependencias entre workloads y establecer el orden correcto para trasladarlos.
Qué puede migrarse entre tenants de Microsoft 365
La siguiente tabla resume los principales workloads. El término “migrar” debe entenderse con cierta cautela: algunos servicios se mueven mediante mecanismos nativos, otros se copian mediante herramientas de terceros y otros requieren recreación o reconfiguración.
| Workload | Qué puede trasladarse | Qué suele requerir atención adicional |
|---|---|---|
| Exchange Online | Correo, calendario, contactos, tareas, notas y determinados buzones. | Delegaciones, archivos online, holds, shared mailboxes, reglas, conectores y dominio. |
| OneDrive | Archivos y estructura documental del usuario. | Permisos, enlaces, usuarios externos, sincronización y aprovisionamiento del destino. |
| SharePoint Online | Sitios, bibliotecas, documentos, versiones y determinados metadatos. | Permisos, enlaces, Microsoft 365 Groups, Teams, Power Platform y personalizaciones. |
| Microsoft Teams | Chats, reuniones, equipos, canales y archivos según el método utilizado. | Planner, apps, pestañas, canales privados, shared channels, grabaciones y usuarios externos. |
| Microsoft Entra ID | Se preparan y mapean identidades en destino. | Los objetos no se “mueven” como datos; deben diseñarse y prepararse correctamente. |
| Power Platform | Determinados entornos y componentes. | Conexiones, propietarios, Dataverse, Power Pages, mailboxes e integraciones. |
| Microsoft Purview | Parte de la configuración debe recrearse o adaptarse. | Retention, DLP, etiquetas, eDiscovery, holds y obligaciones regulatorias. |
| Aplicaciones | Normalmente requieren reconfiguración. | Tenant ID, secretos, certificados, permisos API, SSO y SCIM. |
Qué ofrece Microsoft actualmente para migraciones entre tenants
Hace unos años, la respuesta habitual para un proyecto tenant-to-tenant era utilizar una herramienta de terceros. Esto está cambiando. Microsoft dispone ahora de varias capacidades nativas que cubren una parte cada vez mayor del escenario.
Sin embargo, no debemos hablar de “una herramienta nativa” como si todo Microsoft 365 se migrara con un único botón. Existen diferentes mecanismos, con requisitos y licencias distintos.
| Capacidad Microsoft | Finalidad | Punto clave |
|---|---|---|
| Cross-tenant Mailbox Migration | Mover buzones de Exchange Online. | Requiere preparar MailUsers, relaciones entre tenants y licenciamiento específico. |
| Cross-tenant OneDrive Migration | Mover OneDrive entre tenants. | Es one-and-done y no admite pases delta. |
| Cross-tenant SharePoint Migration | Mover sitios SharePoint. | El destino no debe existir y existe un modelo específico de licenciamiento. |
| Migration Orchestrator | Coordinar migraciones multiworkload. | Gestiona dependencias y batches para workloads soportados. |
| Cross-Tenant Identity Mapping | Mapear usuarios origen-destino. | Es obligatorio en migraciones realizadas mediante el método orquestado. |
| Microsoft Graph Cross-tenant Migration API | API unificada para automatización. | La documentación actual se publica bajo Microsoft Graph beta. |
Migration Orchestrator: una capa de coordinación
Microsoft 365 Migration Orchestrator pretende resolver uno de los problemas clásicos de estos proyectos: coordinar los distintos workloads de un usuario. Microsoft indica en su documentación general que el modelo orquestado puede utilizarse para movimientos multiworkload y gestionar el orden de las dependencias.
La documentación detallada del servicio sigue distinguiendo diferentes tipos de contenido y menciona específicamente Exchange, OneDrive, Teams chats y Teams meetings en sus procesos y estimaciones. Al mismo tiempo, la documentación general de planificación de Microsoft ya contempla SharePoint dentro del modelo de migraciones coordinadas.
La conclusión práctica es sencilla: el alcance del producto está evolucionando rápidamente. Antes de comprometer una arquitectura de proyecto, conviene comprobar la documentación vigente del workload exacto que se pretende migrar.
Documentación oficial: Microsoft – Migration Orchestrator overview.
Cross-tenant SharePoint Migration
La llegada de una capacidad nativa específica para SharePoint es uno de los cambios más relevantes. Microsoft permite actualmente mover sitios mediante SharePoint Online PowerShell sin sacar los datos del cloud de Microsoft.
Pero el comportamiento es muy diferente al de muchas herramientas tradicionales. El sitio de destino no debe existir previamente, no es posible fusionarlo con uno existente y el movimiento es one-and-done: no hay una premigración seguida de pases delta.
Microsoft documenta actualmente un máximo de 5 TB o 1 millón de elementos por sitio. Además, pueden programarse hasta 4.000 sitios para migración y la funcionalidad de Shared Data Migration mantiene requisitos comerciales específicos, entre ellos disponibilidad para clientes Enterprise Agreement y licenciamiento por volumen de datos.
Por tanto, que exista una capacidad nativa no significa necesariamente que sea la mejor opción para cualquier proyecto.
Documentación oficial: Microsoft – Cross-tenant SharePoint migration.
¿Microsoft nativo o una herramienta especializada?
Esta decisión conviene tomarla después del assessment. En algunos proyectos las capacidades nativas de Microsoft encajan perfectamente. En otros, la necesidad de hacer premigraciones, deltas, coexistencia avanzada, migrar Teams con mayor profundidad o disponer de una consola centralizada puede hacer más adecuada una herramienta especializada.
Analizar qué herramienta encaja en mi migraciónCómo elegir la estrategia de migración
Microsoft diferencia varios modelos. La decisión debe estar condicionada por el tamaño del entorno, las dependencias y el margen de cambio que pueda asumir la empresa.
| Modelo | Cómo funciona | Cuándo suele encajar |
|---|---|---|
| Single-event | Usuarios y workloads principales cambian dentro de una misma ventana. | Empresas pequeñas o proyectos con pocas dependencias. |
| Por fases | Usuarios o departamentos se trasladan en sucesivas oleadas. | Entornos grandes o donde el soporte debe repartirse. |
| Tenant split | Solo una parte de la organización abandona el tenant. | Escisiones y desinversiones. |
| Selectiva | Solo se trasladan determinados datos o workloads. | Cuando no merece la pena migrar todo el entorno. |
La migración por fases suele ser más manejable, pero introduce una dificultad adicional: durante varias semanas pueden coexistir usuarios en el tenant origen y en el destino. Esto obliga a diseñar correo, calendarios y colaboración cross-tenant antes de empezar las oleadas.
El assessment: la fase que más problemas evita
Un buen assessment responde a una pregunta aparentemente sencilla: ¿qué tenemos realmente?
La respuesta suele sorprender. Es frecuente encontrar buzones compartidos que nadie había incluido en el proyecto, Teams sin propietarios, sitios SharePoint abandonados, aplicaciones que envían correo utilizando una cuenta histórica, flujos Power Automate creados por empleados que ya no trabajan en la empresa o usuarios invitados con acceso a información sensible.
El inventario debe servir para convertir ese entorno desordenado en un alcance concreto.
| Área | Información que conviene obtener | Por qué importa |
|---|---|---|
| Identidad | Usuarios, UPN, grupos, invitados, roles, sincronización y licencias. | Permite construir el mapping entre ambos tenants. |
| Exchange | Buzones, tamaños, archives, shared mailboxes, permisos, aliases, holds y conectores. | Define estrategia, licencias y orden de migración. |
| OneDrive | Volumen, usuarios, sharing, enlaces y contenido abandonado. | Evita mover información innecesaria y detecta casos incompatibles. |
| SharePoint | Sitios, almacenamiento, elementos, permisos, Teams asociados y personalizaciones. | Determina qué puede moverse automáticamente y qué necesita tratamiento especial. |
| Teams | Equipos, canales, miembros, invitados, apps, Planner y reuniones. | Permite establecer expectativas realistas sobre el resultado. |
| Aplicaciones | SSO, SCIM, registros de apps, API permissions, secretos y certificados. | Evita que aplicaciones críticas dejen de funcionar tras el corte. |
| Compliance | Retention, DLP, labels, holds, eDiscovery y Customer Key. | Puede condicionar qué contenido puede moverse y mediante qué método. |
No todo debería migrarse
Una migración también es una oportunidad para limpiar. Mover información que nadie utiliza solo aumenta tiempo, coste y complejidad.
En el assessment deberían clasificarse los elementos en cuatro grandes categorías: lo que se migra, lo que se archiva, lo que se elimina y lo que debe reconstruirse en destino.
Esto es especialmente útil en SharePoint y Teams. Es habitual descubrir equipos sin actividad desde hace años, sitios duplicados, permisos heredados demasiado amplios o propietarios que ya no existen.
Microsoft Entra ID: el punto de partida real
Antes de hablar de correo o archivos hay que hablar de identidad. Los datos necesitan saber a qué usuario del tenant destino pertenecen y qué permisos debe recibir esa nueva identidad.
Microsoft dispone actualmente de Cross-Tenant Identity Mapping (CTIM), una herramienta diseñada para mapear uno a uno usuarios de origen y destino y preparar los atributos que necesita la migración.
En el método orquestado, Microsoft establece este mapping como requisito. Además, existe un detalle especialmente importante: CTIM debe ejecutarse antes de asignar determinadas licencias de workload a los usuarios de destino para evitar que se aprovisionen objetos, como un buzón, antes de tiempo.
Esto resume una de las reglas fundamentales de estos proyectos: no aprovisiones servicios en destino sin comprobar primero cómo afectará al método de migración elegido.
Documentación oficial: Microsoft – Cross-Tenant Identity Mapping.
Dominios, UPN y DNS: el momento más delicado del cutover
Un dominio corporativo como empresa.com no puede simplemente “copiarse” de un tenant a otro. Primero hay que eliminar las dependencias que mantiene en el origen y, después, añadirlo y validarlo en destino.
Este proceso afecta tanto al inicio de sesión como al correo. Por eso es habitual preparar previamente las cuentas con dominios temporales onmicrosoft.com o dominios de routing y reservar el movimiento del dominio corporativo para la ventana de corte.
| Elemento | Qué debe comprobarse |
|---|---|
| UPN | Qué usuario utilizará cada dirección de inicio de sesión en destino. |
| SMTP | Direcciones principales, aliases y proxyAddresses. |
| MX | A qué tenant o gateway llegará el correo después del cambio. |
| SPF | Qué plataformas están autorizadas a enviar correo. |
| DKIM | Claves y configuración del dominio en el nuevo tenant. |
| DMARC | Alineación con el nuevo flujo de correo. |
| Autodiscover | Comportamiento de Outlook y otros clientes. |
Antes de retirar el dominio del origen deben revisarse usuarios, administradores, contactos, grupos, Teams, buzones compartidos, recursos y cualquier otro objeto que todavía utilice ese namespace.
Documentación oficial: Microsoft – Remove a domain from Microsoft 365.
Licencias necesarias para una migración cross-tenant
Las licencias de Microsoft 365 que utiliza normalmente el usuario no cubren necesariamente el movimiento entre tenants. Microsoft dispone de complementos específicos.
Para Exchange Online y OneDrive, Microsoft documenta la licencia Cross Tenant User Data Migration, que se asigna por usuario y se adquiere como pago único para esa migración. Puede asignarse en origen o destino según el escenario.
SharePoint Shared Data Migration utiliza actualmente un modelo diferente. Microsoft documenta disponibilidad específica para clientes Enterprise Agreement y licenciamiento por bloques de 100 GB migrados.
| Workload | Modelo de licencia nativa a revisar |
|---|---|
| Exchange Online | Cross Tenant User Data Migration por usuario. |
| OneDrive | Incluido dentro del modelo Cross Tenant User Data Migration aplicable. |
| Migration Orchestrator | Licencia cross-tenant por usuario para contenido soportado por la orquestación. |
| SharePoint Shared Data | Licenciamiento por capacidad migrada, actualmente con condiciones específicas de contratación. |
Conviene confirmar siempre el modelo comercial vigente antes de cerrar un presupuesto, porque estas capacidades están evolucionando rápidamente.
Migración de Exchange Online entre tenants
Exchange Online suele marcar la percepción del proyecto. Si un usuario puede acceder a sus documentos pero no puede enviar correo, para él la migración ha fallado.
La solución nativa de Microsoft permite mover buzones entre tenants mediante Exchange Online PowerShell y el servicio MRS. El usuario debe estar correctamente preparado en el tenant destino como MailUser con los atributos necesarios para identificar el buzón origen.
Después del movimiento, el buzón del origen deja de ser un mailbox y Microsoft conserva un MailUser con una dirección de routing hacia el destino. Esto puede facilitar la coexistencia temporal del correo.
Qué contenido se mueve
Microsoft indica que la migración nativa traslada el contenido visible del usuario, incluyendo correo, contactos, calendario, tareas y notas. Sin embargo, no debe interpretarse como una copia completa de toda la configuración de Exchange.
| Elemento | Tratamiento recomendado |
|---|---|
| Correo | Migrar y validar número de elementos y acceso. |
| Calendario | Probar reuniones, organización y disponibilidad. |
| Shared mailboxes | Inventariar y validar acceso después del movimiento. |
| Full Access / Send As | Inventariar y comprobar explícitamente. |
| Transport Rules | Recrear o adaptar en destino. |
| Connectors | Revisar aplicaciones, gateways y flujo SMTP. |
| Archive | Revisar tamaño, ArchiveGUID y licencias. |
El problema de los holds
Este es uno de los puntos que debe detectarse en el assessment. Microsoft establece actualmente que los buzones sometidos a cualquier tipo de hold quedan bloqueados para el movimiento cross-tenant nativo.
Eso significa que un proyecto con Litigation Hold, eDiscovery o políticas de conservación debe analizarse con el equipo de seguridad y cumplimiento antes de ejecutar cambios. Retirar un hold simplemente para poder migrar puede tener implicaciones legales, por lo que nunca debería hacerse sin validar el requisito que lo originó.
Documentación oficial: Microsoft – Cross-tenant mailbox migration.
Migración de OneDrive entre tenants
OneDrive parece más sencillo porque, en esencia, contiene archivos. Sin embargo, también contiene enlaces compartidos, permisos externos, contenido sincronizado en dispositivos y archivos utilizados indirectamente por otras aplicaciones.
Microsoft ofrece una migración cross-tenant nativa mediante SharePoint Online PowerShell. Puede programar hasta 4.000 OneDrive para movimiento, mantiene los datos dentro de Microsoft 365 y deja una redirección en la ubicación antigua una vez completada la operación.
Durante el movimiento existe una breve ventana en la que el OneDrive queda en modo de solo lectura. Microsoft habla de unos pocos minutos en condiciones normales, aunque no debe utilizarse como garantía contractual.
Una diferencia fundamental: no hay delta
La migración nativa de OneDrive es one-and-done. El contenido se mueve; no existe un primer pase seguido de sincronizaciones incrementales.
Esta característica tiene una consecuencia directa en el diseño del proyecto. Una herramienta que permite pre-stage puede copiar gran parte de los datos días antes y solo sincronizar cambios durante el corte. El método nativo de OneDrive funciona de otra manera y debe planificarse teniendo esto en cuenta.
No aprovisiones el OneDrive destino
Otro detalle crítico es que el OneDrive del usuario no debe existir previamente en el tenant destino cuando se utiliza esta migración nativa. Si el usuario entra en OneDrive y provoca su aprovisionamiento antes de tiempo, la operación puede fallar porque Microsoft no permite fusionar el contenido con un OneDrive existente.
Documentación oficial: Microsoft – Cross-tenant OneDrive migration.
Migración de SharePoint Online
SharePoint requiere probablemente el análisis documental más profundo. Dos sitios con el mismo tamaño pueden tener una complejidad totalmente diferente si uno contiene simples documentos y el otro utiliza permisos únicos, metadatos, Power Automate, Power Apps, external sharing y una conexión con Microsoft Teams.
Antes de decidir cómo migrarlo, conviene entender la estructura real del entorno.
| Qué analizar | Por qué importa |
|---|---|
| Propietarios | Evita dejar sitios sin responsable en el nuevo entorno. |
| Permisos únicos | Son una fuente habitual de errores después de la migración. |
| External sharing | Los invitados y enlaces pueden necesitar tratamiento específico. |
| Versiones | Pueden representar una parte importante del volumen. |
| Metadatos | Columnas y tipos de contenido pueden ser críticos para procesos internos. |
| Teams asociados | El sitio puede formar parte de un Team y no debería tratarse aisladamente. |
| Power Platform | Flujos y aplicaciones pueden contener URLs o referencias del tenant origen. |
La nueva opción nativa de Microsoft
Cross-tenant SharePoint Migration permite mover sitios directamente entre tenants. Como OneDrive, es una operación one-and-done. No permite crear previamente el sitio destino, sobrescribirlo ni ejecutar pases delta.
La documentación vigente limita cada sitio individual a un máximo de 5 TB o 1 millón de elementos. Además, si el tenant de origen utiliza Service Encryption con Microsoft Purview Customer Key, la migración nativa puede no ser compatible.
Una ventaja interesante es que, al terminar, Microsoft deja una redirección en la ubicación anterior para ayudar a mantener enlaces hacia el nuevo sitio.
Documentación oficial: Microsoft – Cross-tenant SharePoint migration.
¿Tienes mucho SharePoint o Teams?
En estos proyectos, hacer un descubrimiento previo suele tener más valor que empezar directamente a copiar datos. Podemos ayudarte a identificar sitios activos, Teams asociados, permisos especiales, almacenamiento y contenido que realmente merece la pena trasladar.
Revisar mi SharePoint y Teams antes de migrarMigración de Microsoft Teams
Teams merece un capítulo propio porque es donde más fácilmente se confunden las expectativas.
Para el usuario, un Team es una única aplicación. Técnicamente, puede contener información distribuida entre Teams, Exchange Online, SharePoint, OneDrive y otros servicios. Por eso “migrar Teams” debe convertirse en una lista mucho más concreta de requisitos.
| Elemento | Qué hay que confirmar |
|---|---|
| Equipos | Si se recrean, trasladan o reconstruyen. |
| Canales estándar | Estructura, archivos y conversaciones. |
| Canales privados | Permisos y sitios SharePoint asociados. |
| Shared channels | B2B Direct Connect y configuración cross-tenant. |
| Chats 1:1 y grupales | Compatibilidad exacta de la herramienta elegida. |
| Meeting chats | Relacionados con reuniones y Exchange. |
| Planner / Apps / Tabs | Normalmente requieren revisión específica. |
| Archivos | Dependencia de SharePoint y OneDrive. |
Migration Orchestrator incluye actualmente capacidades relacionadas con Teams chats y Teams meetings dentro de sus workloads de usuario. Para una migración más amplia de equipos, canales y aplicaciones, hay que revisar la funcionalidad disponible en el momento del proyecto o utilizar una plataforma especializada.
La regla práctica es no vender nunca “migración de Teams” sin especificar qué elementos de Teams están incluidos.
Coexistencia entre tenants mientras dura la migración
En una migración por fases, una parte de la plantilla puede estar trabajando ya en el tenant destino mientras otra sigue utilizando el origen.
Durante ese periodo, ambos grupos deben poder comunicarse de forma razonable.
La coexistencia puede abarcar correo, free/busy, acceso a documentos, Teams y aplicaciones. Microsoft también dispone de herramientas como Cross-Tenant Access Settings, B2B Collaboration, B2B Direct Connect, Cross-Tenant Synchronization y Multitenant Organization para determinados escenarios.
La coexistencia no debería convertirse en un estado permanente. Cuanto más tiempo permanezcan ambos tenants conectados mediante soluciones temporales, más difícil será administrar identidades, permisos, licencias y soporte.
Correo y calendarios
Exchange permite mantener mail routing entre usuarios situados en distintos tenants. Además, mediante Organization Relationships puede compartirse información de disponibilidad para facilitar la planificación de reuniones durante la transición.
Teams y colaboración
Dependiendo del escenario pueden combinarse External Access, usuarios B2B, Shared Channels y otras configuraciones cross-tenant para permitir que los equipos sigan colaborando mientras se completa la consolidación.
Microsoft Purview, retención y cumplimiento
Una migración entre tenants puede convertirse en un problema legal si se trata el cumplimiento como una consideración secundaria.
Antes de mover información hay que entender qué contenido está sometido a políticas de retención, qué usuarios tienen holds, qué información está clasificada y qué obligaciones debe seguir cumpliendo el tenant destino.
| Área Purview | Qué revisar |
|---|---|
| Retention | Qué información debe conservarse y durante cuánto tiempo. |
| Sensitivity Labels | Taxonomía, cifrado, publicación y comportamiento en destino. |
| DLP | Políticas y ubicaciones protegidas. |
| eDiscovery | Casos activos, custodios y datos sujetos a investigación. |
| Holds | Pueden afectar directamente a la posibilidad de migrar buzones. |
| Customer Key | Puede afectar a determinados movimientos nativos de SharePoint y OneDrive. |
Las configuraciones de Purview no deberían suponerse transferidas automáticamente. En muchos proyectos se documenta el modelo del tenant origen y se construye una configuración equivalente o mejorada en destino.
Power Platform en una migración tenant-to-tenant
Power Platform merece su propio análisis. Un flujo aparentemente sencillo puede depender de una cuenta concreta, una conexión de SharePoint, un mailbox, Dataverse o una aplicación externa.
Microsoft dispone de un procedimiento específico para migrar determinados entornos Power Platform entre tenants. Actualmente los entornos Production y Sandbox son los principales tipos admitidos por este mecanismo; otros, como Developer, Trial o Teams, tienen limitaciones.
El cambio de tenant no elimina la necesidad de revisar conexiones y dependencias posteriores. Power Apps, Power Automate, Power Pages, Microsoft Copilot Studio y determinadas cargas Dynamics 365 pueden necesitar pasos adicionales.
Documentación oficial: Microsoft – Power Platform tenant-to-tenant migrations.
Las aplicaciones son el gran olvidado
Una migración puede completar correctamente Exchange, OneDrive y SharePoint y, aun así, provocar una incidencia grave el lunes siguiente si una aplicación empresarial deja de autenticarse.
Esto ocurre porque numerosas aplicaciones almacenan referencias propias del tenant:
Tenant ID, Application ID, Object ID, redirect URI, secretos, certificados, service principals, permisos Graph, URLs de SharePoint o cuentas utilizadas para SMTP y automatización.
Por tanto, el inventario debe identificar no solo qué aplicaciones existen, sino también quién es su propietario, cómo autentican y qué dependencias tienen.
| Tipo de integración | Qué puede necesitar después del cambio |
|---|---|
| SSO | Crear Enterprise Application y configurar nuevo tenant. |
| SCIM | Reconfigurar provisioning y mapping. |
| Graph API | Nuevo consentimiento, app registration o permisos. |
| SMTP | Actualizar cuenta, autenticación y configuración. |
| SharePoint | Actualizar URLs, permisos y conexiones. |
| Power Automate | Recrear conexiones o connection references. |
Qué herramienta utilizar para una migración tenant-to-tenant
La respuesta depende completamente del proyecto. Microsoft está cubriendo cada vez más escenarios de forma nativa, pero una plataforma especializada sigue aportando ventajas cuando se necesita coexistencia avanzada, migración multiworkload, reporting centralizado, premigración o mayor control sobre Teams y SharePoint.
| Opción | Puntos fuertes | Cuándo evaluarla |
|---|---|---|
| Microsoft nativo | Integración directa en Microsoft 365 y movimiento de datos dentro de la plataforma. | Cuando workloads, licencias y modelo operativo encajan con las funciones nativas. |
| Quest On Demand Migration | Discovery, mapping, Exchange, OneDrive, SharePoint, Teams y coexistencia desde una plataforma central. | Proyectos complejos o con múltiples workloads. |
| ShareGate | Especialización en SharePoint, Teams, OneDrive y gobierno de Microsoft 365. | Proyectos con fuerte componente documental y de colaboración. |
| BitTitan MigrationWiz | Experiencia consolidada en correo y distintos escenarios de migración. | Proyectos centrados especialmente en Exchange y datos de usuario. |
| Cloudiway | Escenarios multiworkload y cross-platform. | Entornos con necesidades diversas de correo, colaboración y coexistencia. |
Quest On Demand Migration
Quest On Demand Migration es especialmente interesante cuando se necesita trabajar con varios workloads desde una única consola. Permite realizar descubrimiento, mapping de usuarios, migraciones y determinados escenarios de coexistencia.
Para organizaciones con Exchange Online, OneDrive, SharePoint y Teams, la posibilidad de centralizar operaciones y reporting puede simplificar significativamente la gestión del proyecto.
Referencia oficial: Quest – On Demand Migration.
ShareGate, BitTitan y Cloudiway
ShareGate suele tener especial interés en proyectos con fuerte presencia de SharePoint y Teams. BitTitan continúa siendo una referencia conocida para migraciones de correo y otros datos, mientras que Cloudiway ofrece soluciones para diferentes escenarios multiworkload y cross-platform.
Ninguna de estas plataformas debería seleccionarse únicamente por una lista de funcionalidades comerciales. Antes de comprar licencias conviene validar qué elementos concretos soporta la versión actual, qué permisos requiere, cómo gestiona deltas, qué hace con permisos y enlaces y cómo presenta el contenido migrado al usuario.
En Kloudeal trabajamos la herramienta después del diseño
No todas las migraciones necesitan la misma tecnología. Podemos analizar el entorno y plantear una estrategia con herramientas nativas de Microsoft, Quest On Demand Migration u otras soluciones cuando resulte más adecuado.
Revisar mi escenario de migraciónMetodología recomendada para una migración tenant-to-tenant
Una migración bien organizada suele recorrer las mismas fases, independientemente de la herramienta elegida.
| Fase | Objetivo | Resultado esperado |
|---|---|---|
| 1. Discovery | Entender ambos tenants y sus dependencias. | Inventario y mapa del entorno. |
| 2. Assessment | Identificar riesgos, incompatibilidades y decisiones necesarias. | Alcance definitivo. |
| 3. Diseño | Definir identidad, dominios, coexistencia, herramientas y oleadas. | Arquitectura de migración. |
| 4. Preparación | Construir usuarios, licencias, mapping y configuraciones de destino. | Tenant destino preparado. |
| 5. Piloto | Probar el procedimiento completo. | Errores conocidos y procedimiento corregido. |
| 6. Premigración | Copiar datos anticipadamente cuando la herramienta lo permita. | Menor volumen pendiente para el corte. |
| 7. Oleadas | Migrar grupos controlados de usuarios. | Transición progresiva. |
| 8. Cutover | Ejecutar cambios finales de identidad, dominio y acceso. | Usuarios operando en destino. |
| 9. Validación | Verificar datos, accesos y funcionamiento. | Aceptación técnica y funcional. |
| 10. Hypercare | Resolver incidencias post-cambio. | Entorno estabilizado. |
| 11. Decommission | Eliminar coexistencia y configuraciones temporales. | Arquitectura definitiva. |
Por qué el piloto es mucho más que “migrar dos usuarios”
Un piloto solo aporta valor si representa la realidad. Elegir dos usuarios con buzones pequeños, sin delegaciones, sin Teams y con pocos documentos puede dar una falsa sensación de seguridad.
El piloto debería incluir perfiles diferentes: un usuario con buzón grande, otro con archivo online, alguien que gestione buzones compartidos, un propietario de Teams, un usuario con OneDrive grande, usuarios con acceso externo y, si existen, perfiles con aplicaciones críticas.
También debería probarse la experiencia completa. No basta con que la herramienta indique “Success”: el usuario debe iniciar sesión, abrir Outlook, consultar el calendario, acceder a OneDrive, abrir Teams y utilizar las aplicaciones que necesita para trabajar.
El cutover: donde todas las decisiones se encuentran
El cutover es la ventana en la que se realizan los cambios que no pueden adelantarse. Puede incluir dominio, DNS, correo, identidad, perfiles de Outlook, sincronización de OneDrive y aplicaciones.
En lugar de una lista improvisada de tareas, conviene utilizar un runbook de cutover con responsables, orden, validaciones y criterios de decisión.
| Momento | Acciones principales |
|---|---|
| Antes del corte | Comprobar jobs, errores, licencias, mappings, backups, DNS y soporte. |
| Inicio | Detener cambios cuando sea necesario y ejecutar sincronización final. |
| Dominio | Liberar origen, añadir destino y publicar registros necesarios. |
| Servicios | Completar correo, OneDrive, Teams y otros workloads. |
| Aplicaciones | Activar configuraciones que dependían del nuevo tenant o dominio. |
| Validación | Ejecutar pruebas técnicas y funcionales. |
| Comunicación | Confirmar a usuarios el cambio y las acciones que deben realizar. |
La migración no termina cuando aparece “Completed”
Esta es probablemente la idea más importante después de la planificación. Un job puede completarse correctamente y, aun así, existir un problema de permisos, una aplicación sin configurar o un enlace que haya dejado de funcionar.
La validación debe hacerse por workload y, cuando sea posible, combinar controles técnicos con una comprobación funcional realizada por usuarios o propietarios de negocio.
| Área | Pruebas mínimas |
|---|---|
| Identidad | Login, UPN, MFA, Conditional Access y pertenencia a grupos. |
| Exchange | Envío, recepción, calendario, shared mailboxes y delegaciones. |
| OneDrive | Archivos, permisos, sincronización, sharing y redirecciones. |
| SharePoint | Sitios, documentos, versiones, permisos, enlaces y externos. |
| Teams | Equipos, canales, chats esperados, reuniones y archivos. |
| Aplicaciones | SSO, APIs, conectores, SMTP, SCIM y automatizaciones. |
| Seguridad | Defender, Purview, Conditional Access y políticas requeridas. |
Hypercare
Después del cambio conviene reservar un periodo de soporte reforzado. Muchas incidencias no aparecen inmediatamente. Un usuario puede descubrir tres días después que ha perdido acceso a un buzón compartido que solo utiliza una vez por semana, o que un enlace de SharePoint utilizado por un proveedor externo ha cambiado.
El objetivo del hypercare no es únicamente responder tickets. También sirve para encontrar patrones, corregir configuraciones y confirmar que el entorno puede pasar a operación normal.
Errores que más problemas generan
Los proyectos tenant-to-tenant suelen fallar por decisiones previas más que por el proceso de copia en sí.
| Error | Consecuencia | Cómo reducir el riesgo |
|---|---|---|
| Elegir herramienta primero | Descubrir después que no cubre un workload crítico. | Assessment antes de comprar licencias. |
| No inventariar aplicaciones | ERP, CRM o automatizaciones dejan de funcionar. | Inventario de Enterprise Apps y App Registrations. |
| No revisar holds | Buzones bloqueados para migración nativa. | Revisión previa con compliance. |
| Aprovisionar OneDrive destino | Puede bloquear el movimiento nativo. | Controlar cuándo puede acceder el usuario. |
| Crear sitio SharePoint destino | La migración nativa puede fallar. | Seguir los prerrequisitos del método elegido. |
| No probar permisos | Usuarios con acceso insuficiente o excesivo. | Validación funcional por propietarios. |
| Subestimar el dominio | Retraso en cutover y problemas de correo. | Limpiar referencias y preparar DNS previamente. |
| No comunicar | Gran volumen de incidencias evitables. | Plan de comunicación antes, durante y después. |
| Prometer impacto cero | Expectativas imposibles de cumplir. | Explicar qué cambios experimentará el usuario. |
Preguntas frecuentes sobre migraciones tenant-to-tenant de Microsoft 365
Es el proceso de trasladar usuarios, datos y servicios desde un tenant de Microsoft 365 hacia otro. Puede incluir Exchange Online, OneDrive, SharePoint, Teams, dominios, aplicaciones y otros servicios.
Es habitual en fusiones, adquisiciones, escisiones, consolidaciones o reorganizaciones empresariales.
No existe una duración estándar. Un entorno pequeño puede resolverse en pocas oleadas, mientras que una empresa con cientos o miles de usuarios, varios dominios, SharePoint complejo, Teams y aplicaciones puede necesitar semanas o meses.
El volumen de datos es solo uno de los factores. La coexistencia, las dependencias y la capacidad para validar y dar soporte suelen tener igual o mayor importancia.
Sí. Microsoft dispone actualmente de capacidades nativas para Exchange Online, OneDrive y SharePoint, además de Migration Orchestrator para coordinar determinados movimientos multiworkload.
No obstante, cada capacidad tiene requisitos, licencias y limitaciones propias.
No debería darse por hecho. Los distintos servicios tienen modelos y dependencias diferentes.
Incluso utilizando una plataforma multiworkload, elementos como aplicaciones, políticas de seguridad, Power Platform o configuraciones de Purview pueden necesitar procesos independientes.
Las herramientas cross-tenant individuales permiten trabajar directamente sobre workloads concretos como Exchange, OneDrive o SharePoint.
Migration Orchestrator busca coordinar varios workloads de los mismos usuarios y gestionar dependencias y batches desde una experiencia común.
Sí. Microsoft dispone actualmente de Cross-tenant SharePoint Migration.
El sitio destino no debe existir previamente, no puede fusionarse con contenido existente y el proceso es one-and-done, sin deltas posteriores. Además existen requisitos específicos de licenciamiento y límites técnicos.
Microsoft documenta actualmente un máximo de 5 TB o 1 millón de elementos por sitio para el mecanismo cross-tenant de SharePoint.
Estos límites deben comprobarse nuevamente antes del proyecto porque Microsoft puede actualizar el servicio.
No. Cross-tenant OneDrive Migration es actualmente una operación one-and-done.
Esto significa que no funciona como una herramienta tradicional donde se realiza una premigración y después se sincronizan únicamente los cambios.
Es un punto crítico. Para el mecanismo cross-tenant nativo de Microsoft, el OneDrive destino no debe haberse aprovisionado previamente.
Por eso el orden en el que se crean usuarios, asignan licencias y habilitan servicios debe planificarse cuidadosamente.
Microsoft deja redirecciones desde determinadas ubicaciones de origen después de los movimientos cross-tenant nativos de OneDrive y SharePoint, lo que ayuda a mantener enlaces.
Aun así, los enlaces importantes deben incluirse en la validación post-migración.
Sí. Microsoft dispone de Cross-tenant Mailbox Migration y existen también distintas herramientas de terceros.
El tenant destino debe prepararse correctamente y hay que revisar atributos, permisos, shared mailboxes, archivos online, dominios y coexistencia.
La documentación actual de Microsoft indica que los buzones bajo cualquier tipo de hold quedan bloqueados para el movimiento cross-tenant nativo.
El requisito de retención debe revisarse con los responsables de cumplimiento antes de realizar cualquier cambio.
Sí, el contenido visible que Microsoft describe para su movimiento nativo de Exchange incluye calendario, además de correo, contactos, tareas y notas.
Después de la migración conviene validar reuniones, permisos delegados y calendarios compartidos.
Pueden formar parte del proyecto, pero deben inventariarse y planificarse explícitamente. Su tratamiento depende del método utilizado, licenciamiento y relaciones con usuarios.
También deben comprobarse posteriormente Full Access, Send As y Send on Behalf.
Sí, pero “Teams” engloba varios tipos de información.
Chats, reuniones, equipos, canales, archivos, Planner, apps y pestañas no deben tratarse como un único objeto. El alcance exacto depende del método o herramienta utilizada.
La documentación actual de Microsoft incluye Teams chats y Teams meetings dentro de los workloads tratados por el servicio de orquestación.
Para Teams, canales y otros datos compartidos conviene validar el alcance actualizado antes de la ejecución.
No deben olvidarse. Microsoft dispone de un procedimiento tenant-to-tenant para determinados entornos Power Platform, pero conexiones, propietarios, SharePoint, Dataverse, Power Pages y otras dependencias pueden necesitar reconfiguración.
No debe suponerse que sí.
Retention, etiquetas de sensibilidad, DLP, eDiscovery, auditoría y otras configuraciones deben inventariarse y diseñarse en el tenant destino de acuerdo con los requisitos de la organización.
El dominio corporativo no puede simplemente utilizarse de forma equivalente en ambos tenants para los mismos servicios.
Durante la preparación suelen utilizarse dominios temporales o direcciones onmicrosoft.com y el dominio principal se traslada durante una ventana de corte planificada.
Depende del escenario y de cómo se gestione identidad, dominio y perfil. Algunos usuarios pueden necesitar autenticarse de nuevo o recrear el perfil.
Este comportamiento debe probarse durante el piloto para poder dar instrucciones concretas al resto de la organización.
No hay una respuesta universal.
Las capacidades nativas pueden ser excelentes cuando el escenario encaja con sus requisitos. Quest On Demand Migration puede aportar ventajas en proyectos multiworkload donde se necesita discovery, mapping, coexistencia, premigraciones, reporting y una plataforma de gestión centralizada.
No siempre es un requisito de la tecnología, pero es una de las mejores formas de reducir riesgos.
El piloto permite comprobar el procedimiento real de inicio a fin antes de afectar a toda la organización.
El proyecto debe diseñarse para reducir el impacto, pero no es recomendable prometer impacto cero.
Cambios de dominio, autenticación, Outlook, Teams, OneDrive o aplicaciones pueden requerir acciones por parte del usuario o pequeñas ventanas de indisponibilidad.
Como mínimo deben comprobarse identidad, MFA, correo entrante y saliente, calendarios, shared mailboxes, OneDrive, SharePoint, Teams, permisos, enlaces, aplicaciones, dispositivos, DNS, licencias y políticas de seguridad.
Cuando existen varios dominios, cientos de usuarios, identidad híbrida, SharePoint complejo, Teams, requisitos regulatorios, aplicaciones críticas o poco margen para errores durante el cutover.
También puede ser útil cuando el equipo interno necesita apoyo puntual para diseñar arquitectura, ejecutar la migración o validar el resultado.
Conclusión: una buena migración se decide antes de empezar a copiar datos
Una migración tenant to tenant de Microsoft 365 es un proyecto de identidad, datos, colaboración y seguridad. La tecnología que mueve el contenido es importante, pero solo representa una parte del trabajo.
Microsoft ofrece actualmente muchas más capacidades nativas que hace unos años: Exchange Online, OneDrive, SharePoint, Migration Orchestrator e Identity Mapping forman ya un ecosistema de herramientas cross-tenant mucho más completo. Sin embargo, cada una tiene su propio comportamiento, licencias y limitaciones.
En determinados proyectos, estas capacidades serán suficientes. En otros, herramientas como Quest On Demand Migration, ShareGate, BitTitan o Cloudiway pueden ofrecer un modelo más adecuado, especialmente cuando hay varias cargas, necesidad de premigraciones, coexistencia avanzada o requisitos específicos sobre Teams y SharePoint.
La decisión correcta empieza siempre igual: conocer qué hay en los dos tenants, definir qué debe quedar en destino y construir un plan que contemple identidad, dominios, datos, aplicaciones, seguridad y usuarios.
Después vienen la herramienta, el piloto, las oleadas y el cutover. Y solo cuando los usuarios pueden trabajar correctamente y las validaciones han terminado puede considerarse cerrada la migración.
¿Estás preparando una migración tenant-to-tenant de Microsoft 365?
En Kloudeal podemos ayudarte desde el análisis inicial hasta la estabilización del nuevo tenant.
Revisamos origen y destino, usuarios, dominios, Exchange Online, OneDrive, SharePoint, Teams, aplicaciones, identidad y requisitos de seguridad para diseñar una estrategia de migración adaptada al entorno real.
Podemos trabajar con herramientas nativas de Microsoft, Quest On Demand Migration y otras plataformas especializadas, seleccionando la tecnología después de analizar qué necesita realmente el proyecto.
Hablar con Kloudeal sobre mi migración tenant to tenantDocumentación oficial recomendada
Las funcionalidades cross-tenant están evolucionando rápidamente. Antes de ejecutar una migración conviene consultar siempre la documentación vigente del workload correspondiente.
Microsoft 365 y Migration Orchestrator
- Microsoft – Plan a Microsoft 365 tenant-to-tenant migration
- Microsoft – Microsoft 365 migration overview
- Microsoft – Migration Orchestrator overview
- Microsoft – Migration Orchestrator planning and prerequisites
- Microsoft – Migration Orchestrator FAQ