Dos empresas, dos tenants Microsoft 365: ¿fusionarlos o mantenerlos separados?

La decisión estratégica

Una fusión empresarial no necesita empezar por una migración

Una operación corporativa suele empezar con una pregunta sencilla: ¿cuándo podremos trabajar como una sola empresa? El consejo de administración espera sinergias, Finanzas quiere consolidar costes y la dirección comercial necesita que equipos antes separados compartan clientes, conocimiento y oportunidades. En esa conversación, Microsoft 365 aparece enseguida: hay dos directorios, dos entornos de correo, dos configuraciones de Teams, dos bibliotecas documentales, dos formas de dar de alta empleados y, con frecuencia, políticas de seguridad diferentes.

La reacción más habitual es pedir una migración rápida hacia el tenant de la compañía compradora. Parece lógica: una sola empresa, un solo tenant. Pero un tenant no es una carpeta que se pueda arrastrar de un lado a otro. Es un límite administrativo y de identidad que sostiene usuarios, dominios, acceso a aplicaciones, colaboración, datos, licencias, dispositivos y políticas. Cambiarlo sin descubrir las dependencias puede impactar no solo en Outlook, sino en nóminas, ventas, aplicaciones operativas y acceso a información crítica.

La alternativa tampoco consiste en conservar dos entornos indefinidamente por miedo. Mantener tenants separados puede generar costes duplicados, colaboración incompleta, dificultad para encontrar personas, gobierno fragmentado y problemas de seguridad si no se configuran relaciones de confianza correctamente. El equilibrio se consigue identificando qué sinergias busca realmente la operación y qué riesgos merece la pena asumir para obtenerlas.

Esta guía está escrita para CIOs, directores de tecnología, responsables de integración postadquisición y CFOs. Su objetivo es aportar un método para elegir entre convivencia, consolidación por fases y migración completa, así como un conjunto de preguntas que deberían formar parte de cualquier proceso de selección de un partner especializado. No parte de la idea de que migrar siempre sea bueno ni de que conservar tenants siempre sea más seguro.

Tres caminos posibles

Convivir, migrar por fases o unificar: no son decisiones equivalentes

Microsoft permite organizar relaciones de colaboración entre tenants sin hacerlos desaparecer. En determinados escenarios de adquisición, esa convivencia controlada es suficiente para que los equipos compartan aplicaciones, información y espacios de trabajo durante meses o incluso de forma indefinida. En otros, el coste de mantener dos administraciones y la complejidad de los procesos comunes justifican concentrar servicios en un tenant de destino.

La elección también debe incorporar preguntas organizativas: ¿se consolidarán realmente las sociedades?, ¿se mantienen marcas diferenciadas?, ¿hay equipos que cambian de empleador?, ¿se unifica el soporte?, ¿existen regiones o negocios con obligaciones distintas? Una arquitectura que parece perfecta para el día uno puede quedarse corta si la empresa tiene previsto vender una unidad de negocio o integrar otra adquisición al cabo de un año.

La documentación de Microsoft sobre organización multitenant insiste en que cada administrador mantiene el control sobre los recursos de su tenant. Las relaciones de acceso entrante y saliente deben configurarse explícitamente. Eso es una ventaja de gobierno, pero también una responsabilidad: una colaboración mal diseñada puede multiplicar invitaciones, permisos y excepciones difíciles de auditar.

Cuando no conviene moverlo todo

Qué puedes resolver manteniendo dos tenants Microsoft 365

La convivencia no es un apaño provisional necesariamente. Bien diseñada, puede habilitar colaboración inmediata mientras la integración de ERP, finanzas, operaciones o estructura societaria sigue su propio ritmo. Microsoft Entra ofrece distintas capacidades; conviene escogerlas en función de la experiencia requerida y no confundirlas con una migración de identidades.

La precisión técnica importa: sincronizar una identidad externa no mueve su buzón, su sitio de OneDrive ni los mensajes de Teams. Configurar un canal compartido tampoco traslada automáticamente todos los equipos y canales existentes. Por otro lado, ciertas experiencias de colaboración entre tenants necesitan licencias, condiciones y configuraciones específicas que deben revisarse para el caso concreto. El objetivo de la fase de convivencia debe ser resolver necesidades de negocio medibles, no recrear artificialmente una sensación de tenant único.

En la primera fase de una adquisición puede ser preferible dar acceso seguro a documentación y equipos de proyecto, establecer visibilidad de calendarios, crear canales compartidos y centralizar el soporte. Con ello se habilita colaboración sin forzar aún una migración de cientos de buzones, equipos y dispositivos. Cuando se conoce el mapa real de dependencias, la consolidación puede priorizar cargas que aporten valor verificable.

La diferencia entre trasladar datos y recuperar el trabajo

Qué se puede migrar de Microsoft 365 y qué no se mueve automáticamente

Cuando se decide consolidar, la peor suposición es que existe un único botón de “migrar Microsoft 365”. Microsoft proporciona herramientas específicas para distintas cargas y un Migration Orchestrator que coordina parte de ellas, pero los límites de cada servicio no son idénticos. Hay datos personales, espacios compartidos, aplicaciones, configuraciones y objetos de identidad que requieren tratamiento propio.

La documentación vigente de Microsoft indica que el orquestador puede coordinar, según su ámbito, buzones de Exchange Online, OneDrive, chats de Teams y reuniones de Teams. Esa cobertura es relevante, pero el contenido compartido de equipos y canales y los sitios SharePoint no queda incluido automáticamente en ese mismo proceso. Además, el orquestador mueve datos de usuario, no identidades: la organización debe preparar usuarios y correspondencias en el tenant destino. Sus prerrequisitos y licencias deben verificarse antes de comprometer un proyecto.

La tabla muestra por qué el inventario debe ser el primer entregable real. No basta con conocer el número de buzones o gigabytes. Para una empresa de proyectos, el equipo de Teams que guarda toda la información de un cliente puede ser más crítico que cientos de documentos personales. Para otra, el bloqueo de una aplicación conectada a Entra o de un flujo en Power Automate puede afectar a facturación y atención al cliente.

Experiencia de empleado y continuidad

El verdadero éxito es que la empresa pueda trabajar al día siguiente

El usuario no evalúa una migración por el número de objetos transferidos. La evalúa por si puede comenzar el lunes, abrir Outlook, acceder a su calendario, encontrar los archivos del proyecto, responder a un cliente y entrar en las aplicaciones que utilizaba el viernes. Por eso hay que diseñar una experiencia de transición, no limitarse a declarar una fecha de corte.

Microsoft documenta limitaciones específicas en reuniones y chats al usar su orquestador. Según el escenario, no se trasladan grabaciones, transcripciones, ciertos eventos y plantillas de reunión; también pueden cambiar enlaces o participantes. Presentar la migración de Teams como “migración íntegra y transparente de todo Teams” sería un compromiso comercial poco responsable. Los pilotos deben demostrar exactamente qué contenido se conserva, qué experiencia cambia y qué acciones tienen que realizar los usuarios.

Tampoco es realista presupuestar un proyecto sin asignar una fase de soporte reforzado. Algunas incidencias aparecen cuando los empleados salen de la oficina y vuelven a conectarse desde el móvil, o cuando un proveedor externo intenta acceder a un documento. Una oficina puede superar correctamente el piloto mientras un equipo con acceso a aplicaciones heredadas sigue bloqueado. Las pruebas deben representar áreas, dispositivos, zonas geográficas, responsabilidades y perfiles de trabajo diferentes.

En un cambio corporativo delicado conviene nombrar responsables de comunicación, soporte, negocio y seguridad. El equipo de proyecto debe dar instrucciones sencillas: qué cambia, cuándo sucede, cómo acceder, a quién avisar, qué sucede con los enlaces antiguos y qué hacer si una tarea crítica falla. La información que recibe el usuario forma parte de la continuidad de negocio.

Seguridad antes, durante y después

El riesgo no es solo perder correo: es perder el control de identidades y accesos

Las identidades suelen ser la primera dependencia subestimada. Un inicio de sesión corporativo da acceso a aplicaciones SaaS, ERP, CRM, VPN, automatizaciones, portales de clientes y herramientas internas. Si la empresa cambia el tenant donde residen esas identidades, las relaciones de confianza, autorizaciones y objetos de usuario pueden requerir adaptación. No son problemas de correo: son problemas de arquitectura de acceso.

Los dominios personalizados merecen su propio plan. Microsoft indica que un dominio no puede estar verificado al mismo tiempo en dos tenants de Microsoft Entra. Eso implica preparar la retirada del dominio en origen, eliminar referencias que bloqueen su liberación y verificarlo en destino, cuando forme parte de la estrategia. El flujo de correo, las cuentas de servicio y los alias deben coordinarse con los cambios de DNS y la secuencia de corte. El detalle varía según el escenario y no debería improvisarse durante una ventana nocturna.

