Kloudeal Journal · Guía para empresas
Un servicio de migración entre tenants debe definir qué información y servicios se trasladan y cómo se comprueba el cambio. Esta guía explica qué pedir en el análisis, la propuesta y la entrega de un proyecto de consolidación o separación de Microsoft 365.
Alcance, exclusiones y responsabilidades.
Preparación, piloto, traslado y cambio de servicio.
Pruebas, documentación y soporte acordado.
Contenido de esta guía
Resumen rápido del servicio
La revisión incluye Analizamos el tenant origen y el tenant destino antes de iniciar la migración, Definimos qué se migra, qué no se migra y qué debe revisarse manualmente, Trabajamos con Exchange Online, OneDrive, SharePoint, Microsoft Teams, dominios, usuarios, permisos y licencias, Revisamos DNS, UPN, MX, SPF, DKIM, DMARC, autodiscover y dependencias del dominio, Podemos utilizar herramientas nativas de Microsoft o soluciones especializadas como Quest, BitTitan, Cloudiway o ShareGate según el caso e Incluimos validación posterior y acompañamiento para reducir incidencias después del corte.
Qué debe quedar acordado antes de contratar una migración entre tenants
Un servicio de migración entre tenants debe describir la situación de llegada de cada grupo de usuarios. El cliente necesita saber con qué cuenta iniciará sesión el empleado, dónde encontrará su correo y sus documentos y qué cambios afectarán a sus dispositivos o aplicaciones. Esta descripción es más precisa que una promesa general de trasladar Microsoft 365 sin distinguir sus componentes.
En una separación de negocio, por ejemplo, no siempre se trasladan todos los datos de una persona o de un equipo. La empresa debe decidir qué información pertenece al nuevo entorno y qué colaboración seguirá siendo necesaria con el anterior. El proveedor convierte esas decisiones en un plan técnico, pero la aprobación del alcance corresponde a los responsables de la información y del proyecto.
La propuesta debe identificar dependencias que pueden alterar el calendario: liberación del dominio, acceso autorizado a ambos tenants, preparación de identidades, compatibilidad de herramientas o disponibilidad de validadores. Para cada una se registra un responsable y una condición de cierre. Así se evita utilizar la fecha de corte como solución a decisiones que todavía no se han tomado.
Cómo valorar la calidad de la entrega y del acompañamiento
La calidad del servicio se comprueba con resultados vinculados al alcance. Cada carga necesita informes de transferencia, diferencias explicadas y pruebas funcionales. Un estado correcto en la herramienta no acredita por sí solo que las personas puedan abrir un buzón delegado, trabajar en un sitio o utilizar una aplicación con la nueva cuenta.
El acompañamiento debe tener un canal y una cobertura acordados para el primer periodo de uso. Las incidencias se clasifican por impacto y se asignan a quien puede resolverlas, distinguiendo errores del proyecto de necesidades adicionales. Al cerrar se entregan decisiones, configuración relevante, asuntos pendientes y responsabilidades de operación, de forma que el equipo del cliente pueda administrar el destino con información suficiente.
Cómo preparar la aceptación con los responsables de cada departamento
El responsable funcional debe participar antes de la fecha de corte, cuando todavía se pueden ajustar las pruebas y el alcance. No necesita validar parámetros internos de la herramienta: necesita confirmar que sus usuarios pueden realizar las acciones acordadas. Para administración puede ser consultar un buzón compartido y responder a un proveedor; para un equipo de proyectos, abrir su documentación y trabajar con un colaborador externo. Cada caso se registra con las cuentas y recursos que se utilizarán en la prueba.
El informe de aceptación debe explicar las diferencias que el usuario observará. Una nueva convocatoria de reunión, un enlace que debe actualizarse o una aplicación que requiere volver a iniciar sesión no deberían aparecer como sorpresas durante el primer día. Si esos cambios se conocen en el piloto, se preparan instrucciones y responsables. Si afectan a una función imprescindible y no existe una alternativa aceptada, la decisión de avance debe revisarse antes de ampliar el lote.
Este acuerdo también ayuda a cerrar incidencias con criterio. El equipo técnico demuestra la corrección repitiendo la prueba, y el departamento confirma el resultado del proceso. Cuando queda una excepción aceptada, se documenta su motivo y su seguimiento, para distinguirla de un fallo que todavía impide considerar finalizada la entrega.
Qué es un servicio de migración tenant to tenant de Microsoft 365
Un tenant de Microsoft 365 es el entorno donde una organización administra usuarios, licencias, dominios, correo, archivos, Teams, SharePoint, OneDrive, políticas y servicios cloud. Una migración tenant to tenant consiste en trasladar parte o la totalidad de esos usuarios, datos y servicios desde un tenant de origen a un tenant de destino. Este tipo de proyecto puede afectar a: Usuarios y grupos, Buzones de Exchange Online, Calendarios, contactos y buzones compartidos, OneDrive de usuarios, Sitios y bibliotecas de SharePoint Online, Microsoft Teams, equipos, canales, archivos y permisos, Dominios personalizados, Licencias y servicios activos, Microsoft Entra ID, Aplicaciones empresariales, Power Platform, Power BI y conectores y Configuraciones de seguridad y cumplimiento.
Microsoft documenta este tipo de migraciones para escenarios como fusiones, adquisiciones, desinversiones y reorganizaciones internas. Puedes consultar su documentación oficial sobre planificación de migraciones tenant-to-tenant de Microsoft 365.
Cuándo necesita una empresa migrar entre tenants
Las migraciones entre tenants suelen aparecer cuando cambia la estructura de una empresa o cuando el entorno de Microsoft 365 necesita consolidarse. Fusiones y adquisiciones. Cuando una empresa adquiere otra, puede ser necesario integrar usuarios, correo, archivos, Teams y colaboración en el tenant corporativo principal. Separaciones de empresa o unidades de negocio. Cuando una división se separa, se vende o pasa a operar de forma independiente, puede necesitar su propio tenant con usuarios, datos y dominios separados.
Consolidación de tenants. Algunas organizaciones tienen varios tenants por crecimiento, compras previas, filiales o decisiones históricas. Consolidar puede simplificar administración, licencias y gobierno del entorno. Cambio de dominio o marca. Un cambio de marca puede implicar nuevos dominios, nuevas direcciones de correo, cambios de UPN, ajustes DNS, firmas, aplicaciones y comunicación interna. Reorganización interna. También puede haber migraciones por cambios de estructura, centralización de TI, cumplimiento, integración de servicios o reducción de entornos duplicados.
Qué podemos migrar en Microsoft 365
El alcance depende de cada empresa. Antes de migrar, revisamos qué servicios se utilizan realmente, qué volumen de datos existe y qué limitaciones puede tener cada carga.
| Área | Qué puede incluir | Qué revisamos antes |
|---|---|---|
| Usuarios y grupos | Usuarios, grupos de Microsoft 365, grupos de seguridad, listas y propietarios. | UPN, duplicados, usuarios inactivos, identidad híbrida, roles y licencias. |
| Exchange Online | Buzones, calendarios, contactos, archivo online, compartidos, salas y recursos. | Dominios, MX, aliases, delegaciones, reglas, conectores, tamaño y permisos. |
| OneDrive | Archivos personales de usuarios y contenido compartido. | Volumen, permisos, enlaces, usuarios inactivos, sincronización y retención. |
| SharePoint Online | Sitios, bibliotecas, documentos, permisos, estructura y metadatos según herramienta. | Sitios obsoletos, propietarios, permisos únicos, versiones, enlaces y acceso externo. |
| Microsoft Teams | Equipos, canales, miembros, propietarios, archivos y parte de conversaciones según herramienta. | Canales privados, invitados, chats, pestañas, apps, Planner, OneNote y permisos. |
| Dominios | Dominios personalizados, UPN, correo, DNS, MX, SPF, DKIM y DMARC. | Dependencias, objetos que usan el dominio, ventana de corte y validación. |
| Aplicaciones | Aplicaciones empresariales, SSO, registros de apps, conectores y automatizaciones. | Permisos API, secretos, certificados, propietarios, Power Platform y dependencias. |
Exchange Online: correo, calendarios y buzones compartidos. El correo suele ser la parte más visible para los usuarios. Por eso revisamos buzones, calendarios, contactos, buzones compartidos, salas, recursos, delegaciones, permisos, reglas, conectores y DNS. Microsoft documenta la migración cross-tenant de buzones, incluyendo requisitos, licencias y configuración. OneDrive: archivos personales y compartidos. OneDrive requiere especial atención porque muchos archivos personales también están compartidos con otros usuarios o externos. Revisamos propietarios, permisos, enlaces, usuarios inactivos, volumen y datos sujetos a retención.
Microsoft documenta la migración cross-tenant de OneDrive y sus requisitos. SharePoint Online: sitios, bibliotecas y permisos. SharePoint suele contener documentación crítica de departamentos, proyectos y equipos. Antes de migrar, conviene revisar qué sitios siguen activos, qué permisos existen, qué bibliotecas son críticas y qué contenido puede limpiarse. En algunos escenarios se pueden evaluar capacidades nativas de Microsoft para migración cross-tenant de SharePoint.
Microsoft Teams: colaboración, canales y archivos. Teams depende de SharePoint, OneDrive, Exchange Online, grupos de Microsoft 365, aplicaciones, permisos e invitados. Por eso no debe tratarse como una simple copia de equipos. Revisamos equipos activos, propietarios, miembros, invitados, canales privados, canales compartidos, archivos, conversaciones, pestañas, Planner, OneNote, aplicaciones y expectativas de usuario. Dominios, UPN y DNS. Los dominios personalizados son una parte crítica de la migración. Afectan a inicio de sesión, correo, autodiscover, SPF, DKIM, DMARC, aplicaciones, Outlook y dispositivos móviles.
Antes del corte revisamos qué objetos usan el dominio, cómo se liberará del tenant origen, cuándo se añadirá al destino y qué registros DNS deben modificarse.
Qué no conviene prometer en una migración tenant to tenant
Una migración profesional debe ser clara sobre lo que se puede hacer y lo que depende de herramientas, licencias, límites de Microsoft, permisos, APIs y configuración del entorno. Por eso evitamos promesas como: “Sin pérdida de datos” como garantía absoluta, “Cero interrupciones” en cualquier escenario, “Todo quedará exactamente igual”, “Todos los chats de Teams se migrarán completos”, “Todas las aplicaciones funcionarán sin cambios”, “Todos los enlaces antiguos seguirán funcionando” y “Todos los permisos se conservarán sin revisión”.
Lo correcto es definir alcance, validar herramientas, hacer piloto, comunicar limitaciones y comprobar el resultado con usuarios y servicios críticos.
Nuestro proceso de migración paso a paso
Cada empresa tiene un entorno distinto. Por eso estructuramos la migración por fases, adaptando el plan al tamaño del tenant, los servicios utilizados y el nivel de riesgo.
1. Análisis inicial del entorno
Antes de proponer una herramienta o una fecha de corte, revisamos el entorno de origen y el objetivo del proyecto. En esta fase analizamos: Número de usuarios, Dominios personalizados, Licencias actuales, Usuarios activos e inactivos, Buzones de usuario, compartidos, salas y recursos, Volumen de correo y archivo online, OneDrive de usuarios, Sitios de SharePoint, Equipos y canales de Teams, Invitados externos, Permisos sensibles, Aplicaciones conectadas, Power Platform, Power BI y automatizaciones e Identidad híbrida si existe Active Directory local.
El resultado de esta fase es una visión más clara del alcance, los riesgos y el esfuerzo real del proyecto.
2. Preparación del tenant destino
Una migración no debe empezar a copiar datos si el tenant destino no está preparado. Podemos ayudarte a preparar: Usuarios y grupos, Licencias necesarias, Dominios temporales o definitivos, Configuración base de Exchange Online, Políticas iniciales de seguridad, Microsoft Entra ID, Acceso condicional, MFA y cuentas administrativas, SharePoint y OneDrive, Teams y políticas necesarias y Permisos administrativos para herramientas de migración.
También revisamos si el dominio principal debe moverse durante una ventana de corte o si conviene trabajar con dominios temporales hasta el cambio final.
3. Selección de herramienta y estrategia
No siempre se usa la misma herramienta. La elección depende del alcance y de las cargas incluidas. Podemos evaluar opciones como: Herramientas nativas de Microsoft: Migration Orchestrator, cross-tenant mailbox migration, OneDrive y SharePoint cross-tenant cuando encajan, Quest On Demand Migration: para proyectos tenant-to-tenant amplios con varias cargas de Microsoft 365, BitTitan MigrationWiz: especialmente útil en migraciones de correo y determinados escenarios Microsoft 365, Cloudiway: para escenarios cross-tenant y multiworkload, ShareGate: especialmente interesante para SharePoint, OneDrive, Teams y gobierno de contenido y PowerShell y Microsoft Graph: para inventario, automatización, preparación y validación.
Microsoft documenta Migration Orchestrator como funcionalidad para mover datos y workloads entre tenants separados en determinados escenarios.
4. Prueba piloto
Antes de migrar toda la organización, recomendamos realizar un piloto con usuarios y datos representativos. El piloto puede incluir: Un buzón estándar, Un buzón grande, Un buzón compartido, Un OneDrive con datos compartidos, Un sitio SharePoint con permisos relevantes, Un Team con canales, archivos e invitados, Un usuario con móvil y Outlook y Un caso con permisos delegados. El piloto ayuda a comprobar tiempos reales, errores, limitaciones de la herramienta, calidad de datos migrados y experiencia de usuario.
5. Migración por fases
En la mayoría de proyectos, la migración se organiza por fases para reducir riesgos. Podemos trabajar por: Departamentos, Grupos de usuarios, Unidades de negocio, Cargas de trabajo, Usuarios críticos y no críticos y Ventanas de menor actividad. Cuando la herramienta lo permite, se realizan migraciones iniciales y sincronizaciones incrementales antes del corte final.
6. Corte, dominios y DNS
La ventana de corte es uno de los momentos más importantes del proyecto. Puede incluir cambios en DNS, dominios, flujo de correo, inicio de sesión, Outlook, móviles y acceso a servicios. Revisamos especialmente: MX, Autodiscover, SPF, DKIM, DMARC, UPN de usuarios, Aliases y direcciones SMTP, Buzones compartidos, Conectores de correo, Aplicaciones que envían correo y Acceso a Teams, OneDrive y SharePoint.
El objetivo es que el cambio se ejecute con checklist, responsables definidos y pruebas posteriores.
7. Validación y soporte posterior
Una migración no termina cuando la herramienta indica que los trabajos han finalizado. Hay que validar que los usuarios pueden trabajar. Validamos puntos como: Inicio de sesión, Licencias asignadas, Correo entrante y saliente, Calendarios, Contactos, Buzones compartidos, Permisos delegados, Outlook, Dispositivos móviles, OneDrive y sincronización, Acceso a archivos, SharePoint y permisos, Teams, equipos y canales, Invitados externos si aplica, Aplicaciones conectadas y DNS y autenticación de correo.
También podemos acompañar durante los primeros días para resolver incidencias, dudas de usuarios, permisos pendientes o ajustes del nuevo entorno.
Seguridad, permisos y cumplimiento
Durante una migración, la seguridad no debe tratarse como un añadido final. Es parte del diseño del proyecto. Revisamos aspectos como: Roles administrativos, Cuentas con privilegios, MFA, Acceso condicional, Permisos de SharePoint y Teams, Acceso externo, Buzones compartidos y delegaciones, Datos sensibles, Políticas de retención, Microsoft Purview cuando aplica y DLP, etiquetas y cumplimiento según alcance. Si existen requisitos legales, regulatorios o internos, deben tenerse en cuenta antes de mover datos.
Comunicación con usuarios
La comunicación es una parte crítica. Una migración técnicamente correcta puede generar incidencias si los usuarios no saben qué cambia. Podemos ayudarte a preparar mensajes sobre: Fecha de migración, Qué servicios se verán afectados, Qué debe hacer cada usuario, Cambios en Outlook, Acceso desde móviles, Uso de Teams después del cambio, Inicio de sesión en el nuevo tenant y Dónde pedir ayuda.
La comunicación reduce incertidumbre y facilita que el equipo se adapte al nuevo entorno.
Por qué trabajar con Kloudeal
En Kloudeal trabajamos este tipo de proyectos con una visión práctica. No empezamos por la herramienta, sino por entender el entorno y el objetivo de la empresa. Enfoque técnico y realista. Analizamos qué se puede migrar, qué requiere revisión, qué depende de herramientas y qué puede necesitar reconfiguración manual. Alcance claro. Definimos qué incluye el proyecto, qué queda fuera, qué limitaciones existen y qué validaciones se harán.
Experiencia con Microsoft 365. Trabajamos con correo, OneDrive, SharePoint, Teams, dominios, usuarios, permisos, licencias, Microsoft Entra ID y herramientas de migración. Acompañamiento durante el cambio. Podemos ayudarte desde el análisis inicial hasta la validación posterior, incluyendo soporte a incidencias y orientación al equipo interno. Documentación y orden. Una migración debe dejar el entorno destino más claro, no más confuso. Por eso documentamos decisiones, cambios relevantes y puntos críticos.
Qué documentos conviene recibir al finalizar
El cierre de un servicio de migración debe permitir al equipo de TI continuar la administración del entorno. Para ello conviene acordar los documentos de entrega antes de comenzar: inventario final, relación de usuarios y destinos, resumen de cambios, incidencias pendientes y procedimientos que se hayan modificado. Un informe de la herramienta aporta información útil, pero no sustituye ese contexto operativo.
La aceptación puede organizarse por servicio y por grupos de usuarios. El responsable de correo comprueba recepción, envío y delegaciones; los propietarios de los repositorios revisan documentos y accesos; los responsables de aplicaciones confirman sus integraciones. Cada validación necesita un criterio concreto, una evidencia y una persona que pueda aprobarla. Así se evita que una incidencia localizada impida comprender el estado del conjunto.
También debe entregarse una relación de excepciones. Si un elemento no se ha podido trasladar, el registro debe indicar qué falta, qué impacto tiene y qué alternativa se ha acordado. No es suficiente agrupar todos los fallos bajo una cifra de errores. Algunas excepciones pueden aceptarse, otras requieren un reintento y otras obligan a mantener temporalmente una dependencia del origen.
Los accesos temporales y las licencias del proyecto tienen que revisarse después de la aceptación. La retirada se coordina con el cliente para no eliminar una cuenta o una aplicación todavía necesaria. Cuando se acuerde soporte posterior, la documentación debe distinguir incidencias del cambio, administración recurrente y solicitudes que amplían el alcance. Esa separación facilita que el usuario sepa a quién dirigirse y qué información aportar.
La revisión económica final también debe reflejar las decisiones de proyecto: servicios que continúan activos, suscripciones que se darán de baja y tareas adicionales aceptadas. El objetivo es que el responsable de la empresa reciba un entorno operativo y una explicación clara de lo que queda contratado, pendiente o fuera del servicio.
Preguntas frecuentes sobre el servicio de migración entre tenants de Microsoft 365
¿Qué diferencia un servicio entre tenants de una copia de buzones?
El servicio puede requerir coordinar identidades, dominios, datos, permisos, dispositivos y aplicaciones, además de la transferencia de correo. El alcance debe describir qué componentes incluye y cómo quedarán en destino. La diferencia se comprueba con pruebas de uso y con responsabilidades definidas para las tareas que no realiza una herramienta de copia.
¿Quién decide qué datos se trasladan en una separación empresarial?
La decisión corresponde a los responsables de negocio e información, con el asesoramiento técnico necesario para concretarla. El proveedor necesita un alcance autorizado que identifique personas, recursos y excepciones. No conviene utilizar los valores predeterminados de una herramienta para resolver qué información debe permanecer o compartirse entre las organizaciones.
¿Qué puede retrasar la fecha de una migración entre tenants?
Las dependencias sin resolver, la preparación de identidades, las limitaciones del método y las decisiones sobre dominio o aplicaciones pueden condicionar el calendario. El piloto ayuda a conocer esfuerzo y errores reales. La planificación debe registrar esas condiciones y sus responsables, en lugar de presentar la duración de copia como plazo total del servicio.
¿Qué debería incluir el soporte posterior al corte?
Debe especificar canal, cobertura, responsables y criterios de prioridad para las incidencias que afecten al funcionamiento acordado. También conviene indicar cómo se gestionarán necesidades adicionales. La entrega final incluye pruebas, diferencias aceptadas, asuntos pendientes y documentación que permita al equipo del cliente operar el nuevo entorno.
Conclusión
Una migración entre tenants de Microsoft 365 es un proyecto sensible que afecta a usuarios, datos, correo, archivos, colaboración, dominios, permisos y aplicaciones. No debería tratarse como una simple copia de información. La clave está en preparar bien el proyecto: inventario, alcance, herramienta, piloto, migración por fases, comunicación, corte, validación y soporte posterior. En Kloudeal podemos ayudarte a convertir una migración compleja en un proyecto más ordenado, con riesgos identificados y pasos claros para avanzar.
¿Necesitas migrar tu tenant de Microsoft 365?
En Kloudeal podemos revisar tu escenario y ayudarte a planificar una migración tenant to tenant de Microsoft 365 con un enfoque técnico, realista y adaptado a tu empresa. Podemos ayudarte con Exchange Online, OneDrive, SharePoint, Microsoft Teams, dominios, usuarios, permisos, licencias, herramientas de migración, PowerShell, validación y soporte posterior.
Hablar con Kloudeal sobre mi migración Microsoft 365Documentación oficial recomendada: