Coexistencia entre tenants de Microsoft 365: cómo mantener correo, calendarios, Teams y colaboración durante una migración

Cuando una empresa se fusiona con otra, adquiere una nueva sociedad, separa una unidad de negocio o decide consolidar varios entornos de Microsoft 365, rara vez todo puede trasladarse de un tenant a otro en una única noche.

Durante días, semanas o incluso meses pueden convivir usuarios en los dos entornos. Algunas personas ya tendrán su buzón en el tenant de destino, otras continuarán trabajando en el de origen; habrá documentos que todavía no se hayan migrado, equipos de Teams repartidos entre ambas organizaciones y usuarios que necesitarán consultar calendarios o acceder a aplicaciones del otro tenant.

Ese periodo es lo que denominamos coexistencia entre tenants de Microsoft 365.

Una coexistencia bien diseñada puede hacer que una migración por fases sea perfectamente manejable. Una coexistencia improvisada, en cambio, suele acabar generando rebotes de correo, usuarios duplicados, invitados difíciles de administrar, calendarios que no muestran disponibilidad, accesos excesivos y una creciente dependencia de configuraciones temporales que nadie se atreve a retirar.

Por eso el objetivo no debería ser intentar que dos tenants funcionen como si fueran uno. Microsoft 365 mantiene límites claros entre ellos. Lo importante es crear los puentes necesarios para que los usuarios puedan seguir trabajando mientras cada servicio se traslada al entorno definitivo.

En esta guía veremos cómo plantear esa transición en 2026 utilizando capacidades como Microsoft Entra B2B collaboration, Cross-tenant access settings, Cross-tenant synchronization, Multitenant Organization, Exchange Online organization relationships, Microsoft Teams shared channels y las herramientas nativas de migración cross-tenant de Microsoft 365.

Índice

1. Qué significa realmente coexistir entre tenants
2. Cuándo es necesaria la coexistencia
3. Qué no resuelve una arquitectura de coexistencia
4. El límite más importante: el dominio no puede estar en dos tenants
5. Arquitectura general de coexistencia
6. Identidad y Microsoft Entra B2B
7. Cross-tenant access settings
8. Cross-tenant synchronization
9. Multitenant Organization
10. Coexistencia de correo con Exchange Online
11. Mail routing durante una migración por fases
12. Corte y traslado del dominio
13. Calendarios y free/busy entre tenants
14. Microsoft Teams entre tenants
15. SharePoint y OneDrive
16. Seguridad y Conditional Access
17. Cómo encaja la coexistencia con la migración
18. Migration Orchestrator en 2026
19. Migración cross-tenant de Exchange Online
20. Migración cross-tenant de OneDrive
21. Migración cross-tenant de SharePoint
22. Qué estrategia elegir
23. Fases de un proyecto de coexistencia
24. Operación y monitorización
25. Errores frecuentes
26. Checklist
27. Preguntas frecuentes
28. Documentación oficial

Qué significa realmente coexistir entre tenants de Microsoft 365

Un tenant de Microsoft 365 es un límite administrativo independiente. Dispone de su propio directorio Microsoft Entra ID, usuarios, grupos, licencias, políticas de seguridad, Exchange Online, SharePoint, OneDrive, Teams, aplicaciones y configuración.

Por tanto, tener dos tenants no equivale a tener dos servidores dentro del mismo dominio.

Cada entorno mantiene su propia identidad y sus propios servicios.

La coexistencia consiste en configurar mecanismos de colaboración y routing entre ambos tenants durante el tiempo necesario para completar la transición.

Un ejemplo sencillo

Supongamos que una empresa adquiere otra organización con 500 usuarios.

No quieren migrar los 500 usuarios el mismo fin de semana. Deciden moverlos en cinco lotes de 100 usuarios.

Después del primer lote tendremos:

Sin coexistencia, los dos grupos podrían empezar a percibir problemas inmediatamente.

Por ejemplo:

• no encontrar a compañeros al convocar reuniones;
• no consultar correctamente su disponibilidad;
• tener problemas con correos dirigidos al dominio corporativo;
• no encontrar los mismos equipos de Teams;
• perder acceso a documentos compartidos;
• tener que cambiar constantemente entre organizaciones.

La coexistencia busca reducir precisamente estos problemas mientras se completa la migración.

Cuándo suele ser necesaria la coexistencia

No todas las migraciones necesitan el mismo nivel de coexistencia.

Una empresa de 20 usuarios que puede realizar el cambio completo durante un fin de semana probablemente necesite mucha menos infraestructura temporal que una organización internacional que vaya a migrar 5.000 usuarios durante cuatro meses.

Fusiones y adquisiciones

Es habitual que dos empresas necesiten colaborar mucho antes de que TI pueda consolidar todos sus sistemas.

En este caso la coexistencia puede empezar por identidad, Teams y acceso documental, mientras la migración de correo y datos se prepara en paralelo.

Escisiones y desinversiones

El reto es diferente.

No se trata solo de permitir colaboración, sino de ir reduciendo dependencias entre dos organizaciones que finalmente deben quedar separadas.

La configuración temporal debe diseñarse pensando desde el principio en cómo se eliminará.

Migraciones por oleadas

En proyectos grandes suele ser uno de los escenarios más razonables.

Los usuarios pueden agruparse por:

país, departamento, sociedad, ubicación, unidad de negocio o complejidad técnica.

La coexistencia permite que cada oleada migre sin esperar a que todo el proyecto esté terminado.

Qué no resuelve una arquitectura de coexistencia

Este punto es importante porque muchas expectativas incorrectas aparecen antes incluso de empezar el proyecto.

El límite más importante: un dominio personalizado no puede estar en dos tenants

Probablemente sea la restricción más importante de toda migración tenant-to-tenant.

Un dominio como:

empresa.com

solo puede verificarse en un tenant Microsoft Entra / Microsoft 365 al mismo tiempo.

Microsoft tampoco permite compartir entre tenants los namespaces:

UPN, SMTP y SIP.

Qué significa en la práctica

Mientras empresa.com pertenezca al tenant A, no podremos verificar ese mismo dominio en el tenant B.

Por tanto, antes del corte los usuarios de destino suelen prepararse utilizando:

usuario@tenantdestino.onmicrosoft.com

o algún dominio/subdominio temporal adecuado al diseño.

Cuando llegue el momento del cutover será necesario eliminar del tenant de origen las referencias que impiden liberar el dominio y, una vez retirado, añadirlo y verificarlo en el tenant de destino.

No basta con cambiar el MX

El dominio interviene en muchas más cosas que el correo.

Microsoft documenta además que, antes de eliminar un dominio, no debe seguir siendo utilizado por usuarios, administradores, buzones compartidos, recursos, contactos, grupos, listas de distribución o Teams.

Referencia oficial: Microsoft – Remove a domain from Microsoft 365.

Arquitectura general de coexistencia

En lugar de buscar una única herramienta que haga “coexistencia”, resulta más útil dividir el problema por servicios.

Identidad: Microsoft Entra B2B como base de colaboración

Antes de hablar de Teams o SharePoint necesitamos resolver identidad.

Cuando un usuario de una organización necesita acceder a recursos de otra, Microsoft Entra puede representarlo mediante B2B collaboration.

B2B collaboration

El usuario continúa autenticándose con sus credenciales de origen, pero existe un objeto que lo representa en el tenant que contiene los recursos.

Este modelo es apropiado para escenarios como:

• acceso a SharePoint;
• participación como invitado en Teams;
• acceso a aplicaciones empresariales;
• colaboración entre sociedades;
• proyectos compartidos.

El usuario no se “migra” por crear un invitado

Su identidad principal continúa perteneciendo al tenant de origen.

Esto es especialmente importante durante una adquisición.