La seguridad tampoco se copia por arte de magia. Es necesario inventariar políticas de acceso condicional, métodos de autenticación, privilegios, identidades externas, dispositivos administrados, aplicaciones empresariales, retención de información y requisitos regulatorios. En determinadas organizaciones, el diseño correcto puede consistir en mantener áreas o unidades en tenants diferenciados precisamente por sus obligaciones de segregación y control.

La orientación general de seguridad y cumplimiento en Microsoft 365 debe acompañar este trabajo: los controles de identidad, colaboración y dato necesitan continuidad. Un proyecto que reduce dos tenants a uno pero deja políticas sin validar o permisos excesivos no puede calificarse de éxito simplemente porque los buzones se hayan migrado.

Aplicaciones que dependen del tenant

Power Platform y Dynamics 365 pueden cambiar por completo la decisión

La presencia de Power Platform o Dynamics 365 introduce una dificultad que a menudo no se ve en una oferta centrada en Microsoft 365. Muchas compañías dependen de procesos automatizados que conectan formularios, SharePoint, Dataverse, ERP, CRM, correo y sistemas externos. En la adquisición, esos flujos pueden llevar meses funcionando sin incidencias y, precisamente por eso, no figuran en el primer inventario de IT.

Microsoft ofrece procedimientos de migración de entornos entre tenants para determinados escenarios de Power Platform. No son universales: hay tipos de entorno no admitidos, componentes excluidos y procesos específicos para aplicaciones y servicios. La documentación advierte de que los grupos de seguridad no se migran como parte de determinados movimientos y que existen tareas posteriores para Power Automate, Power Apps, Copilot Studio, Power Pages o Customer Insights. En entornos Finance & Operations el soporte y las restricciones requieren una validación específica, incluida la presencia de complementos y licencias ISV.

Un CRM de ventas puede conservar clientes, oportunidades y actividad, pero dejar de enviar notificaciones si falla un conector o una conexión con un buzón. Un ERP puede mantenerse en su plataforma habitual y aun así dejar de autenticar usuarios mediante una integración dependiente del tenant anterior. Un proceso de aprobación puede terminar en un grupo de seguridad que ya no existe. La evaluación debe bajar al nivel de proceso de negocio: quién lo utiliza, cuándo se ejecuta, qué aplicaciones conecta y qué sucede si no funciona.

Por eso una evaluación de tenants debe implicar no solo al equipo Modern Work, sino también a responsables de aplicaciones empresariales, integración y seguridad. El objetivo no es ampliar artificialmente el alcance del proyecto: es identificar una incidencia que podría parar un proceso importante y prevenirla. La visión integrada de Ayesa Digital y el ecosistema Microsoft permite tratar estas dependencias como parte de un único mapa de negocio.

Cuándo decir que no

Seis motivos para no fusionar tenants todavía

Hay situaciones en las que recomendamos no consolidar inmediatamente, aunque la dirección quiera una imagen corporativa única. Por ejemplo, cuando la compañía adquirida está en plena campaña comercial o en un cierre financiero crítico; cuando existe una separación societaria pendiente de aprobación; cuando una unidad utiliza aplicaciones cuya identidad no se ha inventariado; cuando no se dispone de las autorizaciones administrativas necesarias; o cuando los equipos de IT desconocen cómo se utilizan determinados grupos y permisos.

Tampoco tiene sentido presentar una migración integral como un proyecto urgente si la necesidad inmediata es que veinte directivos compartan calendarios, que dos áreas trabajen en determinados documentos o que la organización central tenga visibilidad de algunos indicadores. Esas necesidades pueden resolverse primero con colaboración, gobierno o integración selectiva. La consolidación técnica puede venir después, cuando su valor esté demostrado.

La pregunta del CFO

Cómo comparar el coste total de mantener dos tenants frente a consolidarlos

La dirección financiera suele comparar dos presupuestos: mantener dos entornos frente al precio de migrarlos. Es un punto de partida insuficiente. La convivencia también cuesta: soporte duplicado, controles diferentes, administración de identidades, herramientas redundantes y tiempo dedicado a resolver fricciones entre organizaciones. Pero migrar introduce inversión en descubrimiento, herramientas, licencias, proyectos técnicos, comunicación, pruebas, soporte reforzado y adaptación de aplicaciones.

