Migrar Microsoft Teams entre tenants: cómo trasladar equipos, canales, chats, archivos y reuniones

Una migración de Microsoft Teams entre tenants es bastante más compleja que copiar un conjunto de equipos desde una organización Microsoft 365 a otra.

Para el usuario, Teams parece una única aplicación. Desde una misma ventana puede abrir un canal, escribir un mensaje, consultar un documento, iniciar una reunión, revisar un Planner o acceder a una aplicación empresarial.

Técnicamente, sin embargo, detrás de esa experiencia intervienen varios servicios de Microsoft 365.

Los miembros de un Team están relacionados con Microsoft 365 Groups y Microsoft Entra ID. Los archivos de los canales se almacenan en SharePoint Online. Los documentos compartidos mediante chats suelen depender de OneDrive. Las reuniones tienen relación con Teams y Exchange Online. Los canales privados y compartidos tienen modelos específicos de permisos y almacenamiento. Planner, OneNote, Power BI, Power Apps y las aplicaciones de terceros añaden todavía más dependencias.

Por eso un proyecto puede terminar aparentemente bien desde el punto de vista de la herramienta y, sin embargo, dejar problemas visibles para los usuarios.

El Team está creado, pero falta un canal. El canal aparece, pero un antiguo miembro conserva acceso. Las conversaciones históricas están disponibles, pero algunas menciones se comportan de forma diferente. El archivo existe en SharePoint, pero el enlace almacenado hace dos años en un chat ya no funciona. El Planner no está donde esperaba el usuario. Una pestaña necesita volver a autorizarse. O una reunión recurrente continúa utilizando información asociada al tenant anterior.

La pregunta correcta, por tanto, no es simplemente:

“¿Se puede migrar Microsoft Teams?”

La pregunta debería ser:

“¿Qué componentes de Teams necesitamos conservar, dónde reside realmente cada uno y qué procedimiento permite trasladarlo con una experiencia aceptable para los usuarios?”

En esta guía explicamos cómo abordar una migración Microsoft Teams tenant-to-tenant en 2026, qué puede migrarse, qué diferencias existen entre equipos, canales, chats y reuniones, cómo intervienen SharePoint y OneDrive, qué ofrece Microsoft de forma nativa y cuándo merece la pena utilizar soluciones especializadas como Quest On Demand Migration, BitTitan, Cloudiway o ShareGate.

Índice

1. Qué significa migrar Microsoft Teams entre tenants
2. Por qué Teams es un workload especialmente complejo
3. Dónde almacena Teams realmente sus datos
4. Cómo definir correctamente el alcance
5. Qué inventariar antes de migrar
6. Qué Teams conviene migrar y cuáles no
7. Identidad y mapping de usuarios
8. Canales estándar, privados y compartidos
9. Archivos de canales y SharePoint
10. Archivos de chats y OneDrive
11. Conversaciones de canales
12. Microsoft Graph Migration APIs en 2026
13. Chats privados 1:1 y de grupo
14. Meeting chats
15. Reuniones de Teams
16. Microsoft Migration Orchestrator
17. Migración cross-tenant nativa de SharePoint
18. Planner, OneNote, Forms y Power Platform
19. Pestañas, aplicaciones y bots
20. Invitados y colaboración externa
21. Herramientas de migración
22. Quest On Demand Migration
23. BitTitan MigrationWiz
24. Cloudiway
25. ShareGate
26. Comparativa práctica
27. Qué estrategia elegir
28. Proceso de migración paso a paso
29. Cómo diseñar el piloto
30. Premigraciones y deltas
31. Oleadas y coexistencia
32. Cutover
33. Cómo validar una migración
34. Experiencia y comunicación a usuarios
35. Errores frecuentes
36. Checklist completo
37. Preguntas frecuentes
38. Documentación oficial

Qué significa realmente migrar Microsoft Teams entre tenants

Una migración Microsoft Teams tenant-to-tenant consiste en trasladar o reconstruir en otro tenant la colaboración que actualmente existe en Teams.

La definición parece sencilla, pero puede esconder alcances completamente diferentes.

Para una empresa, migrar Teams puede significar simplemente recrear 30 equipos, conservar sus miembros y mover los documentos. Para otra organización puede ser imprescindible mantener además años de conversaciones, canales privados, Planner, invitados, chats 1:1, reuniones futuras y aplicaciones integradas.

