Migración de Microsoft Teams entre tenants (tenant-to-tenant): guía completa para mover Teams, canales, chats y configuración con el menor impacto

Resumen rápido: migración de Microsoft Teams entre tenants en 11 puntos

1. Empezar por la decisión correcta: en algunos escenarios no conviene migrar todo; puede bastar con coexistencia y colaboración entre tenants (por ejemplo, con canales compartidos) mientras se consolida a medio plazo.
2. Separar “datos de usuario” de “espacios compartidos”: chats y reuniones del usuario van por un lado; equipos/canales/archivos y apps van por otro (y no siempre viajan con el mismo método).
3. Inventario real: número de equipos, canales privados/compartidos, propietarios, invitados, apps, pestañas, automatizaciones, políticas, y (si aplica) voz y call queues.
4. Identidad bien atada: mapeo de usuarios entre tenants, UPN, dominios, y (si hay Teams Phone) plan para SIP/voice.
5. Estrategia de coexistencia: cómo se colabora mientras se migra (externos, invitados, compartición, calendario operativo).
6. Plan para equipos/canales: recreación controlada, nomenclatura, ownership, plantillas y gobierno (quién puede crear qué).
7. Archivos con enfoque SharePoint: los archivos de canales viven en SharePoint y requieren plan de migración propio (incluyendo canales privados y compartidos con su SharePoint “separado”).
8. Apps y pestañas: no asumir que “aparecerán solas”; muchas hay que reconfigurarlas, reautorizar permisos y validar conectores.
9. Chats y reuniones: cuando el cliente lo requiere, valorar capacidades nativas disponibles y/o enfoque alternativo (cumplimiento y exportación) según alcance real.
10. Seguridad y cumplimiento desde el día 1: acceso condicional, control de invitados, etiquetas de sensibilidad/retención y auditoría.
11. Adopción y soporte: comunicación por oleadas, guías por rol, mesa de ayuda reforzada y revisión post-migración (permisos, invitados, enlaces y uso).

¿Cuándo se necesita migrar Microsoft Teams entre tenants?

Una migración de Teams entre tenants suele aparecer cuando la estructura empresarial cambia: dos organizaciones se unen, una parte se separa, o el cliente decide consolidar su colaboración en un único tenant por control, costes o cumplimiento. En esos escenarios, Teams es el “centro de trabajo” diario y, por tanto, cualquier cambio se nota rápido.

Escenarios habituales

• Fusiones y adquisiciones (M&A): dos tenants operando en paralelo, y se busca una experiencia unificada de Teams.
• Carve-out / spin-off: una unidad de negocio se independiza y necesita su propio tenant, conservando parte de la colaboración y documentos.
• Rebranding o cambio de dominio: se reorganizan identidades y se aprovecha para “ordenar” colaboración y gobierno.
• Consolidación histórica: se han ido acumulando tenants y ahora se quiere simplificar operación, seguridad y compliance.
• Exigencia regulatoria: se requiere que el control documental, retención y auditoría se concentre en un tenant con políticas uniformes.

Resumen de esta sección: si Teams es donde se decide, se coordina y se ejecuta el trabajo, una migración tenant-to-tenant afecta a hábitos diarios. Por eso el éxito depende menos de “mover objetos” y más de diseñar una transición que mantenga colaboración, archivos y permisos con lógica.

Antes de migrar: ¿conviene migrar o conviene coexistir?

Migrar es una opción, pero no siempre es la primera que conviene ejecutar. En algunos casos, el cliente obtiene más valor si primero habilita colaboración entre tenants y, cuando el negocio se estabiliza, consolida con menos prisa. Esto es especialmente cierto cuando la organización todavía está definiendo estructura, responsables, procesos y dominios.

Opción A: coexistencia controlada (colaborar entre tenants)

Si el objetivo inmediato es trabajar juntos sin aún “mezclarlo todo”, se puede habilitar colaboración entre tenants:

• Canales compartidos (shared channels): permiten colaborar con personas externas de otro tenant sin convertirlas en invitados tradicionales, cuando se configura B2B Direct Connect.
• Acceso externo y federación: para chat/llamadas entre organizaciones, útil como paso intermedio.
• Invitados (guest access): válido para casos concretos, pero requiere gobierno (expiración, revisión y control de permisos).