La comparación más útil es a tres años, con hipótesis explícitas y distintos escenarios. Se deben separar costes inevitables —por ejemplo, licencias y operación que la organización necesitará en cualquier modelo— de costes incrementales asociados a seguir separados o a consolidar. También hay que incluir beneficios que no aparecen como una línea de ahorro inmediato: incorporación más rápida de empleados, mejor gobierno, identidad más clara, menos excepciones y reducción del riesgo de parada.

No ofrecería un precio genérico por usuario sin conocer complejidad, volumen de datos y dependencias. Dos compañías con 500 personas pueden tener proyectos radicalmente diferentes: una usa Microsoft 365 de manera estándar y tiene cinco integraciones; la otra administra cientos de sitios, automatizaciones, dispositivos, aplicaciones propias y requisitos de cumplimiento. El número de usuarios no explica por sí solo la dificultad del proyecto.

Un modelo sencillo para el comité puede expresar el coste de convivencia a tres años como la suma de licencias, operación de dos tenants, seguridad, coordinación y fricción atribuible a los procesos. El coste de consolidación añade evaluación, licencias de migración, herramientas, implantación, soporte reforzado y adaptación de aplicaciones, pero puede reducir parte del coste operativo futuro. La valoración debe tratar los riesgos de parada como escenarios y no presentarlos como pérdidas ciertas.

Del diagnóstico al entorno estable

Una hoja de ruta de seis etapas que evita improvisar con el correo, los datos y la seguridad

No hay un cronograma responsable que empiece directamente por mover datos. Un proyecto de consolidación requiere una fase de decisión y preparación que determine qué servicios están dentro del alcance y quién responde por cada dependencia. La secuencia siguiente es orientativa y se adapta al tamaño, criticidad y modelos de las organizaciones implicadas.

En la planificación deben existir puertas de decisión explícitas. Una oleada no debería avanzar si el piloto deja incidencias críticas sin resolver, si falta el mapeo de identidad o si no se dispone de capacidad de soporte. Y el retorno atrás debe describirse por componente: el rollback de un buzón, de una identidad o de una reunión puede ser muy distinto. Microsoft documenta que después de cierto punto de corte algunas acciones ya no pueden cancelarse como si no hubieran ocurrido.

La coordinación también debe incluir a proveedores externos. Si una aplicación utiliza SSO con el tenant adquirido, el responsable del servicio debe confirmar con antelación cómo cambia el registro de la aplicación, cómo se gestionan secretos y certificados y cómo se valida el acceso. Es preferible descubrir esa dependencia en un ensayo que la mañana en que la organización unificada intenta facturar.

El buen resultado no es una gráfica que muestra usuarios completados. Es una verificación compartida con el negocio: el correo llega, los documentos están disponibles, los equipos trabajan, las políticas se aplican, las aplicaciones funcionan y los incidentes residuales tienen un responsable y un plazo de resolución.

Para CIO, compras y dirección

Qué debe incluir una RFP de consolidación de tenants Microsoft 365

Para un CIO que evalúa proveedores, una oferta basada en “migración de usuarios a precio cerrado” resulta insuficiente si no deja claro qué servicios y riesgos incorpora. El documento de solicitud de propuesta debería exigir el alcance por carga, una matriz de responsabilidades, dependencias, licencias de migración, exclusiones, pruebas, cronograma por oleadas, soporte posterior y entregables verificables. También es necesario precisar qué hace el cliente y qué debe aportar cada proveedor de aplicaciones.

Pedir estas evidencias no significa convertir la compra en un concurso burocrático. Significa que el proveedor ha comprendido la diferencia entre ejecutar una operación técnica y responsabilizarse de un resultado empresarial. La empresa no compra únicamente una migración de datos: compra la capacidad de integrar organizaciones sin perder productividad, protección de la información ni continuidad de sus procesos.

Ejemplo práctico de decisión

Una adquisición con 650 empleados: por qué no empezaría migrando todo

Caso ilustrativo: una empresa industrial adquiere una organización de servicios con 650 profesionales repartidos en varias sedes. Ambas utilizan Microsoft 365, pero sus entornos son diferentes. La primera tiene más controles de dispositivos y seguridad; la segunda utiliza Teams y SharePoint intensivamente para proyectos externos, mantiene aplicaciones SaaS conectadas a Entra y ha creado decenas de automatizaciones de Power Platform. La dirección quiere que los equipos colaboren cuanto antes y que la marca corporativa sea coherente.