Puede permitirse que los empleados accedan rápidamente a determinados recursos del comprador sin necesidad de migrar todavía:

buzón + OneDrive + dispositivos + aplicaciones + dominio.

Cross-tenant access settings: decidir en quién confiamos y para qué

Cross-tenant access settings permite controlar la relación entre nuestro tenant y otras organizaciones Microsoft Entra.

Podemos configurar políticas específicas para cada organización en lugar de tratar a todos los externos de la misma manera.

Acceso entrante y saliente

También podemos limitar aplicaciones

No es obligatorio abrir toda nuestra organización.

Podemos permitir, por ejemplo:

un grupo concreto de usuarios + una aplicación concreta.

Trust settings

Una de las capacidades más relevantes es poder confiar en determinadas claims emitidas por el tenant externo.

Entre ellas:

• MFA;
• device compliance;
• Microsoft Entra hybrid joined device.

Ejemplo práctico

Nuestro Conditional Access exige MFA a usuarios externos.

Si hemos configurado confianza en el MFA del tenant asociado y el usuario ya completó correctamente MFA allí, nuestro tenant puede aceptar esa señal.

Eso permite mantener el control sin obligar necesariamente al usuario a repetir el mismo proceso.

No confiar automáticamente en cualquier tenant

Antes de aceptar señales de otra organización deberíamos conocer:

su política MFA, sus métodos permitidos, la forma en que administra dispositivos y el nivel de control que aplica sobre las identidades.

Referencia oficial: Microsoft – Cross-tenant access overview.

Cross-tenant synchronization: automatizar usuarios y determinados grupos

Cuando necesitamos colaborar con diez usuarios, las invitaciones B2B manuales pueden ser perfectamente manejables.

Cuando necesitamos mantener cientos o miles de identidades externas durante meses, el problema cambia.

Cross-tenant synchronization automatiza el aprovisionamiento entre tenants de una organización.

Qué hace

Puede crear, actualizar y eliminar representaciones B2B en el tenant de destino a partir de objetos del tenant de origen.

Es un proceso unidireccional

Una configuración tiene:

source tenant → target tenant.

Si necesitamos sincronización en ambos sentidos debemos crear las correspondientes configuraciones para cada dirección.

Actualización importante: sincronización de grupos

La documentación actual de Microsoft permite también sincronizar determinados grupos.

Pero existen límites

No debemos interpretar esto como una sincronización general de todos los grupos de Microsoft 365.

Actualmente no crea en destino:

• Microsoft 365 Groups como tal;
• distribution groups;
• dynamic distribution groups;
• mail-enabled security groups;
• grupos role-assignable;
• grupos anidados.

Tampoco es una herramienta de migración

El usuario sincronizado continúa autenticándose contra su tenant de origen.

Cross-tenant synchronization tampoco migra:

mailbox, OneDrive, SharePoint, Teams ni dispositivos.

Referencia oficial: Microsoft – Cross-tenant synchronization.

Multitenant Organization: cuando varios tenants pertenecen realmente a la misma empresa

No todas las coexistencias terminan con un único tenant.

Algunas organizaciones deciden mantener varios tenants de forma permanente debido a:

estructura legal, autonomía regional, requisitos regulatorios, adquisiciones o modelos operativos.

Para estos casos Microsoft dispone de la funcionalidad Multitenant Organization.

Qué representa

Permite definir un perímetro de tenants que pertenecen a una misma organización.

No fusiona sus directorios.

Los tenants continúan siendo independientes, pero Microsoft puede ofrecer experiencias de colaboración más coherentes entre ellos.

Microsoft 365 people search

Uno de los problemas tradicionales de una arquitectura multi-tenant es que la búsqueda de personas suele estar limitada al tenant local.

En una Multitenant Organization, combinada con el aprovisionamiento B2B adecuado, Microsoft puede mejorar la capacidad de encontrar compañeros de otros tenants en experiencias de Microsoft 365.

Microsoft Teams