Opción B: migración parcial

En un carve-out o reorganización, a menudo no se debe migrar “todo”. Se migran equipos/proyectos concretos, se recrean espacios críticos y se mantiene un periodo de acceso al tenant origen para consultas (con límites y fecha de cierre).

Opción C: migración completa

Cuando la decisión está tomada (un solo tenant como destino), la migración completa tiene sentido si se define con claridad:

• Qué datos deben moverse sí o sí (equipos activos, archivos vivos, procesos operativos).
• Qué se puede archivar o dejar en origen (histórico de proyectos cerrados, chats antiguos sin valor operativo).
• Qué se recrea (políticas, apps, plantillas, gobierno) en el tenant destino.

Resumen de esta sección: antes de invertir esfuerzo en migrar, conviene decidir si el cliente necesita una consolidación inmediata o si es mejor colaborar entre tenants y migrar por fases. Esa decisión reduce riesgo y evita migraciones “a ciegas”.

Qué se migra (y qué no) en una migración de Microsoft Teams entre tenants

Teams mezcla contenido de varios servicios de Microsoft 365. Por eso, la migración se entiende mejor si se descompone en capas. El error típico es pensar que Teams “es una sola cosa” y que todo viaja igual.

La capa 1: espacio compartido (equipo y canales)

Un equipo es un contenedor con miembros, canales, configuración y apps. Al migrar entre tenants, lo más habitual es recrear equipos/canales en destino (con estructura y gobierno) y luego mover o reenganchar lo que corresponda (archivos, pestañas, conectores, etc.).

La capa 2: archivos (SharePoint y OneDrive)

Los archivos compartidos en canales se almacenan en SharePoint, y los canales privados/compartidos pueden tener su propio SharePoint asociado. Esto implica que la migración de archivos es, en realidad, una migración de SharePoint/OneDrive con sus propias reglas (permisos, enlaces, versiones, retención).

La capa 3: conversaciones, chats y reuniones

Aquí hay que ser especialmente realistas: durante años, el mercado ha dependido de herramientas de terceros o enfoques de cumplimiento (exportar para evidencias) para conservar histórico. A cierre de 2025 Microsoft ha anunciado capacidades nativas de migración de datos de usuario que incluyen chats de Teams y migración de reuniones dentro de un enfoque orquestado (según disponibilidad y alcance), pero no cubren “todo lo compartido” como equipos y canales en sí mismos.

La capa 4: voz (Teams Phone) y telefonía

Si el cliente usa Teams Phone, hay otro conjunto de elementos que planificar: números, asignaciones, rutas, operadores, colas de llamada, IVR, emergencia (E911 donde aplique) y convivencia temporal con el entorno origen.

Resumen de esta sección: Teams tenant-to-tenant se ejecuta mejor cuando se separa: (1) estructura de colaboración, (2) archivos, (3) datos de usuario (chats/reuniones) y (4) voz. Cada capa tiene dependencias y “puntos de rotura” distintos.

1. Metodología por oleadas y gobierno del proyecto (Teams tenant-to-tenant)

La migración de Microsoft Teams entre tenants se beneficia de un enfoque por oleadas: un piloto representativo, oleadas progresivas y una fase de estabilización. Esto permite aprender con impacto limitado y reducir el volumen de incidencias cuando se escala.

1.1 Roles claros y decisiones por adelantado

Si no se define quién decide (negocio) y quién ejecuta (IT), aparecen bloqueos: equipos sin propietario, invitados sin control, o discusiones sobre si un canal “era público o privado” cuando ya es tarde. Funciona bien acordar:

• Propiedad: cada equipo debe tener propietarios de negocio y un responsable de gobierno (no necesariamente técnico).
• Nomenclatura: cómo se nombran equipos/canales y qué significa cada prefijo (área, país, proyecto).
• Política de creación: quién puede crear equipos y cuándo se solicita uno nuevo.
• Periodo de coexistencia: cuánto tiempo se mantendrá acceso al tenant origen y con qué límites.

1.2 Comunicación y soporte como parte del plan

Teams es visible. Si un lunes “faltan equipos”, el negocio lo nota al minuto. Por eso la comunicación no es un añadido, es parte del diseño:

• Calendario por oleadas con qué cambia y cuándo.
• Guías cortas por rol: usuario estándar, propietario de equipo, soporte interno.
• Mesa de ayuda reforzada la primera semana tras cada oleada (y métricas de incidencias).

Resumen de esta sección: oleadas + gobierno + comunicación convierten la migración en un proceso repetible. Sin eso, Teams se convierte en una lista interminable de casos “especiales”.

2. Assessment: inventario, dependencias y puntos sensibles

Un assessment serio evita la típica situación de “pensábamos que solo eran equipos y canales”. En Teams, el inventario debe incluir no solo cuántos equipos existen, sino cómo se usan y qué depende de ellos.

2.1 Inventario mínimo recomendado

• Equipos y canales: número, propietarios, canales privados/compartidos, archivados, plantillas.
• Miembros e invitados: quién es externo, qué proyectos están abiertos a terceros, y si hay invitados “huérfanos”.
• Archivos y SharePoint asociado: volumen, bibliotecas, permisos rotos, enlaces compartidos.
• Apps y pestañas: Planner, Lists, OneNote, apps de terceros, conectores, bots, apps internas.
• Políticas: mensajería, reuniones, apps, grabación, retención, configuración de invitados.
• Voz (si aplica): números, direct routing / operator connect / calling plans, colas, auto attendants, policies de voz.

2.2 Identificar “equipos críticos”

No todos los equipos pesan lo mismo. Se recomienda identificar los que soportan operación diaria: soporte, operaciones, ventas, dirección, proyectos en fase final, etc. En esos equipos suele ser clave:

• Que los propietarios estén disponibles para validar.
• Que los archivos queden accesibles desde el primer día.
• Que las apps/pestañas esenciales sigan funcionando.

Resumen de esta sección: el assessment no se limita a contar equipos; debe descubrir dependencias: apps, archivos, invitados, voz y políticas. Esto define oleadas y reduce sorpresas.

3. Identidad y acceso: Entra ID, mapeo de usuarios y coexistencia

La migración de Teams entre tenants depende de que el usuario “sea el usuario correcto” en destino: misma persona, mismo rol, permisos coherentes, y un acceso que no obligue a soluciones improvisadas. Aquí entran Entra ID, la configuración cross-tenant y, en algunos casos, sincronización entre tenants.

3.1 Cross-tenant access y sincronización (cuando aplica)

Para coexistencia y colaboración entre tenants, se suele configurar cross-tenant access y, si se necesita automatizar provisión de usuarios externos, cross-tenant synchronization. Esto ayuda a controlar atributos, acceso y ciclo de vida en escenarios de colaboración prolongada.

• Definir qué tenant confía en cuál, y con qué condiciones.
• Controlar acceso con políticas (por ejemplo, exigir MFA o dispositivos compatibles).
• Evitar “invitados eternos” mediante revisiones y expiración.

3.2 Mapeo de usuarios (source → target)

En tenant-to-tenant, el mapeo de identidades debe definirse antes de migrar contenido. Preguntas que conviene cerrar:

• ¿Se mantiene el mismo dominio principal o se cambia (rebranding)?
• ¿Se unifica UPN y correo, o habrá alias temporales?
• ¿Cómo se gestionan grupos, propietarios de equipos y accesos a SharePoint?

3.3 Coexistencia operativa: qué se permite y qué no

Durante coexistencia, el cliente suele necesitar reglas claras:

• Qué tipo de colaboración se permite con externos (invitados vs canales compartidos).
• Cómo se comparten archivos (evitar enlaces públicos o sin caducidad cuando no proceda).
• Qué ocurre con los equipos “duplicados” (uno en origen y otro en destino) y cómo se evita que el trabajo se divida.

Resumen de esta sección: si la identidad y la coexistencia no están bien definidas, la migración termina siendo una colección de excepciones. El mapeo de usuarios y las reglas de colaboración se deciden antes de mover nada.

4. Migración nativa de datos de usuario (Teams chats y reuniones) con Migration Orchestrator

Contexto importante: en Teams, “lo más difícil” históricamente ha sido conservar chats y reuniones de forma nativa. A cierre de 2025, Microsoft ha presentado un enfoque orquestado para migraciones cross-tenant que incluye datos de usuario de Teams (según alcance y disponibilidad).

Microsoft ha introducido Migration Orchestrator para unificar y coordinar migraciones cross-tenant de datos de usuario. En este enfoque, Teams se trata como parte del “paquete” de datos del usuario: chats y migración de reuniones (con dependencias claras respecto al correo/calendario).

4.1 Qué cubre (y qué no cubre)

Es clave entender el alcance:

• En alcance (datos del usuario): chats de Teams y reuniones (en el contexto de la migración orquestada).
• Fuera de alcance (contenido compartido): equipos, canales y datos compartidos como sitios de SharePoint “del equipo” no se migran como parte de “datos del usuario”.

Dicho de forma sencilla: Orchestrator ayuda con “mi historial como persona”, pero el “espacio del equipo” y su contenido requieren plan paralelo.

4.2 Dependencia crítica: correo/calendario y reuniones

En migraciones donde se pretende mover reuniones, conviene tener en cuenta que el calendario es parte de la experiencia. Si el cliente migra buzones, el orden y las validaciones importan. En el enfoque orquestado, la migración de reuniones se ejecuta con dependencias del movimiento del buzón y su estado.

4.3 Preparación práctica (qué suele fallar si no se cuida)

• Usuarios ya aprovisionados en destino: si el usuario destino ya tiene OneDrive/buzón aprovisionados y no coincide con el mapeo esperado, aparecen conflictos.
• Licencias y habilitación de Teams: el usuario debe estar habilitado para Teams en destino; en escenarios con voz, hay implicaciones de SIP y configuración.
• Permisos de apps de migración: la configuración de tenants requiere consentimientos y roles específicos.

4.4 Experiencia de usuario (qué notará el usuario final)

En una migración cross-tenant bien planificada, el objetivo es que el usuario tenga un “punto de cambio” claro: a partir de una fecha, el trabajo diario ocurre en el tenant destino. Aun así, es normal que el usuario note:

• Cambio de cuenta/tenant en el cliente de Teams (y en móvil).
• Reuniones reprogramadas o ajustes en invitaciones según el enfoque de migración de reuniones.
• Revalidación de acceso a algunas apps/pestañas si dependen de consentimientos del tenant.

Resumen de esta sección: Orchestrator mejora el escenario de migración de datos de usuario (chats y reuniones) pero no sustituye el trabajo de migrar/recrear equipos, canales, archivos y apps. El éxito está en coordinar ambos caminos.

5. Migrar equipos y canales de Microsoft Teams entre tenants

Los equipos y canales son la “estructura” donde vive el trabajo. En tenant-to-tenant, lo habitual es:

• Definir qué equipos se migran, cuáles se consolidan (dos equipos similares → uno), y cuáles se archivan.
• Recrear la estructura (equipos/canales) en el tenant destino con gobierno y naming.
• Reasignar propietarios y miembros por grupos (no por usuarios sueltos).

5.1 Cómo decidir la estructura destino (sin copiar errores del origen)

Migrar es buen momento para simplificar. Ejemplos de decisiones que suelen ayudar:

• Limitar equipos “por persona” o equipos duplicados por departamento sin propósito claro.
• Separar equipos internos de equipos de colaboración externa (por cliente/proveedor/proyecto).
• Reducir el número de propietarios por equipo, pero asegurar que siempre haya más de uno.

5.2 Canales privados y compartidos: plan específico

Canales privados y compartidos no son “un canal más”: tienen implicaciones de membresía y almacenamiento (SharePoint dedicado). Si el cliente los usa, conviene:

• Inventariarlos y justificar su necesidad (muchas veces se han creado por falta de gobierno).
• Decidir si se mantienen como privados/compartidos o se rediseñan.
• Planificar su SharePoint asociado en la migración de archivos.

5.3 Enfoques típicos (manual, PowerShell, terceros)

Para estructura (equipos/canales/membresía), hay tres enfoques habituales:

• Manual controlado: viable si hay pocos equipos críticos. Más lento, pero permite depurar estructura.
• Automatización (PowerShell/Graph): útil si hay muchos equipos, siempre que se tenga claro el modelo destino y el mapeo de usuarios.
• Herramientas de terceros: aportan mapeo, reporting, reintentos y paneles; suelen ser útiles en entornos grandes o con plazos ajustados.

Resumen de esta sección: equipos y canales se tratan como estructura. La migración no debería “clonar desorden”; debería recrear con un modelo más claro, cuidando canales privados/compartidos y ownership.

6. Migrar archivos de Teams: SharePoint detrás de los canales (el punto que más trabajo ahorra si se hace bien)

Muchos problemas atribuidos a “Teams” son en realidad problemas de SharePoint: enlaces rotos, permisos mal heredados, bibliotecas caóticas o exceso de compartición. Esto se entiende con una regla simple: los archivos de un canal estándar viven en SharePoint. Y los canales privados/compartidos pueden tener un SharePoint dedicado.

6.1 Enfoque recomendado para archivos

1. Inventariar el SharePoint asociado: sitios conectados a Teams, bibliotecas, permisos, compartición externa.
2. Definir estructura destino: qué se mantiene, qué se consolida, qué se archiva.
3. Migrar por oleadas: priorizar equipos críticos y proyectos activos.
4. Validar enlaces y accesos: especialmente si hay colaboración externa.

6.2 Canales privados y compartidos: por qué requieren más cuidado

En canales privados y compartidos, el almacenamiento se separa del equipo principal. Esto afecta a:

• Permisos (membresía distinta al equipo).
• SharePoint asociado (sitio distinto, gobierno distinto).
• Compartición externa (en el caso de compartidos, participación externa con reglas específicas).

6.3 Qué suele romperse si no se planifica

• Enlaces compartidos: si se cambia de tenant, los enlaces antiguos pueden dejar de ser válidos o perder contexto.
• Permisos “a mano”: si había permisos por usuario, la recertificación se vuelve lenta.
• Duplicidad: el mismo archivo termina en dos ubicaciones (origen y destino) y el equipo no sabe cuál es la “buena”.

Resumen de esta sección: migrar Teams sin tratar SharePoint con seriedad lleva a incidencias repetidas. Los archivos son un proyecto dentro del proyecto: inventario, destino, oleadas y validación.

7. Apps, pestañas, conectores y bots en una migración de Teams entre tenants

Las apps son donde suelen aparecer sorpresas: una pestaña que “ya no carga”, un conector que deja de publicar, o una app interna que dependía de permisos del tenant origen. En tenant-to-tenant conviene tratar apps como una carga con su propio plan.

7.1 Inventario de apps por criticidad

Se recomienda separar:

• Apps básicas y estándar: Planner, Lists, OneNote, Forms, Power BI (dependen de configuración y permisos, pero suelen ser recuperables).
• Apps de terceros: requieren revisión de licencias, configuración y, a veces, reinstalación y reautorización.
• Apps internas (custom): suelen depender de Azure AD/Entra ID, App Registrations, APIs y consentimientos.

7.2 Consentimientos y seguridad

Una app que funcionaba en el tenant origen puede no funcionar en destino si:

• Faltan consentimientos de administrador.
• Se han restringido apps por política (lo cual puede ser deseable, pero hay que planificarlo).
• Ha cambiado la identidad del usuario o los endpoints de servicios (por ejemplo, URLs, entornos Power Platform).

7.3 Pestañas y enlaces (expectativas realistas)

Muchas pestañas son “vistas” a un recurso externo (SharePoint, web, Power BI, etc.). En migración, la pestaña puede seguir existiendo, pero apuntar a una URL antigua. Por eso conviene:

• Planificar actualización de pestañas para recursos migrados (SharePoint/Power BI).
• Validar con un piloto: abrir, editar y comprobar permisos reales, no solo “que se ve”.

