IDENTIDAD Y MIGRACIONES · DECISIONES DE ARQUITECTURA

Cross-tenant synchronization vs migración tenant-to-tenant: diferencias y casos de uso

Una empresa compra otra y necesita que sus equipos colaboren cuanto antes. Alguien propone sincronizar usuarios entre tenants y dar por terminada la integración. El acceso puede mejorar, pero los buzones, documentos y servicios siguen donde estaban. Elegir entre colaboración y migración exige responder dónde se autentican las personas, dónde viven los datos y qué organización debe administrar el resultado.

1. Colaboración, identidad y datos son decisiones diferentes

Piensa en tres preguntas separadas. ¿Quién controla la autenticación del empleado? ¿Qué objeto representa a esa persona en el tenant que contiene el recurso? ¿Dónde permanece el contenido de trabajo? Una solución puede mejorar la segunda pregunta sin cambiar las otras dos. Por eso, ver a una persona en el directorio del comprador no demuestra que su identidad y sus datos se hayan trasladado a esa organización.

Cross-tenant synchronization utiliza aprovisionamiento de Entra para crear y mantener usuarios B2B y los grupos compatibles entre tenants. El origen define población y atributos; el destino permite la relación. El empleado sigue autenticándose mediante su organización de origen. El acceso posterior depende de las autorizaciones de cada aplicación y recurso. Un objeto correctamente aprovisionado puede no tener derecho a abrir ningún documento de un sitio determinado.

Una migración tenant-to-tenant tiene otra finalidad: colocar contenido compatible en el entorno de destino y preparar allí su operación. Requiere identidades de destino, métodos por workload, licencias, controles y validación. No es una única función de Entra ni una copia íntegra del directorio. Los usuarios, los buzones, los documentos, las configuraciones y los dispositivos necesitan decisiones relacionadas, pero no idénticas.

También conviene distinguir capacidades vecinas. B2B collaboration permite acceso de identidades externas; B2B direct connect se utiliza para escenarios como canales compartidos; multitenant organization mejora experiencias dentro de una organización con varios tenants. Ninguna de estas denominaciones debe usarse como sinónimo universal de migración. La arquitectura puede combinarlas, pero debe expresar qué función desempeña cada una y qué dependencia conserva.

2. Comparativa para decidir el resultado esperado

La pregunta de compra no debería ser «¿cuál es más barata?», sino «¿qué resultado necesitamos?». Si hay que conservar varios tenants bajo una misma organización, una migración completa puede añadir trabajo sin aportar el modelo operativo buscado. Si hay que retirar el tenant del vendedor, una sincronización económica no resuelve la dependencia. Primero define el destino de negocio y después compara costes de opciones que realmente lo satisfacen.

Una solución de colaboración tampoco es necesariamente temporal. Puede ser el diseño permanente de un grupo con entornos diferenciados. En ese caso necesita operación, propietarios, revisiones de confianza y presupuesto recurrente. Si es una fase de transición, debe incorporar fecha o condición de salida. La misma configuración puede ser correcta en un modelo permanente y convertirse en deuda técnica cuando nadie recuerda por qué continúa activa.

3. Escenarios donde conviene colaborar, migrar o combinar

En un grupo que mantiene tenants por estructura empresarial, puede interesar que una persona acceda a aplicaciones centrales con su cuenta habitual. El piloto debe verificar experiencia, permisos y bajas, no medir gigabytes transferidos, porque no se están moviendo. Si un responsable pide también centralizar correo y documentos, añade esa necesidad como proyecto de datos y operación; no la incluyas implícitamente en el alcance de sincronización.

En una adquisición, la colaboración puede reducir fricción durante el discovery. Sin embargo, no debe sustituir las decisiones de consolidación. Define qué identidades acabarán siendo internas del destino, qué datos se trasladan y qué aplicaciones cambian de autoridad. Comprueba si la cuenta B2B creada para la coexistencia es compatible con el método posterior. No reutilices objetos únicamente porque ya aparecen en el directorio.