En consecuencia, el alcance debería descomponerse elemento por elemento.

No utilizar “migración completa” sin definir qué significa

El término puede generar una expectativa poco realista.

Es más preciso indicar, por ejemplo:

“Migración de estructura de Teams, canales estándar y privados, memberships, archivos SharePoint y conversaciones de canal. Los chats privados se tratarán mediante un proceso independiente. Apps de terceros y determinados elementos de Planner se validarán durante el assessment.”

De esa forma el alcance puede comprobarse técnicamente y aceptarse funcionalmente.

Por qué Microsoft Teams es más complejo que otros workloads

Teams funciona como una capa de colaboración sobre diferentes componentes de Microsoft 365.

Esto hace que una migración no pueda tratarse como una simple base de datos.

Un ejemplo sencillo

Imaginemos un Team llamado Dirección Financiera.

Contiene:

• dos canales estándar;
• un canal privado para dirección;
• documentos con varias versiones;
• un Planner;
• una pestaña de Power BI;
• tres invitados externos;
• conversaciones históricas;
• un OneNote;
• miembros que han abandonado la empresa.

Migrar únicamente el Microsoft 365 Group y los documentos no reproduce realmente la experiencia del Team.

Dónde almacena Microsoft Teams sus datos

Archivos de canales

Los documentos almacenados en los canales de Teams dependen de SharePoint Online.

Esto significa que una incidencia como:

“el documento no aparece en Teams”

puede tener realmente su origen en:

SharePoint + permisos + biblioteca + mapping + migración documental.

Canales privados y compartidos

Estos canales utilizan una arquitectura SharePoint específica y no deben considerarse simplemente carpetas adicionales del sitio principal del Team.

Por eso deben aparecer expresamente en el discovery.

Archivos compartidos en chats

Cuando una persona comparte un documento en un chat de Teams, ese archivo normalmente depende del OneDrive del usuario que lo compartió.

La consecuencia es especialmente importante en una migración tenant-to-tenant.

Podemos migrar correctamente:

“Mira este presupuesto”

pero perder el acceso al archivo que acompañaba al mensaje si OneDrive y sus permisos no se han tratado correctamente.

Reuniones y calendario

Las reuniones están relacionadas con Teams, pero también con Exchange Online y el calendario del organizador.

Por eso Microsoft coordina Exchange y Teams Meetings dentro de sus procedimientos nativos de migración de usuario.

Mensajes y cumplimiento

El contenido de Teams también puede tener implicaciones para:

• retención;
• eDiscovery;
• Legal Hold;
• Microsoft Purview;
• investigaciones;
• requisitos regulatorios.

Migrar el contenido operativo de Teams y conservar evidencias para cumplimiento son necesidades relacionadas, pero no deberían darse por equivalentes sin realizar un análisis específico.

Cómo definir correctamente el alcance de una migración de Teams

Antes de comparar Quest, Microsoft, BitTitan o cualquier otra solución conviene completar una matriz de alcance.

Separar “must have” de “nice to have”

No todos los componentes necesitan el mismo nivel de fidelidad.

Por ejemplo, una empresa puede determinar que:

los archivos y miembros son críticos, las conversaciones de los últimos 12 meses son importantes y el histórico anterior solo necesita conservarse como referencia.

Esa decisión puede cambiar completamente la herramienta, el coste y la duración del proyecto.

Qué inventariar antes de migrar Microsoft Teams

El discovery no debería terminar con una cifra como:

“Tenemos 325 Teams.”

Esa cifra dice muy poco sobre la complejidad real.

El inventario debe servir para decidir

El objetivo final no es generar un Excel con muchos datos.

Es poder clasificar cada Team como:

migrar + fusionar + archivar + reconstruir + excluir.

No todos los Teams deberían viajar al nuevo tenant

Una reorganización empresarial suele ser una buena oportunidad para reducir el sprawl de Microsoft Teams.

Con los años pueden acumularse:

• Teams de proyectos terminados;
• pruebas;
• duplicados;
• Teams sin owner;
• espacios sin actividad;
• Teams creados para una única reunión;
• invitados que ya no colaboran;
• aplicaciones que nadie utiliza.

Migrar menos puede mejorar el proyecto

Reduce:

tiempo + coste + volumen + incidencias + objetos obsoletos en destino.