Resumen de esta sección: apps y pestañas no se “heredan” mágicamente entre tenants. El cliente necesita inventario, reconfiguración y validación, especialmente para apps internas o de terceros.

8. Teams Phone (voz) en tenant-to-tenant: números, rutas y call flows

Si el cliente usa Teams como centralita o telefonía corporativa, la migración incluye otra capa de complejidad: números, asignaciones, políticas de voz, rutas y call flows (auto attendants y call queues). La clave es tratarlo como un subproyecto con ventana controlada.

8.1 Lo primero: qué modelo de PSTN usa el cliente

• Calling Plans (Microsoft): números y portabilidad gestionados en Teams Admin Center (según país/región).
• Operator Connect: operador homologado integra PSTN; migración y movimientos dependen del operador y del tenant.
• Direct Routing: SBC propio o del carrier; implica configuración de rutas, trunk y políticas en el tenant destino.

8.2 Plan de números: movimiento/portabilidad y asignación

En la práctica, mover números entre tenants suele requerir coordinación con Microsoft y/o con el operador. El plan debe contemplar:

• Desasignación controlada en origen (para poder mover/portar).
• Alta y validación en destino (números disponibles y asignables).
• Reasignación por oleadas si hay muchos usuarios o sedes.

8.3 Call queues, auto attendants y reglas de negocio

Las colas y asistentes automáticos se reconstruyen en destino: horarios, desvíos, saludos, música en espera, grupos de agentes, y reglas por festivos. Aquí es donde se agradece tener documentación previa o exportaciones de configuración.

8.4 Emergencia (E911) y requisitos locales

En países/regiones con requisitos de localización para emergencias, conviene revisar cómo se configuran ubicaciones, políticas y direcciones en el tenant destino antes de mover usuarios de voz.

Resumen de esta sección: voz no se improvisa. Requiere inventario, coordinación con operador/Microsoft y una ventana de cambio con pruebas de llamadas. En tenant-to-tenant, es normal recrear configuración y reasignar números con control.

9. Seguridad y cumplimiento en Teams tenant-to-tenant: invitados, Acceso Condicional y Microsoft Purview

Una migración es un momento perfecto para corregir “deudas” de seguridad: invitados sin control, compartición demasiado abierta, políticas inconsistentes y ausencia de clasificación de información. Si el cliente consolida a un tenant destino, conviene endurecerlo desde el inicio.

9.1 Invitados, externos y canales compartidos

• Políticas por tipo de colaboración: no todo debe permitirse en todos los equipos.
• Revisión periódica: invitados por proyecto, con fecha de cierre y limpieza.
• Acceso Condicional: exigir MFA, limitar acceso desde dispositivos no conformes o ubicaciones de riesgo, cuando aplique.

9.2 Microsoft Purview para Teams

Para sectores regulados o equipos con datos sensibles, Purview aporta herramientas que conviene integrar en el plan:

• Retención: conservar conversaciones o contenidos según política interna o legal.
• eDiscovery: preservar, buscar y exportar contenido de Teams cuando hay casos legales, auditorías o investigaciones internas.
• DLP: reducir fugas de información (por ejemplo, bloquear compartición de archivos sensibles), con enfoque gradual.

9.3 Auditoría y trazabilidad

En tenant-to-tenant se recomienda confirmar que auditoría y registros relevantes están habilitados en destino, y que existe procedimiento de respuesta ante incidentes:

• Quién revisa alertas y actividad anómala.
• Qué ocurre si se detecta compartición indebida.
• Cómo se bloquea acceso o se revocan sesiones ante riesgo.

Resumen de esta sección: seguridad y cumplimiento no son “después de migrar”. En Teams, invitados, compartición y Purview deben definirse antes de abrir el entorno destino a toda la organización.

10. Experiencia de usuario y adopción: qué cambia y cómo reducir fricción

El usuario final no quiere saber “qué API se ha usado”; quiere saber dónde está su equipo, dónde están sus archivos y si las reuniones funcionan. Por eso conviene traducir la migración a impactos claros por rol.