Microsoft también utiliza la representación Multitenant Organization para mejorar determinadas experiencias entre usuarios que pertenecen a distintos tenants del mismo grupo empresarial.

No utilizarla para un proveedor externo

Multitenant Organization está pensada para tenants que pertenecen a la misma organización.

Para colaboración entre empresas independientes debemos continuar utilizando los modelos B2B correspondientes.

Referencia oficial: Microsoft – Multitenant Organization.

Coexistencia de correo con Exchange Online

El correo suele ser la parte que más perciben los usuarios.

Durante una migración por fases debemos conseguir que un empleado migrado ayer pueda escribir sin problemas a otro que todavía estará tres semanas en el tenant de origen.

Qué necesitamos mantener

Mail routing durante una migración por fases

No existe un único diseño válido para todos los proyectos.

Dependerá de:

qué tenant mantiene el dominio principal, dónde apunta el MX, qué herramienta de migración se utiliza y qué objetos existen en cada organización.

Dominios de routing

Es habitual utilizar dominios técnicos como:

tenantA.onmicrosoft.com

y

tenantB.onmicrosoft.com

para encaminar mensajes sin necesitar que el dominio corporativo esté asociado simultáneamente a ambos tenants.

MailUser y targetAddress

En determinados diseños, el tenant que no contiene el buzón mantiene un objeto mail-enabled que conoce la ubicación real del destinatario.

El atributo de routing puede dirigir el mensaje hacia una dirección técnica del tenant donde reside el mailbox.

Internal Relay

Dependiendo de la arquitectura, un dominio aceptado puede configurarse como Internal Relay para que Exchange busque localmente al destinatario y, si no lo encuentra, continúe el routing hacia el sistema correspondiente.

Esto debe probarse cuidadosamente.

Una configuración incorrecta puede provocar:

loops, NDR, entrega al buzón equivocado o mensajes que permanecen dentro del tenant incorrecto.

No copiar un diseño de routing sin entenderlo

Un esquema correcto para una organización puede ser innecesario o incluso peligroso para otra.

Antes de crear conectores o dominios Internal Relay conviene documentar el flujo:

Internet → gateway → Exchange Online → destinatario → posible segundo tenant.

El corte del dominio: el momento más sensible

En algún momento, si la organización quiere conservar el dominio corporativo en el tenant destino, tendrá que liberarlo del tenant origen.

Antes del corte

Debemos eliminar o cambiar todas las referencias relevantes al dominio.

Después

El flujo habitual será:

eliminar del origen → añadir/verificar en destino → configurar usuarios/direcciones → actualizar DNS.

DNS

Conviene preparar con antelación:

• MX;
• Autodiscover cuando corresponda;
• SPF;
• DKIM;
• DMARC;
• registros necesarios para servicios dependientes.

Reducir TTL ayuda, pero no libera antes el dominio

Bajar TTL antes del cutover puede acelerar la propagación de los nuevos valores DNS.

No elimina las dependencias internas de Microsoft 365 ni permite que un dominio siga verificado simultáneamente en dos tenants.

Calendarios y free/busy entre tenants

El segundo problema que los usuarios detectan rápidamente durante una migración es el calendario.

Cuando intentan convocar a un compañero del otro tenant quieren seguir viendo si está:

Free, Busy, Tentative u Out of Office.

Organization relationships

Exchange Online permite crear Organization Relationships entre organizaciones para compartir información de calendario.

Niveles de información

Podemos compartir únicamente disponibilidad o incluir determinados detalles adicionales según el nivel configurado.

Ejemplo orientativo

Connect-ExchangeOnline -UserPrincipalName admin@tenant-a.com

New-OrganizationRelationship `
    -Name "Tenant B - FreeBusy" `
    -DomainNames "tenantb.com" `
    -FreeBusyAccessEnabled $true `
    -FreeBusyAccessLevel LimitedDetails

En el otro tenant configuramos la relación correspondiente si necesitamos intercambio en ambas direcciones.