Identidad y mapping de usuarios

Una migración de Teams depende enormemente del identity mapping.

La herramienta necesita saber que:

maria@empresa-antigua.com

corresponde ahora a:

maria@empresa.com

El mapping afecta a muchas más cosas que los miembros

• owners;
• members;
• canales privados;
• chats;
• menciones;
• metadata;
• permisos SharePoint;
• archivos;
• Planner;
• históricos.

Usuarios que ya no existen

El histórico de Teams puede incluir empleados eliminados hace años.

Debemos comprobar cómo representa la herramienta utilizada:

usuarios eliminados + usuarios no migrados + invitados + cuentas sin correspondencia.

Los usuarios deberían existir en destino antes de depender de ellos

Especialmente cuando queremos preservar memberships, autoría histórica o permisos.

UPN y dominio

Si la migración de Teams forma parte de un proyecto tenant-to-tenant completo, el cambio de identidad puede coincidir además con:

nuevo UPN + nuevo dominio + cambio de buzón + cambio de OneDrive + cambio de tenant.

Por eso conviene tratar la experiencia del usuario como un único cambio coordinado.

Canales estándar, privados y compartidos

Los tres tipos de canal no deberían meterse en la misma columna del proyecto.

Canales estándar

Utilizan la membresía general del Team y sus archivos se encuentran dentro del sitio SharePoint asociado.

Suelen ser el escenario más sencillo.

Canales privados

Disponen de membresía propia.

Un usuario puede pertenecer al Team pero no al canal privado.

Por tanto, después de migrar debemos validar al menos:

canal + miembros + owners + archivos + SharePoint + conversaciones.

Canales compartidos

Los shared channels están diseñados para colaborar con personas sin incorporarlas necesariamente a todo el Team y pueden utilizar relaciones entre organizaciones mediante Microsoft Entra B2B Direct Connect.

En tenant-to-tenant deben revisarse con especial cuidado.

Soporte de API no equivale a migración completa

Microsoft Graph permite actualmente importar mensajes históricos en canales estándar, privados y compartidos.

Eso significa que existe una API para el componente de mensajes.

No significa automáticamente que:

estructura + SharePoint + membership + colaboración externa + tabs + apps

queden trasladados por utilizar esa API.

Archivos de canales: SharePoint forma parte de la migración de Teams

Si queremos que el Team siga siendo útil, normalmente necesitamos sus documentos.

La validación debería abarcar más que contar archivos.

SharePoint nativo y Teams son dos cosas distintas

Microsoft dispone actualmente de migración nativa cross-tenant de SharePoint.

Puede ser relevante para determinados sitios asociados a Teams.

Sin embargo, mover el sitio SharePoint no mueve automáticamente:

Team + canales + conversaciones + apps + chats.

Archivos de chats: no olvidar OneDrive

Este es uno de los errores más habituales.

La conversación puede conservarse pero el documento asociado puede no funcionar como esperaba el usuario.

Ejemplo

En origen:

Ana: “Te paso el contrato actualizado.”

Archivo: contrato.docx

El mensaje pertenece al chat.

El fichero puede depender del OneDrive de Ana.

Si únicamente migramos la conversación, podemos terminar con:

Ana: “Te paso el contrato actualizado.”

Archivo: acceso denegado.

Orden de migración

Cuando la tecnología utilizada lo exige, puede ser necesario trasladar OneDrive antes del chat para que los enlaces puedan reconstruirse correctamente.

Validar desde Teams

No basta con comprobar que:

contrato.docx existe en el OneDrive destino.

Hay que comprobar también que el usuario puede abrirlo desde el contexto de la conversación migrada cuando eso forme parte de la experiencia prometida.

Migración de conversaciones de canales

Los posts de canal son probablemente uno de los elementos donde más ha evolucionado Microsoft Graph.

Qué interesa conservar

No confundir información conservada con aspecto idéntico

El contenido esencial puede estar disponible aunque algún componente visual o interactivo no sea exactamente igual.

Estas diferencias deberían comprobarse durante el piloto y comunicarse antes de la migración masiva.

Microsoft Graph Migration APIs en 2026

Microsoft ha avanzado considerablemente las APIs destinadas a importar histórico de Teams.

Migration mode