10.1 Qué suele cambiar para el usuario

• Cuenta y tenant: puede requerir cerrar sesión e iniciar en el nuevo tenant (desktop/móvil).
• Equipos y canales: nuevos equipos en destino, con estructura más limpia; los antiguos quedan en modo consulta o cerrados.
• Archivos: se accede a través de pestaña Archivos del canal (que en realidad apunta a SharePoint del tenant destino).
• Reuniones: pueden cambiar enlaces o requerir reprogramación según estrategia acordada.
• Apps: algunas requieren volver a autorizar o iniciar sesión de nuevo.

10.2 Material mínimo que reduce tickets

• Guía “primer día”: cómo cambiar de tenant, dónde encontrar equipos, cómo buscar archivos.
• Guía para propietarios: cómo gestionar miembros, invitados, y cómo pedir un canal privado/compartido si se permite.
• FAQ real basada en piloto: permisos, acceso móvil, enlaces, pestañas, reuniones.

10.3 Mesa de ayuda y estabilización

Los primeros días tras una oleada, conviene registrar incidencias con categorías claras:

• Acceso (login, MFA, tenant equivocado).
• Permisos (no veo el equipo/canal/archivo).
• Apps/pestañas (no carga, permisos, licencias).
• Reuniones (enlaces, calendario, audio).

Resumen de esta sección: adopción no es “formación genérica”. Es explicar impactos concretos y sostener al usuario durante el cambio. Un piloto bien elegido mejora mucho el material y reduce incidencias.

11. Rendimiento, límites y escalabilidad

En migraciones grandes, el rendimiento no es solo ancho de banda: hay límites de servicio, ventanas de trabajo y dependencia de APIs. Por eso conviene:

• Trabajar por oleadas con grupos de validación.
• Planificar ventanas de cambio en horarios de menor impacto.
• Usar reporting para saber “qué falta” y no depender de sensaciones.

11.1 Evitar automatizaciones “a fuerza bruta”

Cuando se intentan “migraciones caseras” de mensajes usando APIs no pensadas para ello, el rendimiento y la fiabilidad se resienten. En general, para conversaciones históricas se debe usar el enfoque soportado (cuando exista) o herramientas que usen APIs de migración específicas, en lugar de APIs estándar de envío.

11.2 Señales de que el entorno está escalando bien

• Los propietarios de equipos entienden su rol y gestionan miembros por grupos.
• La creación de equipos/canales sigue un proceso simple y visible.
• La colaboración externa está contenida (no hay “aperturas” masivas).
• Los archivos se encuentran desde Teams sin que el usuario “salte” a múltiples ubicaciones.

Resumen de esta sección: rendimiento y escalabilidad dependen de oleadas, límites de servicio y buen gobierno. Si el cliente fuerza automatización sin enfoque soportado, el riesgo sube y el resultado empeora.

12. Checklists operativos (pre, durante, post) para migración de Microsoft Teams entre tenants

12.1 Antes de migrar (diseño y preparación)

• Inventario de equipos/canales (incluyendo privados/compartidos) y “equipos críticos”.
• Inventario de SharePoint asociado y estrategia de migración de archivos.
• Inventario de apps/pestañas y plan de reconfiguración/consentimientos.
• Definición de modelo destino: naming, owners, política de creación, y gobierno de invitados.
• Plan de coexistencia: cómo se colabora entre tenants hasta cierre del origen.
• Seguridad: acceso condicional, políticas de invitación, y baseline de Purview si aplica.
• Si hay voz: inventario de números/call flows y coordinación con operador/Microsoft.

12.2 Durante la migración (ejecución por oleadas)

• Crear/recrear equipos y canales en destino con owners correctos.
• Migrar archivos del equipo/canales (SharePoint) según oleada.
• Reconfigurar apps/pestañas críticas y validar permisos.
• Validación con negocio (UAT) y checklist de “funciona lo diario”.
• Comunicación al grupo afectado: qué cambia, dónde ir, cómo pedir soporte.

12.3 Después (estabilización)

• Revisión de invitados y accesos externos; limpieza inicial si procede.
• Recertificación de permisos en equipos sensibles.
• Medición de incidencias por categoría y mejoras de guías.
• Decisión de cierre del tenant origen (o paso a solo lectura con fecha final).

Resumen de esta sección: el checklist convierte la migración en algo repetible. La diferencia entre un cambio “llevadero” y uno caótico suele estar en validar por oleadas y no dejar apps/archivos para el final.

13. KPIs y validación con negocio (UAT) en Teams tenant-to-tenant

En Teams, el éxito se mide en productividad real: ¿la gente encuentra su equipo?, ¿puede abrir archivos?, ¿las reuniones funcionan?, ¿las apps críticas cargan? Definir KPIs reduce discusiones posteriores y ayuda a tomar decisiones rápidas.

UAT debería probar escenarios reales del negocio: atender un ticket, coordinar un cierre mensual, compartir un archivo con proveedor, organizar una reunión con externos, etc.

Resumen de esta sección: KPIs y UAT bajan el riesgo porque convierten “parece que está bien” en pruebas verificables. En Teams, eso reduce incidencias y acelera estabilización.

14. Scripts y snippets útiles (PowerShell) para Teams tenant-to-tenant

Estos ejemplos no sustituyen el diseño ni las herramientas soportadas, pero ayudan a inventariar y estandarizar acciones. En migraciones reales, lo más útil suele ser inventario y control (qué existe, quién es owner, qué se ha recreado).

# Requiere módulos y permisos adecuados
# Microsoft Graph es una vía habitual para inventario de M365 Groups/Teams

Connect-MgGraph -Scopes "Group.Read.All","Directory.Read.All"
$groups = Get-MgGroup -All -Filter "resourceProvisioningOptions/Any(x:x eq 'Team')"
$groups | Select-Object DisplayName, Id, Mail, Visibility

Connect-MicrosoftTeams
Get-CsOnlineUser -Identity "usuario@empresa.com" | Select DisplayName, TeamsUpgradePolicy, OnlineVoiceRoutingPolicy

Connect-MicrosoftTeams
$newTeam = New-Team -DisplayName "PROY-ClienteX" -MailNickname "proy-clientex" -Visibility Private
New-TeamChannel -GroupId $newTeam.GroupId -DisplayName "General"

Resumen de esta sección: scripts ayudan a inventariar y recrear estructura. Para “histórico”, conviene usar enfoques soportados por Microsoft o herramientas especializadas, no automatizaciones improvisadas.

15. Preguntas frecuentes (FAQ) sobre migración de Microsoft Teams entre tenants

16. Recursos oficiales y enlaces recomendados

• Migration Orchestrator (Microsoft Learn)
• Anuncio y contexto de migración cross-tenant con Orchestrator
• Teams y canales: relación con SharePoint y tipos de canales
• eDiscovery para contenido de Microsoft Teams
• FastTrack: cross-tenant migration
• Portabilidad y transferencia de números (Teams)
• Operator Connect: configuración y migración de números

Servicios relacionados de MSAdvance: Modern Workplace (Microsoft 365), Seguridad y cumplimiento (Purview) y Servicios.

Resumen de esta sección: los recursos oficiales ayudan a validar alcance real. Para evitar expectativas erróneas, conviene basar el plan en documentación soportada por Microsoft y complementar con herramientas/servicios solo cuando aportan valor claro.

17. Conclusión: cómo ejecutar una migración de Microsoft Teams entre tenants sin perder el control

Una migración de Microsoft Teams entre tenants es un proyecto de colaboración, información y seguridad. Sale bien cuando el cliente separa capas (estructura, archivos, datos del usuario, voz), define gobierno y ejecuta por oleadas con validación real.

Como siguientes pasos, suele ser útil:

• Realizar un assessment (equipos/canales, SharePoint asociado, apps, invitados, políticas y voz).
• Decidir estrategia: coexistencia, migración parcial o consolidación completa, con calendario por oleadas.
• Definir modelo destino (naming, owners, creación de equipos, externos) y preparar seguridad/compliance.
• Ejecutar piloto, ajustar guías y escalar con soporte reforzado.