Qué consigue

Puede hacer mucho más cómoda una migración por fases porque usuarios de los dos tenants pueden consultar disponibilidad.

Qué no consigue

No migra:

• calendarios;
• delegaciones;
• salas;
• resource mailboxes;
• permisos de calendario;
• reservas históricas.

Salas y recursos necesitan un plan específico

Si una oficina continúa usando salas alojadas en el tenant de origen mientras parte de sus usuarios ya se encuentra en destino, hay que definir quién sigue siendo autoridad de reserva y cómo será la experiencia durante ese periodo.

Referencia oficial: Microsoft – Create an organization relationship in Exchange Online.

Microsoft Teams: hay tres modelos distintos de colaboración

Decir simplemente “permitiremos Teams entre tenants” no es suficientemente preciso.

External access

Es apropiado cuando necesitamos principalmente:

buscar a una persona externa, chatear, llamar o invitarla a reuniones.

No proporciona acceso general a los equipos o documentos de la otra organización.

Guest access

El usuario entra en un Team alojado en el tenant anfitrión como invitado.

Es una buena opción cuando necesita formar parte de un espacio completo de colaboración.

Shared channels

Los shared channels permiten compartir únicamente un canal con personas que no pertenecen al Team completo.

Para participantes externos se apoyan en Microsoft Entra B2B direct connect.

B2B direct connect

A diferencia del guest access tradicional, el usuario puede acceder al shared channel utilizando su identidad de origen sin tener que trabajar como un guest convencional dentro del tenant anfitrión.

Debe habilitarse en ambas organizaciones

B2B direct connect está bloqueado por defecto en cross-tenant access settings.

Para colaborar, ambas organizaciones deben permitir la relación correspondiente.

Actualmente su principal escenario es Teams shared channels

No deberíamos tratar B2B direct connect como una sustitución general de B2B collaboration para cualquier aplicación.

Referencia oficial: Microsoft – B2B direct connect overview.

Un shared channel tampoco es una migración de Teams

Puede ayudarnos a trabajar durante la transición, pero el contenido continúa perteneciendo al tenant donde se aloja el canal.

Cuando termine la coexistencia deberemos decidir:

si permanece allí, se migra, se recrea o se archiva.

SharePoint y OneDrive durante la coexistencia

Los documentos suelen ser más difíciles de gestionar que el correo porque los permisos se acumulan con el tiempo.

Durante la coexistencia conviene evitar que la solución rápida sea:

“compartimos todo con todo el mundo y ya lo arreglaremos después”.

El acceso temporal también debe gobernarse

OneDrive no debería convertirse en un repositorio departamental temporal

Durante una migración es tentador compartir carpetas desde el OneDrive de un usuario para que todo el mundo pueda seguir trabajando.

Si la información pertenece realmente a un equipo o departamento, puede ser mejor aprovechar el proyecto para decidir si su destino correcto será:

SharePoint o Teams.

Permisos temporales con fecha de caducidad

Una buena práctica es registrar:

qué acceso se abrió, para quién, por qué y cuándo se revisará.

La coexistencia no debe rebajar la seguridad

Una migración genera presión.

Los usuarios necesitan acceso y TI necesita resolver incidencias rápidamente.

Es precisamente cuando resulta más fácil introducir excepciones que después permanecen durante años.

Controles que deberíamos mantener

No confiar en MFA externa sin evaluar el tenant

Cross-tenant access settings permite confiar en la MFA realizada por otra organización.

Esto mejora mucho la experiencia de usuario, pero también significa que estamos aceptando una decisión de seguridad tomada por el tenant externo.

En una fusión puede ser perfectamente razonable, pero debería existir una evaluación previa.

Access Reviews

Una coexistencia que inicialmente iba a durar cuatro semanas puede acabar durando seis meses.

Durante ese tiempo:

personas cambian de puesto, abandonan la empresa, finalizan proyectos y dejan de necesitar acceso.