Un chat o canal puede colocarse temporalmente en un modo específico de migración para permitir la importación controlada del histórico.

El flujo conceptual es:

startMigration → importMessage → completeMigration.

Aplicación propietaria de la sesión

La aplicación que inicia el migration mode debe controlar la sesión hasta completarla.

No es un proceso donde varias herramientas puedan importar simultáneamente sobre el mismo thread.

Permiso

La aplicación utiliza el permiso de aplicación:

Teamwork.Migrate.All

junto con los permisos adicionales necesarios para crear o administrar las estructuras correspondientes.

Canales soportados por migration mode

Chats soportados

Canales y chats existentes

Una mejora importante de la arquitectura actual es la posibilidad de introducir contenido histórico en determinados chats y canales que ya existen, siempre respetando las condiciones de migration mode.

Autor original

Microsoft permite definir el autor del mensaje importado.

El usuario representado debe poder relacionarse correctamente con el tenant donde se realiza la importación, lo que vuelve a hacer crítico el identity mapping.

Timestamp histórico

También puede establecerse un createdDateTime histórico bajo las condiciones definidas por la API.

Entre otras restricciones, el timestamp debe cumplir las reglas temporales y de unicidad establecidas por Microsoft.

Qué puede importarse

Las APIs actuales contemplan varios elementos ricos de conversación, como respuestas, menciones, emojis, determinados elementos visuales y reacciones.

Pero el soporte del API establece únicamente lo que es técnicamente posible.

La experiencia final depende después de:

qué implementa la herramienta + cómo realiza el mapping + qué excepciones maneja + qué objeto está migrando.

Referencia oficial: Microsoft Graph – Import messages into Teams chats and channels.

Chats privados 1:1 y chats de grupo

Los private chats deberían figurar como una carga propia dentro del proyecto.

Hay que distinguir

• 1:1 internos;
• grupos internos;
• usuarios eliminados;
• usuarios no migrados;
• externos;
• federados;
• archivos;
• imágenes;
• meeting chats.

Un mismo usuario puede tener miles de mensajes repartidos en muchas conversaciones

Por eso el volumen de chats puede tener un impacto muy diferente al número de Teams.

Una empresa con 20 Teams y 500 usuarios puede tener un volumen de chat muchísimo mayor que otra con 100 Teams y 50 personas.

Chats activos vs histórico archivado

Algunas herramientas permiten estrategias diferentes:

histórico interactivo en Teams + histórico antiguo archivado como referencia.

Esto puede ser interesante cuando conservar cada mensaje como un thread activo no es un requisito empresarial.

Usuarios eliminados

Los chats que contienen empleados eliminados necesitan pruebas específicas.

No todas las herramientas pueden reconstruir exactamente la misma membresía ni representar al usuario histórico de la misma manera.

Los meeting chats son un caso específico

Conviene no meterlos automáticamente dentro de “chats de grupo”.

Las APIs de migration mode para chats 1:1 y grupales no equivalen al tratamiento de meeting chats.

Si conservar conversaciones vinculadas a reuniones es un requisito, debe aparecer explícitamente en el assessment de la tecnología utilizada.

Qué ocurre con las reuniones de Teams

Las reuniones futuras son uno de los componentes con mayor impacto para el usuario.

Por qué son diferentes

Una reunión tiene relación con:

organizador + calendario Exchange + Teams + asistentes + tenant + enlace.

El evento y el enlace no son conceptos equivalentes

Conservar un elemento de calendario no garantiza automáticamente que una reunión antigua se comporte exactamente como una nueva reunión organizada desde la identidad del tenant destino.

Migration Orchestrator

Microsoft dispone actualmente de una carga específica de Teams Meetings dentro de Migration Orchestrator.

Microsoft coordina esta carga con Exchange, lo que demuestra de nuevo la dependencia entre ambos servicios.

Qué probar

Microsoft Migration Orchestrator: qué migra realmente

Microsoft dispone de Migration Orchestrator para coordinar determinadas cargas de usuario en migraciones tenant-to-tenant.

Qué NO significa

No debe interpretarse esta tabla como:

“Microsoft ya migra Teams completos de un tenant a otro.”

Datos compartidos fuera del scope de usuario

Microsoft documenta fuera del mismo Cross-Tenant User Data Migration:

• Teams compartidos;
• Channels;
• SharePoint Sites.