En un carve-out, la relación entre organizaciones puede cambiar después de la venta. Evalúa privacidad, minimización, autorización y responsabilidades antes de habilitar sincronización. Para colaboración externa, valora alternativas de invitación y gobierno adecuadas al escenario. La necesidad de acceso rápido no autoriza a sincronizar indiscriminadamente toda la plantilla ni a mantener confianza amplia después de completar la separación.

Para un proyecto con un proveedor, la decisión suele ser distinta de la de una organización multitenant propia. Un grupo reducido puede necesitar acceso a un recurso durante un periodo concreto, con patrocinador y revisión. La arquitectura debe justificar por qué hace falta aprovisionamiento automático y qué valor aporta frente a una gestión de acceso menos amplia. No selecciones una función solo porque existe en el portal.

4. Licencias: separar aprovisionamiento, acceso y migración

La documentación actual distingue sincronización de usuarios en la misma nube, sincronización de grupos y sincronización entre nubes. Para usuarios en la misma nube exige Entra ID P1 en origen por usuario sincronizado; grupos y escenarios cross-cloud tienen requisitos de Entra ID Governance o Entra Suite. Verifica el producto exacto, el escenario y los derechos contratados antes de aplicar una regla de precio por usuario.

La ausencia de una licencia de sincronización exigida en destino no significa que todas sus capacidades sean gratuitas. El acceso y las funciones utilizadas pueden tener requisitos propios, y la facturación External ID puede resultar pertinente según configuración. Separa ese presupuesto del coste de Microsoft 365, de las políticas avanzadas y de cualquier capacidad de gobierno. Evita sumar o eliminar licencias únicamente a partir del nombre del usuario en el directorio.

La migración nativa utiliza sus propias licencias y requisitos; una licencia para sincronización no cubre automáticamente movimiento de contenido. Las herramientas especializadas también tienen modelos distintos por workload, población o volumen. Solicita una propuesta que especifique alcance, periodo de uso, pasadas disponibles y soporte. No compares dos partidas aparentemente similares sin revisar qué operaciones y excepciones incluyen realmente.

Para evaluar coste total, añade administración recurrente, monitorización, revisión de acceso y soporte de identidades en varios tenants. Una coexistencia larga puede mantener licencias y dependencias paralelas. No inventes un porcentaje de ahorro por consolidar: utiliza asignaciones y facturas reales, estima esfuerzo y valida cuándo pueden retirarse servicios. El ahorro solo existe si el resultado permite cerrar costes de origen sin perder requisitos necesarios.

5. Acceso, confianza y grupos: aprovisionar no es autorizar todo

El objeto B2B necesita un modelo de autorización. Define aplicaciones y recursos permitidos, propietarios y criterios de asignación. Si se crean grupos compatibles, no presupongas que se copian todos los tipos de grupo ni su funcionalidad. La sincronización de grupos tiene restricciones y no equivale a recrear automáticamente Microsoft 365 Groups, listas de distribución, equipos y configuraciones asociadas.

La configuración de acceso entre tenants diferencia entrada y salida, y puede incluir confianza en claims de MFA o dispositivo. Diseña esa confianza por organización y propósito. Confiar en una señal no significa eliminar toda la política del tenant de recursos. Revisa la calidad del control de origen y prueba casos de acceso previsto y denegación. Una experiencia cómoda no basta como evidencia de seguridad correcta.

Limita los atributos a los necesarios. Un mapeo puede exponer información organizativa que no aporta valor al acceso. Comprueba la fuente, el uso y quién verá cada dato. Si se modifica un atributo en destino que sigue gestionado por origen, una actualización posterior puede alterarlo de nuevo. Documenta la autoridad de las propiedades y evita una administración manual que compita con el proceso de aprovisionamiento.

