Migración entre tenants Microsoft 365
MSAdvance planifica y ejecuta migraciones de Microsoft 365 entre tenants para organizaciones que necesitan mover usuarios, correo, OneDrive, SharePoint, Teams, identidades y dominios con un alcance claro, un cutover coordinado y una validación completa del entorno de destino.
Tenant-to-TenantAlcance, identidades, workloads, dominios y cutover se coordinan como un único proyecto.
Un único proyecto para coordinar identidad, datos, dominio y cutover
Una migración entre tenants de Microsoft 365 es el proceso de trasladar cargas y servicios de una organización desde un tenant a otro. MSAdvance se encarga de convertir ese objetivo en un proyecto ejecutable: qué se mueve, con qué método, en qué orden, qué impacto tendrá y cómo se valida el resultado.
El alcance puede ser completo o parcial. Podemos responsabilizarnos de todo el proyecto o trabajar únicamente sobre determinadas cargas, coordinándonos con su equipo interno o con otros proveedores cuando sea necesario.
Especialistas en Microsoft 365 para proyectos donde no basta con mover datos
En una migración tenant-to-tenant, los problemas suelen aparecer en las dependencias: identidades, permisos, dominio, Teams, retenciones, dispositivos o aplicaciones. MSAdvance aporta un equipo especializado que analiza esas dependencias antes del cutover y se responsabiliza de la ejecución técnica hasta la estabilización del alcance acordado.
Cuándo tiene sentido una migración entre tenants Microsoft 365
La causa de negocio determina la arquitectura, las cargas y el orden del proyecto. Estos son los escenarios en los que más habitualmente ayudamos a equipos de IT y organizaciones que necesitan pasar de varios entornos a una situación estable y administrable.
Fusión o adquisición
Consolidación de dos organizaciones en un tenant común, con coexistencia temporal y migración por cargas y oleadas.
Carve-out o separación
Separación controlada de una unidad, filial o negocio, moviendo únicamente los usuarios, datos y servicios que deben salir del tenant origen.
Cambio de dominio
Reorganización de identidades y correo con liberación del dominio en origen, alta en destino y actualización coordinada de DNS.
Consolidación de IT
Reducción de tenants históricos, simplificación de gobierno y normalización de identidades, colaboración y administración.
Un ejemplo real de una consolidación tenant-to-tenant
En uno de nuestros proyectos publicados, una organización necesitaba consolidar dos tenants tras una fusión manteniendo los servicios operativos y coordinando Exchange Online, OneDrive, SharePoint, Teams, Entra ID y el movimiento final del dominio.
800 usuarios y aproximadamente 12 TB consolidados en un único tenant
El trabajo se organizó con discovery técnico, coexistencia, piloto, oleadas, movimiento de dominio y hypercare. El caso muestra también incidencias reales relacionadas con retenciones, throttling, Teams y aplicaciones SSO, y cómo se trataron durante el proyecto.
Lo relevante no es repetir estas cifras en todos los proyectos. Es demostrar que la metodología puede adaptarse a entornos con volumen, dependencias y ventanas de cambio exigentes.
Qué se puede migrar entre tenants Microsoft 365 y cómo lo tratamos
El servicio puede incluir las principales cargas de Microsoft 365 y otros componentes asociados. Para cada una definimos el método, los requisitos, las limitaciones y las comprobaciones de aceptación antes de incorporarla al plan de migración.
Exchange Online
Nativo disponibleBuzones de usuario y contenido visible por el usuario mediante cross-tenant mailbox migration cuando el escenario cumple requisitos.
- Correo, contactos, calendario, tareas y notas.
- Preparación de objetos MailUser y relaciones entre organizaciones.
- Entrega, libre/ocupado y coexistencia según diseño.
OneDrive
Nativo disponibleMigración cross-tenant de OneDrive con mapeo de identidades y redirección posterior cuando aplica.
- Archivos, carpetas y permisos asociados a identidades mapeadas.
- El OneDrive de destino no debe existir previamente.
- El movimiento nativo es de una sola pasada, sin deltas posteriores.
SharePoint Online
Nativo disponibleMicrosoft dispone actualmente de migración cross-tenant de sitios de SharePoint con requisitos específicos de preparación y licenciamiento.
- Sitios y contenido con permisos mapeados.
- Redirecciones posteriores para contenido migrado.
- Revisión separada de integraciones, apps, automatizaciones y taxonomía.
Microsoft Teams
Método mixtoTeams combina datos personales y datos compartidos. Microsoft Migration Orchestrator contempla chats y reuniones, mientras que equipos y canales compartidos quedan fuera de ese alcance y requieren otro enfoque.
- Chats y reuniones: según capacidad nativa y estado del servicio.
- Equipos, canales y archivos: estrategia específica por proyecto.
- Apps, pestañas, conectores y telefonía: revisión independiente.
Entra ID e identidades
Preparación y mappingLa migración de contenido no migra identidades. Los usuarios de destino deben crearse y mapearse correctamente antes de mover los datos.
- UPN, proxyAddresses y atributos necesarios.
- Cross-Tenant Identity Mapping cuando corresponde.
- Grupos, B2B, MFA y Conditional Access se revisan por separado.
Dominio y DNS
Cutover críticoEl dominio debe quedar libre de referencias en el tenant origen antes de poder añadirse al destino. Se trata como una fase de cutover, no como una tarea administrativa menor.
- UPN, alias, grupos y objetos que todavía referencian el dominio.
- MX, SPF, DKIM y DMARC.
- Validación de envío, recepción y resolución DNS.
Intune y dispositivos
ReconfiguraciónEl cambio de tenant puede exigir reinscripción o reprovisionamiento de dispositivos y recreación o adaptación de configuración.
- Perfiles, apps, cumplimiento y Autopilot.
- Plan de re-enrolado y comunicación.
- Revisión de dependencias con identidad y seguridad.
Power BI y Power Platform
Según alcanceWorkspaces, informes, modelos, conexiones, gateways, flujos y aplicaciones deben analizarse individualmente.
- Inventario y criticidad.
- Permisos, conexiones y credenciales.
- Recreación o migración según componente y herramientas.
Un proyecto controlado empieza por definir alcance e impacto antes del cutover
La metodología se adapta al entorno, pero el principio es siempre el mismo: llegar al cutover con las decisiones importantes tomadas, el destino preparado y un procedimiento que el equipo del cliente conozca de antemano.
La migración se diseña antes de que empiece la ventana de cambio
El assessment permite definir el método por workload, las dependencias de identidad y dominio, la preparación del destino, el impacto para los usuarios y los criterios de validación antes de ejecutar cambios productivos.
Objetivo y alcance
Qué tenants participan, qué workloads entran, responsables, restricciones y ventana objetivo.
Inventario técnico
Usuarios, buzones, sitios, Teams, grupos, dominios, identidad, retenciones, aplicaciones y dispositivos.
Arquitectura y mapping
Tenant objetivo, identidad, dominio, método por workload, oleadas y dependencias.
Preparación del destino
Usuarios, permisos, licencias, herramientas, relaciones de confianza, DNS y controles.
Validación del método
Prueba representativa para confirmar tiempos, permisos, experiencia de usuario y runbook.
Precargas y preparación
Trabajo previo al cutover cuando el workload y la herramienta permiten staging o deltas.
Cambio controlado
Ejecución, dominio y DNS, finalización de lotes, validaciones críticas y comunicación.
Estabilización
Soporte reforzado, validación funcional, incidencias, documentación y cierre.
Qué recibe el cliente en un proyecto de migración tenant-to-tenant
El cliente no recibe únicamente una migración ejecutada. Recibe un proyecto trazable: qué se decidió, qué se movió, cómo se hizo, qué se validó y qué queda pendiente después del cambio.
Assessment del entorno
Inventario de cargas, usuarios, dominios, dependencias, volumen y puntos que condicionan el método de migración.
Matriz origen-destino
Correspondencia de usuarios, buzones, grupos, sitios, Teams, dominios y otros objetos incluidos en el alcance.
Plan técnico de migración
Método por workload, prerequisitos, herramientas, orden de ejecución, oleadas y responsabilidades.
Plan de cutover
Secuencia de tareas para el cambio, criterios Go/No-Go, DNS, validaciones y coordinación con el equipo del cliente.
Validación y evidencias
Comprobaciones acordadas sobre datos, acceso, permisos, correo, colaboración y elementos críticos después del movimiento.
Cierre y handover
Resumen de incidencias, pendientes, cambios realizados, recomendaciones y retirada de accesos temporales cuando proceda.
Soporte de estabilización
Atención a incidencias ligadas al cambio durante el periodo de soporte definido en el alcance del proyecto.
Siguientes pasos
Recomendaciones sobre seguridad, gobierno, licencias o arquitectura cuando el tenant de destino necesita una fase posterior.
Qué puede notar el usuario durante una migración tenant-to-tenant
No prometemos que todos los workloads sean invisibles para el usuario. Definimos el impacto esperado, lo comunicamos y preparamos el cutover para que el cambio sea previsible y el soporte pueda responder con rapidez.
Puede requerir cierre/reapertura de sesión, recreación o actualización del perfil y validación posterior de Autodiscover, correo y calendario según el método elegido.
En la migración nativa puede existir un breve periodo de solo lectura. Después se valida el acceso al nuevo OneDrive y la sincronización del cliente.
Se comunica una ventana de cambio para los sitios afectados y se valida acceso, permisos, enlaces y contenido después de la migración.
Los usuarios pasan a trabajar con su identidad de destino y pueden necesitar reconectar equipos, reuniones o elementos que no se hayan movido de forma nativa.
Es uno de los pasos más sensibles. La retirada del dominio del origen, su alta en destino y el cambio de DNS deben estar secuenciados con precisión.
Cuando entran en alcance, la experiencia depende del método de re-enrolado y del tipo de dispositivo. Se prepara un plan específico de usuario y soporte.
Acceso administrativo limitado al trabajo que necesita el proyecto
La migración exige permisos técnicos, pero esos permisos deben estar definidos, controlados y retirarse cuando dejan de ser necesarios. El modelo concreto se adapta a las restricciones del cliente y a las herramientas utilizadas.
Durante el proyecto
- Roles y cuentas administrativas definidos para el alcance necesario.
- MFA y controles de acceso compatibles con la ejecución técnica.
- PIM, permisos temporales o modelos equivalentes cuando el entorno y el cliente lo permiten.
- Aplicaciones, service principals y consentimientos documentados.
- NDA y adaptación a procedimientos internos de seguridad cuando aplica.
Al finalizar
- Revisión y retirada de permisos que ya no sean necesarios.
- Eliminación o revocación de aplicaciones y consentimientos temporales cuando proceda.
- Entrega de evidencias, informes o documentación definida en el alcance.
- Validación de que la administración ordinaria queda de nuevo bajo control del cliente.
- Recomendaciones de seguridad y gobierno para el tenant de destino.
Cómo se calcula el coste de una migración entre tenants Microsoft 365
Publicamos referencias “desde” para que pueda hacerse una primera idea del coste. El presupuesto definitivo se construye sobre el alcance real, evitando incluir cargas o herramientas que el proyecto no necesita.
Buzón de usuario
25 €Desde / buzón
- Alcance estándar de buzón.
- Preparación y validación según proyecto.
- Licencias y extras se presupuestan aparte.
Cuenta de usuario
10 €Desde / cuenta
- Migración de contenido personal.
- Mapeo y validación según método.
- El volumen y las excepciones pueden alterar el coste.
Equipo
40 €Desde / equipo
- Estructura y colaboración según alcance.
- Archivos asociados se coordinan con SharePoint.
- Chats, reuniones, apps y voz se revisan aparte.
Sitio o grupo
40 €Desde / sitio
- Sitios y bibliotecas estándar.
- Permisos, grupos y metadatos según alcance.
- Apps, automatizaciones y taxonomía pueden requerir trabajo adicional.
Qué información necesitamos para dimensionar el proyecto
Con estos datos podemos preparar una primera estimación con bastante precisión y decirle rápidamente si necesitamos un assessment más profundo antes de presentar una propuesta cerrada.
Cómo elegimos entre Microsoft nativo, herramientas especializadas y enfoque mixto
No existe una única herramienta que sea la mejor para todos los tenants. La elección depende de las cargas incluidas, el estado del origen y del destino, la coexistencia necesaria, el nivel de reporting y los elementos que Microsoft no cubre de forma nativa.
Cuando el escenario encaja con los requisitos
Es una buena opción para cargas con capacidad cross-tenant soportada y un destino preparado conforme a los requisitos de Microsoft. Reduce intermediarios y mantiene el movimiento dentro del ecosistema Microsoft.
Cuando se necesita más cobertura o control
Puede ser necesaria para Teams, coexistencia avanzada, reporting, transformaciones, migraciones por lotes complejas o elementos que no tienen un camino nativo equivalente.
La opción habitual en proyectos complejos
Combina capacidades nativas, herramientas especializadas y automatización para tratar cada workload con el método más adecuado, sin forzar todo el proyecto a una sola plataforma.
Qué evaluamos antes de elegir herramienta
Lo que evitamos
No recomendamos una herramienta solo porque sea la que se utilizó en otro proyecto. Una plataforma puede ser excelente para correo y no ser la mejor para Teams, o puede aportar funciones que no compensen el coste en un tenant pequeño.
Quest On Demand Migration, Cloudiway, BitTitan, AvePoint, ShareGate y capacidades nativas de Microsoft
MSAdvance no obliga a ejecutar todos los proyectos tenant-to-tenant sobre una única plataforma. Mantenemos relaciones directas con fabricantes seleccionados de este ecosistema y combinamos sus herramientas con capacidades nativas de Microsoft, PowerShell y Microsoft Graph según los workloads, la coexistencia, el reporting y las restricciones del proyecto.
Quest On Demand Migration
Nuestra plataforma especializada de referencia para programas Microsoft 365 tenant-to-tenant complejos, especialmente M&A, carve-outs y migraciones multi-workload donde importan el control centralizado, las oleadas, la coexistencia y el reporting.
Cloudiway
Una opción especialmente interesante cuando el proyecto va más allá de un movimiento Microsoft-to-Microsoft sencillo o cuando la coexistencia tiene un peso importante durante la transición.
BitTitan MigrationWiz
Una opción SaaS práctica para proyectos cloud-to-cloud con alcance bien delimitado, donde se prioriza una configuración rápida, lotes repetibles y cargas de correo o documentos claramente definidas.
AvePoint Fly
Interesante cuando el proyecto incluye un estate Microsoft 365 amplio, discovery avanzado o componentes de Power Platform además de las principales cargas de colaboración.
ShareGate Migrate
Especialmente útil en proyectos Microsoft 365 con gran peso documental donde la arquitectura de información, permisos, metadatos, versiones, autoría y reestructuración requieren especial atención.
Capacidades nativas de Microsoft
Cuando Microsoft dispone de una vía nativa que encaja con el escenario, la evaluamos antes de introducir otra plataforma. También podemos combinar capacidades nativas y herramientas especializadas dentro del mismo programa.
Qué aporta Microsoft de forma nativa
Microsoft ha ampliado de forma importante sus capacidades tenant-to-tenant. Esto permite utilizar servicios nativos en más escenarios, pero no convierte todos los workloads en una única migración automática. Migration Orchestrator está actualmente documentado por Microsoft como una capacidad en preview, por lo que disponibilidad, comportamiento y requisitos deben volver a validarse durante el assessment del proyecto.
Migration Orchestrator
Orquesta contenido personal de usuario. Actualmente contempla buzones de Exchange, OneDrive, chats de Teams y reuniones de Teams. No migra datos compartidos como equipos/canales ni sitios de SharePoint dentro de ese mismo alcance.
Documentación oficial MicrosoftExchange cross-tenant
Permite mover buzones entre tenants con requisitos de objetos de destino, relaciones entre organizaciones y licencias de Cross-Tenant User Data Migration. Los buzones con holds pueden quedar bloqueados.
Cross-tenant mailbox migrationOneDrive cross-tenant
Microsoft mueve el contenido dentro de Microsoft 365. El OneDrive de destino no debe estar provisionado previamente y el movimiento nativo es una operación de una sola pasada.
Migración de OneDrive entre inquilinosSharePoint cross-tenant
Los sitios de SharePoint pueden trasladarse entre tenants con PowerShell y mapeo de identidades. Microsoft indica que pueden programarse hasta 4.000 migraciones pendientes a la vez.
Migración de SharePoint entre inquilinosCross-Tenant Identity Mapping
CTIM ayuda a mapear usuarios entre origen y destino y a preparar atributos necesarios para la migración. Es una pieza de preparación y correspondencia de identidades, no una copia de los datos del usuario.
Cross-Tenant Identity MappingPlanificación por dependencias
Microsoft recomienda planificar la identidad, el dominio y la secuencia por workload. Teams depende de Exchange en determinados escenarios y OneDrive/SharePoint comparten modelos de permisos.
Planificar una migración T2TCómo lo aplicamos en MSAdvance: usamos la capacidad nativa cuando encaja con el alcance y el licenciamiento. Cuando una carga o requisito no queda cubierto, se define una vía adicional con herramientas especializadas, automatización o reconfiguración. El criterio es el resultado del proyecto, no imponer una única herramienta.
Qué conviene confirmar antes de cerrar el alcance
Una propuesta fiable debe dejar claros desde el principio los elementos que tienen soporte directo, los que necesitan preparación y los que pueden requerir reconfiguración. Estos son algunos de los puntos que revisamos antes de comprometer método y alcance.
La migración de contenido no crea por sí sola la identidad corporativa final. Hay que crear y mapear usuarios y revisar grupos, roles y políticas.
Migration Orchestrator no mueve los datos compartidos de equipos y canales. El proyecto debe contemplar una estrategia adicional para estructura, archivos y configuración.
Las integraciones de Teams, SharePoint y aplicaciones de terceros pueden necesitar reconfiguración o reinstalación en el destino.
Los dispositivos pueden requerir reinscripción y las configuraciones deben analizarse antes del cambio.
Las retenciones legales y determinadas políticas pueden bloquear o alterar el método nativo de migración; deben identificarse antes de ejecutar.
Las capacidades nativas tienen requisitos estrictos sobre la existencia previa de cuentas o sitios de destino y no funcionan como una operación de merge genérica.
Qué validamos antes de autorizar el cutover
La mayoría de los problemas graves no aparecen por la velocidad de copia, sino por una dependencia que no se detectó antes. Esta es la lista mínima que revisamos antes de aprobar la ventana de cambio.
Preguntas habituales sobre migraciones tenant-to-tenant
¿Qué es una migración tenant-to-tenant de Microsoft 365?
Es el proceso de trasladar datos y servicios de un tenant de Microsoft 365 a otro. Puede incluir buzones de Exchange Online, OneDrive, SharePoint, Teams, identidades, dominio, grupos y otros componentes. Cada carga tiene su propio método y sus propios requisitos. En búsquedas y documentación histórica también puede aparecer como migración Office 365 tenant-to-tenant.
¿Se puede migrar todo automáticamente?
No. Microsoft dispone de capacidades nativas importantes, pero no todo el ecosistema Microsoft 365 se mueve de la misma forma. Teams compartido, apps, pestañas, telefonía, Intune, Power BI, Power Platform o determinadas configuraciones pueden requerir herramientas adicionales o reconfiguración.
¿Qué soporta Migration Orchestrator?
La documentación actual de Microsoft indica cuatro workloads para el contenido personal de usuario: buzones de Exchange, OneDrive, chats de Teams y reuniones de Teams. Los datos compartidos como Teams/canales y sitios de SharePoint no se mueven dentro de ese mismo alcance; SharePoint dispone de una capacidad cross-tenant separada.
¿Cuánto tarda una migración entre tenants?
Depende del número de usuarios, volumen de correo y archivos, número de sitios y Teams, complejidad del dominio, identidad, throttling y método de cada carga. Un assessment permite estimar tiempos por oleadas y definir la ventana real de cutover.
¿Hay que mover el dominio?
No en todos los proyectos. Cuando el dominio corporativo debe pasar al tenant destino, hay que eliminar sus referencias del tenant origen, liberarlo, añadirlo al destino y actualizar identidades y DNS en el momento planificado.
¿OneDrive puede tener ya contenido en el destino?
Para la capacidad nativa cross-tenant de Microsoft, el OneDrive de destino no debe estar previamente provisionado. Si existe contenido en destino, es necesario analizar otra estrategia en lugar de asumir un merge automático.
¿Se pueden migrar Teams, canales y chats?
Sí pueden formar parte del proyecto, pero no todos siguen el mismo método. Chats y reuniones de usuario tienen capacidades nativas actuales; los datos compartidos de equipos/canales requieren un enfoque adicional, normalmente con herramientas y recreación controlada.
¿Qué ocurre con permisos y enlaces de SharePoint y OneDrive?
Las capacidades nativas utilizan mapeo de identidades para conservar permisos de usuarios y grupos incluidos. Microsoft también puede crear redirecciones desde el origen al destino para contenido migrado. Aun así, conviene validar enlaces, externos, integraciones y permisos después del movimiento.
¿Los buzones con retención legal se pueden migrar de forma nativa?
La documentación de Microsoft indica que los buzones con holds pueden bloquearse para la migración cross-tenant. Por eso las retenciones y necesidades de eDiscovery deben revisarse durante el assessment.
¿MSAdvance puede trabajar con el equipo interno de IT?
Sí. Es la forma habitual de abordar proyectos de este tipo. MSAdvance puede responsabilizarse de la parte de assessment, arquitectura, configuración, herramientas, ejecución y validación, coordinándose con los responsables internos de identidad, DNS, seguridad y soporte.
¿Se puede hacer un piloto antes del cutover?
Sí, y es recomendable en proyectos medianos o complejos. El piloto valida mapeos, tiempos, permisos, experiencia de usuario y procedimiento antes de ampliar a las oleadas principales.
¿Por qué contratar a una empresa especializada para una migración entre tenants?
Porque el riesgo suele estar en la coordinación entre workloads, identidades, dominio, seguridad y experiencia de usuario, no únicamente en copiar datos. Un equipo especializado puede detectar dependencias antes del cutover, seleccionar el método adecuado por carga y asumir la ejecución y validación del proyecto.
¿Qué necesitamos para recibir presupuesto?
Como mínimo: número de usuarios y buzones, OneDrive, volumen aproximado, número de sitios SharePoint y Teams, dominios implicados, modelo de identidad, otros workloads y la ventana prevista. Con esa base puede prepararse una primera estimación y decidir si hace falta un assessment más profundo.
Información técnica para evaluar una migración entre tenants Microsoft 365
La landing resume el servicio. Estas guías profundizan en los workloads y decisiones que normalmente revisan los equipos de IT antes de contratar o ejecutar un proyecto.
Migración Microsoft 365 entre tenants
Guía general sobre arquitectura, coexistencia, workloads, cutover y validación.
Leer guíaHerramientas y scripts para migrar tenants
Microsoft nativo, Quest, BitTitan, PowerShell y criterios para elegir el enfoque.
Leer guíaMigración de OneDrive entre tenants
Identidad, permisos, preparación del destino y particularidades del movimiento cross-tenant.
Leer guíaMigración de SharePoint entre tenants
Sitios, bibliotecas, permisos, páginas, hubs, automatizaciones e integraciones.
Leer guíaMigración de Microsoft Teams entre tenants
Equipos, canales, chats, reuniones, archivos, aplicaciones y dependencias de identidad.
Leer guíaProyecto real de migración tenant-to-tenant
Contexto, volúmenes, decisiones, incidencias y resultados de una consolidación de Microsoft 365.
Ver caso prácticoCuéntenos qué necesita mover y le ayudaremos a convertirlo en un proyecto viable
Indíquenos los tenants implicados, usuarios, buzones, OneDrive, SharePoint, Teams, dominios y cualquier otro componente relevante. Revisaremos el escenario y le diremos qué información falta, qué puntos requieren atención y cómo plantearíamos el proyecto.