Las revisiones periódicas ayudan a evitar que los objetos B2B se conviertan en permisos permanentes por descuido.

Coexistencia y migración son dos proyectos conectados, pero distintos

Una buena coexistencia facilita la migración.

Pero no debemos confundir:

permitir acceso

con

mover el contenido.

Migration Orchestrator en 2026

Microsoft está desarrollando Migration Orchestrator para coordinar migraciones tenant-to-tenant de varias cargas de trabajo.

A fecha de actualización de esta guía, la propia documentación de Microsoft sigue describiendo esta solución como preview.

Cargas que puede coordinar actualmente

Microsoft documenta cuatro workloads principales:

No significa que migre todo Teams

Microsoft indica que la solución no mueve como parte del mismo alcance:

Teams compartidos y canales ni los sitios de SharePoint compartidos asociados.

Dependencias

Las reuniones de Teams tienen dependencia con Exchange.

Cuando migramos varias cargas para un mismo usuario, Microsoft recomienda tratarlas de forma coordinada para respetar esas dependencias.

Migration Orchestrator mueve contenido, no identidades

Los usuarios del tenant de destino deben prepararse correctamente antes del movimiento.

La creación y configuración de identidades sigue siendo responsabilidad del proyecto.

Referencia oficial: Microsoft – Migration Orchestrator overview.

Migración cross-tenant de Exchange Online

Microsoft dispone de una capacidad nativa para mover buzones Exchange Online entre tenants utilizando tecnologías conocidas como:

Exchange Online PowerShell + Mailbox Replication Service.

El usuario debe prepararse en el tenant destino

Antes del movimiento existe normalmente como MailUser con los atributos necesarios para relacionarlo con el buzón de origen.

Después del movimiento

El buzón pasa al tenant destino y el objeto del origen se convierte en MailUser con una dirección de routing hacia el nuevo tenant.

Este comportamiento puede ayudar a mantener el flujo de correo durante la coexistencia.

Licencia específica

La migración nativa cross-tenant requiere actualmente una licencia:

Cross Tenant User Data Migration

por usuario y por migración.

Esta licencia también cubre la migración nativa de OneDrive correspondiente.

Mailboxes con hold

Microsoft indica que los buzones que estén bajo cualquier tipo de hold no pueden migrarse mediante esta función hasta resolver el escenario correspondiente.

Qué contenido mueve

La funcionalidad está orientada a contenido visible del mailbox como:

correo, calendarios, contactos, tareas y notas.

Referencia oficial: Microsoft – Cross-tenant mailbox migration.

Migración cross-tenant de OneDrive

Microsoft dispone también de una migración nativa de OneDrive entre tenants.

Una diferencia importante

Esta operación es un move y no una herramienta tradicional de premigración con múltiples deltas.

Microsoft especifica que:

no se pueden ejecutar pasadas incrementales o delta.

Redirect

Cuando el movimiento termina, Microsoft deja un redirect en la ubicación original para que determinados enlaces antiguos puedan llevar al nuevo OneDrive.

Implicación para el proyecto

No debemos diseñar la migración nativa de OneDrive con el patrón:

premigramos hoy → delta mañana → delta final.

Ese modelo puede existir en herramientas de terceros, pero no es el comportamiento de la migración cross-tenant nativa documentada por Microsoft.

Referencia oficial: Microsoft – Cross-tenant OneDrive migration.

Migración cross-tenant de SharePoint

Otra actualización importante es la capacidad nativa de Cross-tenant SharePoint migration.

Permite mover sitios SharePoint entre tenants utilizando SharePoint Online PowerShell.

Sitios compatibles

Microsoft documenta soporte para:

• sitios modernos;
• communication sites;
• sitios clásicos;
• sitios conectados a Microsoft 365 Groups;
• sitios asociados a Teams.

Pero atención con Teams

Que podamos mover el sitio SharePoint de un Team no significa que estemos migrando el Team completo.