La redención automática simplifica determinadas experiencias de incorporación, pero no concede aprobación indiscriminada de aplicaciones. Revisa consentimiento, políticas de colaboración y autorizaciones de recursos de forma separada. Tampoco garantiza que toda experiencia de Teams o SharePoint sea igual a la de un usuario interno. Prueba los servicios utilizados y comunica las limitaciones relevantes para las personas que trabajan entre organizaciones.

6. Diseñar un piloto que compruebe el modelo completo

Empieza por una población pequeña y representativa, con alcance explícito. Incluye una persona que necesite una aplicación, otra que use documentos compartidos y un caso de baja controlado. Registra tenant de origen y destino, identificadores de usuario y objeto resultante. Antes de iniciar, confirma licencias, configuración bilateral requerida, permisos administrativos y responsables de ambas partes.

Utiliza asignación y filtros con cautela. Un atributo de departamento puede no representar de forma fiable el perímetro de una adquisición o proyecto. Revisa valores vacíos, inconsistencias y cambios de personal. Una modificación del filtro puede modificar quién permanece gestionado. Trata esos cambios como configuración de acceso, con revisión de impacto y pruebas, no como una edición inocua del inventario.

La provisión bajo demanda ayuda a verificar casos concretos, pero el resultado de una persona no certifica toda la población. Cuando amplíes el alcance, reconcilia resultados y excepciones con el registro aprobado. Registra cuándo se observó cada cambio y qué ciclo lo procesó. No prometas actualización instantánea de todos los objetos ni cierres una incidencia porque una ejecución individual haya funcionado.

Prueba también denegaciones. Un empleado fuera de alcance, una aplicación excluida y un dispositivo que incumple una condición deben comportarse conforme al diseño. Documenta el recurso y la identidad utilizados en cada prueba. El administrador no debería emplear su cuenta privilegiada como sustituto de todos los roles. Las pruebas positivas demuestran utilidad; las negativas ayudan a comprobar el perímetro.

7. Pasar de coexistencia a migración sin confundir objetos

Antes de mover contenido, establece un mapa entre identidad de origen, representación B2B y futura identidad operativa. Pueden ser objetos distintos. Revisa qué autorizaciones y aplicaciones dependen del objeto externo existente y cómo se trasladará o recreará esa relación. Evita eliminarlo de manera anticipada para «limpiar» el directorio. Su identificador puede aparecer en permisos que siguen siendo necesarios durante la transición.

Microsoft documenta conversiones de usuarios externos a internos para escenarios admitidos, pero no deben tratarse como una acción genérica que resuelve toda migración. La conversión de identidad, el aprovisionamiento que la gestionaba y los requisitos del workload seleccionado deben evaluarse conjuntamente. Confirma compatibilidad con la ruta, autoridad de atributos y estado del objeto. Un cambio de userType por sí solo no es esa conversión.

El plan de destino debe prevenir creación prematura de buzones y OneDrive cuando la ruta exige objetos sin aprovisionar. También debe decidir cómo se asignarán grupos, aplicaciones y licencias en el orden correcto. Reutilizar una identidad ya utilizada durante coexistencia puede tener ventajas, pero únicamente si el método admite su estado. No fuerces esa reutilización sin comprobar prerrequisitos y consecuencias.

Para datos, prepara una matriz separada de contenido, método y aceptación. La existencia de una relación entre tenants no habilita automáticamente todos los movimientos. Distingue orquestación nativa, rutas individuales y herramientas especializadas, con sus restricciones. Si el objetivo es retirar el origen, incluye dominio, aplicaciones, dispositivos y referencias que seguirían dependiendo de él después del último lote de archivos.

Define el momento en que el empleado cambia de identidad de trabajo y dónde deberá realizar cambios nuevos. Mantener edición en ubicaciones paralelas puede crear divergencia. Comunica el acceso histórico permitido, los canales de soporte y las limitaciones conocidas. La transición debe coordinarse con responsables del negocio, especialmente cuando un proceso incluye participantes que aún no han migrado.