Por tanto necesitamos dos perspectivas

No hay deltas nativos de OneDrive en este modelo

La migración cross-tenant nativa de OneDrive es un movimiento y no permite las tradicionales pasadas incrementales.

Esto puede influir en el diseño global del proyecto.

Experiencia después de migrar chats

Microsoft advierte que pueden aparecer cambios en la lista de participantes y, en determinados escenarios, threads duplicados entre origen y destino.

Después del movimiento, el usuario debería trabajar con la identidad de destino según el procedimiento definido.

Referencia oficial: Microsoft – Migration Orchestrator.

Migración cross-tenant nativa de SharePoint

Microsoft también dispone de una función independiente para mover sitios SharePoint entre tenants.

Puede ser relevante porque los archivos de Teams se apoyan precisamente sobre SharePoint.

Pero no convierte la migración en una migración completa de Teams

Podemos mover el contenido del sitio asociado.

Eso no recrea por sí solo:

• Team;
• canales;
• conversaciones;
• chats;
• Planner;
• tabs;
• apps.

Identity mapping

La migración nativa de SharePoint también necesita relacionar las identidades origen con sus equivalentes en destino.

One-and-done

Al igual que el modelo nativo cross-tenant de OneDrive, no debe diseñarse como una herramienta tradicional de premigraciones y deltas.

Referencia oficial: Microsoft – Cross-tenant SharePoint migration.

Planner, OneNote, Forms y Power Platform

Una migración de Teams puede parecer sencilla hasta que empezamos a abrir las pestañas.

Planner merece atención especial

Que una herramienta indique “Planner migration” no significa necesariamente que todos sus campos y metadata se conserven idénticamente.

Durante el piloto conviene comprobar:

tasks + assignments + labels + checklist + attachments + comments + dates.

Power Platform tiene su propia arquitectura

Una pestaña de Power App dentro de Teams no significa que la aplicación esté almacenada dentro del Team.

Migrar el Team no traslada automáticamente todo el environment de Power Platform.

Pestañas, aplicaciones y bots

Un inventario de Teams debería incluir las aplicaciones instaladas.

Tipos habituales

• aplicaciones Microsoft;
• aplicaciones del Teams Store;
• aplicaciones personalizadas;
• bots;
• webhooks;
• connectors;
• website tabs;
• LOB apps.

Qué puede cambiar al mover de tenant

Una aplicación puede depender de:

App Registration + Enterprise Application + consentimiento + secretos + permisos Graph + URL + API + base de datos.

No basta con recrear la pestaña

Podemos tener la pestaña visualmente presente y que la aplicación no funcione porque:

el nuevo tenant no tiene consentimiento + el usuario no tiene licencia + el backend espera otro tenant ID.

Invitados y colaboración externa

Los Guests deberían revisarse antes de migrar.

No existe mucho valor en trasladar cientos de invitados correspondientes a proyectos terminados hace años.

Para cada invitado

Preguntar:

¿sigue necesitando acceso?

Si continúa

Revisar:

Shared channels requieren especial atención

Puede existir una relación B2B Direct Connect con otra organización.

Mover el Team a un nuevo tenant cambia uno de los extremos de esa relación y puede requerir configuración adicional con la organización externa.

Qué herramientas existen para migrar Teams entre tenants

En 2026 existen capacidades nativas de Microsoft y varias soluciones especializadas.

La elección debería hacerse después del discovery.

No existe una herramienta universalmente mejor para cualquier tenant.

Quest On Demand Migration

Quest On Demand Migration está orientado específicamente a proyectos Microsoft 365 tenant-to-tenant y permite tratar varios workloads desde la misma plataforma.

Para Teams

Quest dispone de procesos para:

• discovery de Teams y Groups;
• assessment;
• mapping;
• provisioning;
• migración de Teams;
• remigración;
• chats;
• contenido relacionado.

Chats

Quest permite descubrir y migrar chats entre usuarios correctamente emparejados.

Esto vuelve a convertir el user matching en un requisito fundamental.

OneDrive y archivos de chat

Quest documenta expresamente que las imágenes, documentos y determinados elementos vinculados desde chats dependen de OneDrive.

Por ello, el diseño del proyecto debe coordinar OneDrive y chat migration.

Ventaja en proyectos multiworkload

Puede resultar especialmente interesante cuando Teams no es el único componente y el proyecto incluye también:

Exchange + OneDrive + SharePoint + Groups + Teams + Chats.

Pero sigue necesitando assessment

Ninguna plataforma elimina la necesidad de revisar:

• apps;
• Planner;
• usuarios eliminados;
• externos;
• canales especiales;
• grabaciones;
• elementos no soportados.

Documentación oficial: Quest – On Demand Migration User Guide.

BitTitan MigrationWiz

MigrationWiz dispone de una solución Teams-to-Teams y separa actualmente determinados escenarios de private chat en un proyecto específico.

Por qué importa

No debemos asumir que:

“tenemos una licencia de Teams Migration”

significa automáticamente:

Team + Channels + Files + Private Chats.

Private Chat

BitTitan mantiene documentación específica para su proyecto de Teams Private Chat.

Los límites de concurrencia, apps de migración, endpoints y requisitos han cambiado recientemente, por lo que deben comprobarse en la documentación vigente antes de iniciar el proyecto.

Documentación oficial:

• BitTitan – Microsoft Teams Migration Guide
• BitTitan – Teams Private Chat Migration Guide

Cloudiway

Cloudiway dispone de una solución SaaS de migración Microsoft Teams tenant-to-tenant.

Su documentación contempla, dependiendo de la configuración y componente:

• Teams;
• channels;
• memberships;
• channel conversations;
• files;
• Planner;
• permissions;
• private channels.

Teams Import APIs

Cloudiway utiliza las APIs de Microsoft Teams/Graph para inyectar determinadas conversaciones preservando metadata disponible.

Preprocessing

Su procedimiento incluye una fase previa destinada a preparar Teams y canales en destino antes de iniciar la transferencia correspondiente.

Delta

Cloudiway dispone de mecanismos de delta para determinados elementos, pero el comportamiento puede variar dependiendo de si el Team se ha cerrado y de qué metadata se pretende conservar.

Chats privados

Los chats 1:1 se tratan mediante un proceso específico separado del Team principal.

Revisar siempre la documentación actual

Cloudiway dispone de distintas páginas técnicas y de producto y el alcance ha evolucionado con el tiempo.

Antes de presupuestar una funcionalidad concreta conviene comprobar la guía vigente y realizar un piloto.

Documentación oficial: Cloudiway – Cross-Tenant Microsoft Teams Migration Guide.

ShareGate

ShareGate tiene un posicionamiento especialmente fuerte alrededor de SharePoint y Teams y permite copiar Teams y canales entre entornos.

Actualmente contempla

Entre otros elementos:

• Teams;
• standard channels;
• private channels;
• channel conversations;
• files;
• tabs;
• apps compatibles;
• Planner;
• memberships;
• SharePoint asociado.

Incremental copy

ShareGate permite determinadas migraciones incrementales para Teams ya migrados con versiones compatibles de su producto.

Shared channels

Una limitación especialmente importante en su documentación actual es que los shared channels no están soportados por ShareGate Migrate.

Si son críticos para el proyecto tendremos que plantear su recreación o una tecnología distinta.

Chats 1:1 y de grupo

Tampoco deben confundirse las conversaciones de canal que ShareGate puede tratar con el histórico general de chats privados de los usuarios.

Documentación oficial:

• ShareGate – Microsoft Teams Migration
• ShareGate – Copy Teams limitations

Comparativa práctica de herramientas

La siguiente tabla no pretende sustituir una revisión técnica de la versión actual de cada producto. Sirve para entender por qué la elección depende del alcance.

No elegir por una tabla de checks

Dos fabricantes pueden poner:

“Conversations: Supported”

y ofrecer experiencias muy diferentes.

Una herramienta puede migrar:

autor + fecha + reply + reacción

mientras otra conserva:

texto + autor

o archiva parte del histórico fuera de Teams.

La prueba definitiva es el piloto

Con contenido real de la empresa.

Qué estrategia elegir

Proceso recomendado para migrar Microsoft Teams entre tenants

1. Discovery

Descubrir:

Teams + Groups + channels + owners + members + guests + files + conversations + apps + Planner + activity.

2. Clasificación

Decidir:

migrate + merge + archive + exclude.

3. Alcance

Definir expresamente qué ocurre con:

standard + private + shared + conversations + chats + meetings + apps + Planner.

4. Mapping de identidad