Microsoft deja claro que esta función mueve el contenido SharePoint, no:

la estructura de Teams, sus canales ni todo el contenido específico de Teams.

Identity mapping

Antes de migrar es necesario crear un mapa entre los usuarios y grupos del tenant origen y sus equivalentes en el tenant destino.

Esto permite reconstruir permisos y ownership correctamente.

No debe existir el sitio destino previamente

La funcionalidad no está diseñada para fusionar contenido con un sitio ya existente.

Si el sitio de destino ya existe, el movimiento puede fallar.

Límites actuales relevantes

Redirects

Después del movimiento, los enlaces compartidos compatibles pueden redirigirse hacia la nueva ubicación.

Power Apps, Power Automate y extensiones

No debemos asumir que una migración de contenido SharePoint recrea automáticamente:

Power Apps, Power Automate, aplicaciones personalizadas, web parts externas o workflows heredados.

Estas dependencias deben inventariarse y tratarse aparte.

Referencia oficial: Microsoft – Cross-tenant SharePoint migration.

Qué estrategia de coexistencia elegir

No todas las organizaciones necesitan implementar todas las funcionalidades que hemos visto.

Cuanto más corta sea una coexistencia, mejor

No porque una arquitectura multi-tenant sea necesariamente mala, sino porque mantener simultáneamente:

routing + invitados + sincronización + aliases + dominios temporales + permisos cruzados + licencias duplicadas

aumenta progresivamente la complejidad.

Si el objetivo final es un único tenant, debemos avanzar hacia él.

Cómo plantear un proyecto de coexistencia paso a paso

Fase 1: discovery

Antes de configurar nada debemos entender ambos tenants.

Fase 2: definir el estado final

Una coexistencia no puede diseñarse si no sabemos dónde queremos terminar.

Para cada workload debemos decidir:

se migra, permanece, se recrea o se retira.

Fase 3: definir el periodo de coexistencia

Después determinamos:

• duración prevista;
• usuarios afectados;
• qué servicios necesitan convivencia;
• qué experiencia se ofrecerá;
• qué limitaciones se comunicarán.

Fase 4: preparar identidad

Configuramos:

B2B, Cross-tenant access, synchronization o Multitenant Organization

solo si son necesarios.

Fase 5: preparar Exchange

Diseñamos:

routing, dominios técnicos, conectores, free/busy y cutover.

Fase 6: preparar colaboración

Validamos:

Teams, SharePoint, OneDrive y aplicaciones.

Fase 7: piloto

Un piloto debería incluir usuarios reales de perfiles diferentes.

No basta con comprobar que el job de migración termina correctamente.

Pruebas del piloto

Fase 8: oleadas

Una vez validado el piloto, migramos por lotes.

Cada lote debería disponer de:

pre-check → migración → validación → soporte → cierre.

Fase 9: retirar la coexistencia

Este paso debe formar parte del plan desde el principio.

Revisamos y eliminamos:

• routing temporal;
• dominios técnicos innecesarios;
• MailUsers antiguos cuando ya no procedan;
• guest accounts temporales;
• Cross-tenant synchronization innecesaria;
• shared channels temporales;
• organization relationships;
• connectors;
• excepciones Conditional Access;
• licencias duplicadas.

Operación durante la coexistencia

Cuando la migración dura varias semanas, la coexistencia deja de ser únicamente un diseño y pasa a convertirse en un servicio que debe operarse.

Qué monitorizar

Un único canal de incidencias

Los usuarios no deberían necesitar saber:

“este problema pertenece al equipo del tenant origen y aquel al tenant destino”.

El soporte debería disponer de un único proceso capaz de escalar internamente al equipo adecuado.

Documentar excepciones

Si durante una oleada tenemos que abrir una excepción temporal, registramos:

Errores frecuentes en una coexistencia tenant-to-tenant

Checklist técnico de coexistencia entre tenants

Preguntas frecuentes sobre coexistencia entre tenants de Microsoft 365