Una migración concentrada podría parecer la opción más rápida, pero el inventario descubre que algunos proyectos con clientes externos dependen de canales compartidos y permisos existentes; que varios procesos de aprobación utilizan conectores asociados a identidades personales; y que un grupo de técnicos accede a una aplicación externa mediante el tenant adquirido. El impacto no estaría limitado a la cuenta de correo. Tampoco sería necesario esperar un año entero para que las organizaciones trabajasen juntas.

La alternativa estudiada sería crear primero un modelo de colaboración y acceso controlado, establecer una política de seguridad común donde resulte viable, planificar la consolidación de identidades y correo por colectivos, y separar el tratamiento de sitios SharePoint, Teams y aplicaciones críticas. De ese modo, los equipos empiezan a colaborar mientras el proyecto obtiene evidencia técnica para migrar las cargas que realmente deben unificarse.

En una segunda fase, Finanzas y IT podrían valorar el coste de seguir administrando dos tenants frente a los costes del proyecto de consolidación. Si el análisis concluye que determinadas unidades mantienen autonomía por necesidades legales o comerciales, el modelo multitenant no debería verse como un fracaso: puede ser la arquitectura empresarial correcta. Este ejemplo no describe un cliente real de Ayesa Digital, sino una forma de aplicar los criterios a una decisión compleja.

La propuesta de Ayesa Digital

Transformación Microsoft 365 con visión de negocio, seguridad y continuidad

Ayesa Digital puede ayudar a convertir la consolidación de Microsoft 365 en un proyecto alineado con la transformación de la organización. El punto de partida es entender el negocio y el modelo operativo: sociedades, sedes, perfiles, necesidades de colaboración, criticidad de aplicaciones y objetivos de seguridad. A partir de ahí se evalúan alternativas, se seleccionan herramientas y se diseñan las condiciones de la transición.

La amplitud del ecosistema Microsoft es importante porque los tenants no funcionan aislados. Identidad, Intune, Teams, SharePoint, OneDrive, Power Platform, Dynamics 365, aplicaciones externas y Copilot se apoyan en relaciones que deben mantenerse coherentes. Un partner que solo valora el movimiento de buzones puede pasar por alto dependencias empresariales decisivas. Un enfoque end-to-end permite ordenar el diagnóstico, el gobierno y la ejecución con responsables de cada especialidad.

No planteamos una consolidación como respuesta automática: en algunos casos el resultado del diagnóstico será una hoja de ruta multitenant con colaboración segura. En otros será una consolidación por fases. Y en organizaciones con menor complejidad podrá estar justificada una transición concentrada. El objetivo es recomendar el camino que ofrezca el mejor equilibrio entre operación, seguridad, inversión y tiempo.

Preguntas frecuentes

Qué conviene saber antes de aprobar una migración entre tenants

Estas respuestas ayudan a diferenciar decisiones que suelen mezclarse en un mismo proyecto. Las condiciones técnicas, comerciales y legales deben comprobarse para cada tenant y servicio antes de aprobar un cambio en producción.

Referencias oficiales

Qué documentación Microsoft sostiene las decisiones de esta guía

La arquitectura y la disponibilidad de mecanismos de migración evolucionan. Para evitar promesas incorrectas, las condiciones de producto, licencias, requisitos previos y limitaciones deben contrastarse antes de emitir una propuesta de proyecto. Estas referencias oficiales de Microsoft son el punto de partida técnico para diseñar un plan por cargas de trabajo.

Ayesa Digital y su ecosistema Microsoft

Otras capacidades relacionadas con la integración tecnológica de empresas

La consolidación de tenants es una decisión concreta dentro de una arquitectura Microsoft 365 más amplia. Si la necesidad principal es productividad, seguridad, gobierno documental o adopción de IA, existen recorridos específicos que pueden avanzar incluso antes de mover identidades y datos. Estos recursos permiten profundizar sin confundir ámbitos de proyecto.

UNA ADQUISICIÓN DEBE CREAR VALOR, NO PARAR LA EMPRESA

Antes de fusionar tenants, decide qué necesita unificarse de verdad.

Un diagnóstico de Ayesa Digital puede ayudarte a definir el modelo de convivencia, identificar las dependencias que afectan a empleados y aplicaciones, evaluar los mecanismos de migración y construir una hoja de ruta defendible para Dirección, IT, seguridad y Finanzas.