8. Bajas, supervisión y retirada de la relación

Diseña el ciclo de baja antes de poner la relación en producción. Cambios de alcance y acciones en origen pueden afectar a objetos gestionados en destino. El resultado debe verificarse, incluyendo excepciones y errores. No confundas detener el trabajo de sincronización con eliminar todas las representaciones B2B: cortar una relación puede dejar objetos existentes que requieren una retirada controlada.

La protección contra eliminaciones accidentales permite establecer un umbral y revisar operaciones que lo superan. Elige un valor apropiado para la población y configura notificaciones a un responsable operativo. Un umbral por defecto no es necesariamente adecuado para un piloto pequeño o una reorganización extensa. Cuando el trabajo entra en cuarentena, investiga la causa y autoriza solo cambios esperados; no apruebes eliminaciones masivas para obtener un estado saludable.

Supervisa registros de aprovisionamiento y auditoría con los permisos adecuados. Distingue éxito, omisión, error y objeto fuera de alcance, y compara con la población esperada. Un trabajo activo puede seguir acumulando fallos individuales. Las alertas necesitan un circuito de atención: quién investiga, qué información recibe y cuándo escala. Registrar errores sin responsable no ofrece un servicio de ciclo de vida confiable.

Para retirar una relación temporal, prepara inventario de objetos y dependencias, aprobación de salida y una secuencia compatible. Valida sustitutos y accesos permanentes antes de quitar la colaboración. Revisa grupos, aplicaciones y documentos que todavía utilizan identidades externas. Si se necesitan operaciones de desaprovisionamiento, conserva las condiciones que permiten procesarlas hasta completar la secuencia prevista y comprobar su resultado.

Un ejemplo de decisión sin resultados inventados

Imagina un grupo con dos tenants que decide mantenerlos por autonomía administrativa. Sus empleados necesitan acceder a una aplicación central y a ciertos espacios de colaboración. Una relación de aprovisionamiento controlada puede ser adecuada si su ciclo de vida y permisos están diseñados. No hay motivo para afirmar que se han migrado buzones o que se puede eliminar el segundo tenant.

Ahora cambia la condición: el grupo necesita consolidar operaciones y retirar uno de los tenants. La colaboración puede servir durante preparación, pero el criterio de salida exige identidades, contenido y servicios de destino. El presupuesto debe contemplar migración y remediación. La configuración inicial puede parecer idéntica en ambos ejemplos; la diferencia está en el objetivo final y en las obligaciones de operación y retirada.

Una decisión documentada para dirección y soporte

Resume el resultado en una ficha: objetivo, autoridad de autenticación, ubicación de datos, población, recursos, licencias, dependencias y criterios de aceptación. Añade qué se mantiene en origen y quién lo administra. Esta ficha permite que dirección entienda qué inversión está autorizando y que soporte no trate toda incidencia como un fallo de migración. Revisa la decisión cuando cambie la estrategia empresarial o el perímetro de confianza.

Incluye la duración o condición de permanencia del modelo. Si no hay una fecha de salida porque varios tenants seguirán operando, asigna revisiones periódicas de acceso y coste. Si es coexistencia transitoria, mide avance hacia las dependencias que deben cerrarse. Evita un indicador único basado en objetos sincronizados: una cantidad creciente puede significar adopción del modelo permanente o ampliación accidental de una transición que debía reducirse.

Evaluar grupos sin confundir pertenencia y funcionalidad

Si el diseño utiliza grupos, registra el tipo de origen, el resultado admitido y las aplicaciones que consumirán la pertenencia. Un grupo que agrupa personas para colaborar no transporta automáticamente correo, archivos o calendario. Tampoco una etiqueta comercial de «sincronizar grupos» garantiza grupos anidados, roles asignables o todos los escenarios entre nubes. Comprueba las restricciones vigentes y prueba el patrón real antes de convertirlo en estándar corporativo.

En la documentación actual existen referencias de ayuda que todavía describen capacidades anteriores. Para decidir, contrasta la página específica de la función con su configuración y requisitos actuales, y registra la fecha de revisión. Si una guía general afirma que no se sincronizan grupos, pero la documentación detallada describe una capacidad limitada, evita ambos extremos: ni negar toda la función ni prometer una réplica íntegra del directorio. Explica exactamente qué patrón se ha comprobado.

Valida cambios de pertenencia con usuarios dentro y fuera del alcance aprobado. El acceso a una aplicación puede depender de su propia interpretación de grupos, cachés o asignaciones adicionales. Una membresía visible en Entra no certifica el resultado funcional inmediato. Comprueba también cómo se retira el derecho cuando cambia la pertenencia y quién atiende una discrepancia. Esa prueba debe formar parte del servicio de identidad y de la aplicación consumidora.

Pruebas del ciclo de vida antes de ampliar el alcance

Diseña una secuencia controlada con cuentas de ensayo autorizadas. Primero comprueba alta y atributos; después, un cambio aprobado; finalmente, una salida de alcance conforme a la política. Registra objetos resultantes y evidencias en ambos tenants. No utilices una baja real de un empleado como primer experimento para descubrir el comportamiento. Las cuentas de ensayo también deben tener un propietario, datos no sensibles y una retirada planificada.

Distingue varias acciones: bloquear acceso, quitar una asignación, cambiar un atributo de filtro y eliminar un objeto de origen. No son equivalentes ni deberían mezclarse en una única prueba. Algunas combinaciones de estado requieren atención específica, y el registro debe mostrar lo observado. Si el resultado difiere del previsto, conserva la evidencia y revisa la documentación antes de habilitar el mismo patrón para usuarios reales.

Para incidentes de seguridad, define un procedimiento de contención independiente del ciclo normal de aprovisionamiento. Si se necesita retirar acceso con urgencia, los responsables deben conocer controles y consecuencias en origen y destino. No confíes únicamente en esperar la siguiente actualización sin comprobar el riesgo. Después de la contención, revisa la configuración que gestiona los atributos para evitar que una modificación posterior restablezca un estado no deseado.

Cómo comparar ofertas técnicas de forma útil

Pide a cada propuesta que describa entregables verificables: población, recursos, mapeos, licencias, pruebas positivas y negativas, operación y salida. Una oferta de sincronización y una oferta de migración pueden cubrir problemas distintos aunque ambas mencionen dos tenants. Solicita que se identifique qué permanece en origen y qué requiere trabajo adicional. Así, compras puede comparar alcances equivalentes sin elegir una partida menor que deja sin resolver el objetivo.

Incluye responsabilidades de cliente y proveedor. La decisión sobre datos, la revisión de aplicaciones y la aceptación empresarial pueden requerir disponibilidad interna. Si una propuesta presupone que todo eso está resuelto, debe quedar visible. Define también cómo se trata un bloqueo de seguridad, una identidad incompatible o una aplicación no soportada. Esas condiciones permiten estimar trabajo y negociar prioridades antes de que se conviertan en cambios urgentes.

La aceptación debe corresponder a la arquitectura seleccionada. Para colaboración, exige ciclo de vida y acceso controlado; para migración, añade ubicación de contenido y operación de destino; para coexistencia, incluye dependencias temporales y su salida. Un informe de objetos creados no sustituye esos criterios. Mantén evidencias que el equipo receptor pueda interpretar y un registro de excepciones con responsable y decisión vigente.

Preguntas frecuentes

Fuentes y lectura relacionada

• Microsoft: capacidades y licencias de sincronización
• Configuración y supervisión
• Acceso entre tenants
• Protección frente a eliminaciones accidentales
• Registros de aprovisionamiento
• Alcance de la migración orquestada
• Contexto de M&A y coexistencia