Conclusión: una buena coexistencia hace que la migración parezca mucho más sencilla de lo que realmente es

La coexistencia entre tenants de Microsoft 365 no consiste en activar una opción que una dos organizaciones.

Es el resultado de coordinar varias capas distintas.

La identidad puede resolverse mediante B2B, Cross-tenant access settings y, cuando corresponde, Cross-tenant synchronization. Si varios tenants pertenecen de manera permanente a la misma organización, Multitenant Organization añade capacidades específicas para mejorar la colaboración.

El correo necesita su propio diseño de routing.

Mientras parte de los usuarios permanezcan en origen y otra parte ya esté en destino, Exchange debe saber dónde se encuentra el buzón real de cada persona.

El calendario es otro componente independiente. Las Organization Relationships pueden ofrecer free/busy y determinados detalles, pero no migran calendarios ni resuelven por sí solas salas y delegaciones.

Teams también dispone de diferentes modelos.

External access, Guest access y Shared Channels resuelven problemas distintos. B2B direct connect puede ofrecer una experiencia especialmente cómoda para shared channels, pero no debe confundirse con una migración.

Lo mismo ocurre con SharePoint y OneDrive.

El acceso externo puede mantener a los usuarios trabajando mientras se prepara el movimiento de datos, pero los permisos temporales deben gobernarse igual que cualquier otro acceso empresarial.

Y por encima de todas estas piezas existe una restricción que condiciona el proyecto completo:

un mismo dominio personalizado no puede estar verificado simultáneamente en los dos tenants.

Por eso el traslado de dominio continúa siendo uno de los momentos más sensibles de cualquier migración tenant-to-tenant.

Las herramientas de migración nativas de Microsoft han evolucionado mucho. En 2026 disponemos de cross-tenant mailbox migration, OneDrive migration, SharePoint migration y Migration Orchestrator para coordinar determinadas cargas.

Pero tampoco existe todavía una única función que transforme automáticamente un tenant completo en otro idéntico.

Teams, SharePoint, aplicaciones, Power Platform, permisos, dominios, dispositivos y seguridad siguen requiriendo análisis específico.

Por eso una buena estrategia debería responder antes de empezar a cinco preguntas:

qué usuarios van a convivir, durante cuánto tiempo, qué necesitan compartir, qué workload se migrará en cada fase y cómo eliminaremos toda la configuración temporal cuando el proyecto termine.

Si esas respuestas están claras, la coexistencia deja de ser una colección de parches y se convierte en lo que debería ser:

una arquitectura temporal diseñada para que la empresa pueda seguir trabajando mientras Microsoft 365 cambia por debajo.

Documentación oficial recomendada

Colaboración entre tenants

• Microsoft – Microsoft 365 inter-tenant collaboration
• Microsoft – Cross-tenant access overview
• Microsoft – Cross-tenant access settings for B2B collaboration

Cross-tenant synchronization y Multitenant Organization

• Microsoft – Cross-tenant synchronization
• Microsoft – Multitenant Organization
• Microsoft – Multitenant Organization identity provisioning for Microsoft 365

Teams y B2B direct connect

• Microsoft – B2B direct connect
• Microsoft – Configure B2B direct connect
• Microsoft – Shared channels in Microsoft Teams

Exchange Online y calendarios

• Microsoft – Create an Organization Relationship
• Microsoft PowerShell – New-OrganizationRelationship

Dominios

• Microsoft – Add and verify custom domains
• Microsoft – Remove a domain
• Microsoft – Add a custom domain to Microsoft 365

Migración tenant-to-tenant

• Microsoft – Plan a Microsoft 365 tenant-to-tenant migration
• Microsoft – Migration Orchestrator
• Microsoft – Cross-tenant mailbox migration
• Microsoft – Cross-tenant OneDrive migration
• Microsoft – Cross-tenant SharePoint migration
• Microsoft – FastTrack cross-tenant migration