Relacionar cuentas origen y destino.

5. Selección de herramienta

Solo después de conocer el contenido.

6. Preparar tenant destino

Crear o configurar:

• usuarios;
• licencias;
• dominios;
• políticas;
• apps de migración;
• consentimientos;
• guests cuando corresponda.

7. Piloto

Utilizar Teams representativos.

8. Corregir diseño

Documentar:

errores + limitaciones + diferencias esperadas + tiempos reales.

9. Premigración

Cuando la herramienta lo permita, migrar anticipadamente contenido que no necesita esperar al cutover.

10. Oleadas

Agrupar usuarios y Teams con relaciones lógicas.

11. Delta

Cuando esté soportado por el método utilizado, incorporar cambios posteriores a la premigración.

12. Cutover

Coordinar con:

identidad + Exchange + OneDrive + dominio + usuarios.

13. Validación

Comprobar técnica y funcionalmente.

14. Hypercare

Mantener soporte reforzado durante el periodo posterior acordado.

15. Cierre

Eliminar:

apps de migración + permisos temporales + configuraciones de coexistencia + licencias que ya no sean necesarias.

Cómo diseñar un buen piloto de Teams

Un piloto compuesto únicamente por un Team con dos canales y diez documentos tiene poco valor.

Hay que representar la complejidad real.

El piloto debe ser funcional

No basta con que TI confirme:

“todos los jobs están verdes”.

Un owner debería abrir el Team y comprobar cómo trabaja realmente.

Premigraciones y deltas: cuidado con mezclar herramientas

No todos los métodos permiten el mismo patrón.

Herramientas especializadas

Muchas permiten:

initial copy → incremental → final pass.

Microsoft cross-tenant OneDrive

No permite pasadas delta tradicionales.

Microsoft cross-tenant SharePoint

También debe tratarse como un movimiento, no como el mismo modelo tradicional de premigración.

Microsoft Graph migration mode

Su comportamiento depende de la sesión de migración del canal o chat.

No diseñar el cronograma antes de elegir tecnología

Decir:

“haremos una premigración un mes antes y tres deltas”

sin haber decidido la tecnología puede producir un plan imposible.

Migración por oleadas y coexistencia

En organizaciones grandes probablemente no migraremos a todas las personas el mismo día.

Agrupar usuarios que colaboran

Una oleada basada únicamente en organigrama puede ser mala.

Por ejemplo:

Ventas trabaja continuamente con Preventa y Marketing.

Migrar solo Ventas puede generar más fricción que migrar los tres grupos relacionados.

Durante la coexistencia

Podemos necesitar:

• external access;
• B2B;
• shared channels;
• acceso SharePoint;
• routing de correo;
• free/busy.

Coexistencia no significa migración

Permitir que un usuario del tenant A colabore con otro del B no mueve su Team.

Debe tener una fecha de salida

Si el objetivo es consolidar en un único tenant, conviene evitar una situación permanente de:

usuarios duplicados + guests + cross-tenant + licencias dobles + Teams repartidos.

El cutover de Teams

Teams debe coordinarse con el resto de la experiencia del usuario.

En un proyecto completo puede coincidir con

• cambio de UPN;
• traslado de dominio;
• Exchange mailbox move;
• OneDrive;
• nuevo Teams;
• nuevo tenant;
• cambio de sesión de Office;
• Intune o dispositivo.

El usuario no piensa por workloads

El usuario no va a decir:

“Tengo una incidencia de migración de SharePoint relacionada con una superficie de Teams.”

Dirá:

“No puedo abrir el archivo de mi canal.”

El soporte debe estar preparado para diagnosticar el servicio subyacente.

Cómo validar Teams después de migrar

La validación debería incluir tres niveles.

1. Cuantitativa

2. Técnica

Comprobar:

• errores;
• warning;
• permissions;
• mapping;
• version history;
• links;
• external users;
• apps.

3. Funcional

Un job “Completed” no es una aceptación

Significa que la herramienta ha terminado el proceso que se le pidió.

No significa necesariamente que el usuario tenga exactamente la experiencia definida en el alcance.

Comunicar el cambio a los usuarios

Teams es un producto muy visible.

La comunicación debe explicar las diferencias que realmente percibirá la persona.

Antes del cambio

Informar:

• fecha;
• tenant nuevo;
• qué chats se conservarán;
• qué Teams se migrarán;
• qué Teams se archivarán;
• qué ocurre con reuniones;
• qué ocurre con invitados;
• qué debe hacer el usuario.

Después

Explicar:

• cómo entrar en el tenant correcto;
• dónde buscar Teams;
• qué hacer si falta un Team;
• qué hacer si un link no funciona;
• dónde solicitar soporte.

No ocultar limitaciones conocidas

Es mejor comunicar:

“Determinadas aplicaciones deberán volver a autorizarse”

antes del cambio que dejar que el usuario lo descubra durante una reunión importante.

Errores frecuentes al migrar Microsoft Teams

Checklist para una migración Teams tenant-to-tenant

Preguntas frecuentes sobre migración de Microsoft Teams entre tenants

Conclusión: migrar Teams significa coordinar todo su ecosistema

La migración de Microsoft Teams entre tenants es hoy más viable que hace unos años.

Microsoft ha ampliado las capacidades de Microsoft Graph para importar histórico de chats y canales, incluyendo canales estándar, privados y compartidos, y permitiendo trabajar también con chats 1:1 y grupales.

Migration Orchestrator añade además una capa nativa para coordinar datos personales de usuario como Exchange, OneDrive, Teams Chats y Teams Meetings.

Pero ninguno de estos avances convierte Teams en una única carga fácilmente transportable.

Los Teams y Channels compartidos continúan siendo distintos de los chats privados del usuario. Los documentos dependen de SharePoint y OneDrive. Las reuniones dependen también de Exchange. Los shared channels pueden involucrar relaciones entre organizaciones. Planner y OneNote son servicios independientes. Las aplicaciones pueden depender de App Registrations, permisos y servicios externos.

La primera decisión de un proyecto no debería ser, por tanto:

“Utilizaremos Quest, BitTitan, ShareGate o Microsoft.”

Debería ser:

“Esto es exactamente lo que existe y esto es exactamente lo que necesitamos conservar.”

A partir de ahí podemos determinar qué tecnología encaja.

En algunos proyectos puede bastar con mover estructuras y archivos. En otros, los chats históricos son críticos. Para algunas organizaciones Planner resulta esencial. En otras, la principal dificultad son los canales privados, los invitados o las aplicaciones.

El procedimiento más sólido suele seguir una secuencia clara:

discovery → limpieza → definición de alcance → mapping → selección de herramienta → piloto → premigración → oleadas → cutover → validación → hypercare.

Y hay una última idea especialmente importante:

la migración no debería considerarse terminada cuando la herramienta termina de copiar.

Termina cuando los usuarios pueden entrar en el nuevo tenant, encontrar sus espacios de trabajo, acceder a los documentos que necesitan, consultar el histórico incluido en el alcance, utilizar las aplicaciones requeridas y continuar colaborando con las personas correctas.

Ese debería ser el verdadero criterio de éxito.

Documentación oficial recomendada

Microsoft 365 tenant-to-tenant

• Microsoft – Plan a Microsoft 365 tenant-to-tenant migration
• Microsoft – Migration Orchestrator overview
• Microsoft – Running a Migration with Migration Orchestrator

Microsoft Teams y Graph Migration APIs

• Microsoft Graph – Import messages into Teams chats and channels
• Microsoft Graph – channel: startMigration
• Microsoft Graph – channel: completeMigration
• Microsoft Graph – chat: startMigration
• Microsoft Graph – chat: completeMigration
• Microsoft – Import external messages to Teams

Teams, SharePoint y OneDrive

• Microsoft – File storage in Microsoft Teams
• Microsoft – Cross-tenant OneDrive migration
• Microsoft – Cross-tenant SharePoint migration

Microsoft Purview y Teams

• Microsoft Purview – Find Teams content with eDiscovery

Quest On Demand Migration

• Quest – Microsoft Teams Migration
• Quest – On Demand Migration User Guide

BitTitan MigrationWiz

• BitTitan – Microsoft Teams Migration Guide
• BitTitan – Teams Private Chat Migration Guide

Cloudiway

• Cloudiway – Cross-Tenant Microsoft Teams Migration Guide
• Cloudiway – Teams 1:1 Chat Migration

ShareGate

• ShareGate – Microsoft Teams Migration
• ShareGate – Copy Teams limitations