Herramientas, scripts y formas de migrar entre tenants de Microsoft 365: guía completa para elegir el mejor enfoque

Resumen rápido: cómo elegir herramientas para migrar entre tenants de Microsoft 365

1. No existe una herramienta única perfecta: Exchange, OneDrive, SharePoint, Teams, Planner, Power Platform e identidad tienen límites y métodos distintos.
2. Exchange Online tiene una vía nativa sólida: la migración de buzones cross-tenant se apoya en Exchange Online PowerShell, lotes y requisitos previos entre tenants.
3. OneDrive y SharePoint tienen capacidades cross-tenant: útiles para mover contenido, pero requieren planificación, compatibilidad, mapeo de usuarios y validación de permisos.
4. Teams es más delicado: archivos, canales, miembros, pestañas, reuniones, chats y apps no se comportan igual; muchas migraciones requieren terceros o reconstrucción controlada.
5. Entra ID es la base de la coexistencia: cross-tenant access, B2B y cross-tenant synchronization ayudan a que los usuarios colaboren mientras la migración avanza.
6. Los scripts son imprescindibles: inventario, mapeo, validación, reporting y reintentos suelen automatizarse con PowerShell, Microsoft Graph y módulos de administración.
7. Las herramientas de terceros aportan velocidad y trazabilidad: ShareGate, Quest, BitTitan, Cloudiway, AvePoint y otras soluciones pueden reducir trabajo manual y mejorar reporting.
8. El rendimiento no depende solo de la herramienta: influyen tamaño de buzones, número de archivos, throttling, ventanas de trabajo, red, permisos, retención y salud del tenant.
9. La coexistencia evita interrupciones: correo, calendarios, colaboración externa y dominios deben diseñarse antes del primer lote.
10. El éxito se mide con usuarios trabajando: no basta con mover datos; hay que validar Outlook, Teams, OneDrive, permisos, reuniones, móviles y soporte.

¿Cuándo se necesita una migración entre tenants de Microsoft 365?

Una migración entre tenants de Microsoft 365 suele aparecer cuando una organización necesita consolidar, separar o reorganizar entornos. Puede ser una fusión, una adquisición, una escisión, un cambio de dominio corporativo o una decisión de gobierno para reducir varios tenants históricos a uno solo.

Escenarios habituales

• Fusiones y adquisiciones: dos organizaciones se integran y se quiere unificar correo, archivos, Teams, seguridad y dominios.
• Carve-out o separación de negocio: una unidad se independiza y necesita su propio tenant con usuarios, datos y permisos.
• Consolidación de tenants: empresas con varios tenants heredados buscan reducir complejidad, licencias y administración.
• Rebranding o cambio de dominio: el dominio principal cambia y se aprovecha para reorganizar identidades y servicios.
• Cambio de partner o arquitectura: se rediseña Microsoft 365, Entra ID, seguridad y colaboración desde una base más limpia.
• Unificación de seguridad y cumplimiento: se quiere aplicar una política común de MFA, Acceso Condicional, Purview, Defender y retención.

Introducción: por qué una migración tenant-to-tenant es más que copiar datos

Microsoft 365 no es una sola aplicación. Es un ecosistema formado por identidad, correo, archivos, colaboración, seguridad, cumplimiento, dispositivos y automatizaciones. Por eso, una migración Office 365 tenant-to-tenant exige entender dependencias: un equipo de Teams tiene un grupo de Microsoft 365, un sitio de SharePoint, miembros, propietarios, archivos, pestañas, reuniones y permisos. Un usuario tiene buzón, OneDrive, MFA, dispositivos, grupos, aplicaciones y permisos sobre datos compartidos.

La herramienta elegida importa, pero no sustituye al diseño. Una plataforma de terceros puede acelerar mucho el trabajo, pero si no existe un buen mapa de usuarios, permisos, dominios y cargas de trabajo, también migrará el desorden. Del mismo modo, una migración nativa puede ser muy robusta, pero exige más scripting, coordinación y validación.

La clave está en elegir bien: nativo cuando aporta estabilidad y control, terceros cuando hace falta trazabilidad y velocidad, y scripts cuando conviene automatizar lo repetitivo. En proyectos reales, lo habitual es una combinación.

1. Formas de migrar entre tenants de Microsoft 365

En la práctica: hay cuatro enfoques: nativo, terceros, mixto o reconstrucción controlada. La elección depende del alcance, el riesgo y el tiempo disponible.

Big bang vs migración por oleadas

El corte único puede parecer más sencillo, pero aumenta el riesgo. En entornos con muchos usuarios, varios países, datos críticos o alta dependencia del correo, lo más sensato suele ser trabajar por oleadas: piloto, primera oleada controlada, oleadas por departamento y corte final de dominio.

• Big bang: menos tiempo de coexistencia, más presión en el corte.
• Oleadas: más control, más aprendizaje, mejor soporte a usuarios.
• Híbrido: se precargan datos por oleadas, pero se mueve el dominio en una ventana única.

2. Herramientas nativas de Microsoft por carga de trabajo

En la práctica: las capacidades nativas son la primera opción a revisar, pero no siempre cubren todo el proyecto.

3. Herramientas de terceros: comparativa y cuándo usarlas

En la práctica: las herramientas de terceros no son “mejores” por defecto, pero ayudan mucho cuando hay volumen, presión de tiempo o necesidad de reporting.

ShareGate

ShareGate suele encajar muy bien cuando la migración tiene mucho peso en SharePoint Online, Teams y OneDrive. Su valor no está solo en mover contenido, sino en entenderlo: detectar permisos rotos, sitios inactivos, bibliotecas muy grandes, propietarios ausentes y estructuras que conviene rediseñar antes de copiar.

• Fortalezas: análisis previo, mapeo de permisos, informes claros y buena experiencia para equipos IT.
• Limitaciones: no es la herramienta principal para buzones de Exchange.
• Cuándo usarla: intranets, sitios departamentales, Teams con mucha documentación y migraciones donde se quiere limpiar.

Quest On Demand Migration

Quest On Demand Migration suele aparecer en programas grandes, especialmente en fusiones y adquisiciones. Aporta una visión de proyecto: usuarios, oleadas, progreso por carga, coexistencia, incidencias y reporting ejecutivo. Es útil cuando varias áreas quieren ver estado y riesgos sin entrar en comandos PowerShell.

• Fortalezas: cobertura amplia, dashboards, planificación por oleadas, reporting y coexistencia.
• Limitaciones: requiere presupuesto y configuración cuidada.
• Cuándo usarla: proyectos medianos o grandes con muchas cargas, dirección involucrada y necesidad de trazabilidad.

BitTitan MigrationWiz

MigrationWiz es conocida por su rapidez de puesta en marcha y por ser una plataforma SaaS muy orientada a ejecución. Puede ser una buena opción cuando se quiere mover correo o documentos con un modelo claro, sin desplegar infraestructura propia y con una curva de entrada razonable.

• Fortalezas: velocidad, simplicidad, automatización y proyectos cloud-to-cloud.
• Limitaciones: no siempre es la mejor opción para rediseños profundos de SharePoint o Teams.
• Cuándo usarla: proyectos con alcance acotado, tiempos ajustados y foco en correo/documentos.

Cloudiway

Cloudiway destaca cuando la migración no es solo Microsoft 365 a Microsoft 365. Si hay Google Workspace, Slack, Box u otros orígenes, una plataforma multi-suite puede ahorrar mucho trabajo de integración y mapeo.

• Fortalezas: conectores heterogéneos, escenarios multi-plataforma y flexibilidad.
• Limitaciones: exige más diseño de mapeos y pruebas.
• Cuándo usarla: fusiones con diferentes suites, migraciones desde Google o Slack y proyectos con coexistencia compleja.

4. Matriz de decisión: nativo, terceros o enfoque mixto

En la práctica: el método correcto es el que reduce riesgo y coste total, no necesariamente el que parece más barato al principio.

5. Assessment previo: inventario, dependencias y mapeos

En la práctica: cuanto mejor es el inventario, menos sorpresas aparecen en el corte.

Antes de elegir herramienta, hay que saber qué se va a mover. Parece obvio, pero muchas migraciones empiezan con datos incompletos: usuarios que ya no existen, buzones compartidos sin dueño, sitios sin propietario, Teams abandonados, reglas de transporte antiguas, conectores olvidados o automatizaciones críticas que dependen de una cuenta personal.

Mapeos imprescindibles

• Usuario origen → usuario destino.
• UPN origen → UPN destino.
• SMTP origen → SMTP destino.
• OneDrive origen → OneDrive destino.
• Sitio SharePoint origen → sitio destino.
• Equipo Teams origen → equipo destino o reconstrucción.
• Grupo origen → grupo destino.

6. Scripts PowerShell útiles para migraciones tenant-to-tenant

En la práctica: los scripts no sustituyen a la herramienta de migración, pero hacen que el proyecto sea repetible, auditable y más seguro.

Los siguientes ejemplos son plantillas orientativas. Deben adaptarse al tenant, permisos, módulos vigentes, convenciones de nombres, estrategia de autenticación y políticas de seguridad de cada organización.

6.1 Inventario de usuarios con Microsoft Graph PowerShell

Connect-MgGraph -Scopes "User.Read.All","Group.Read.All","Directory.Read.All"

Get-MgUser -All -Property Id,DisplayName,UserPrincipalName,Mail,AccountEnabled |
  Select-Object Id,DisplayName,UserPrincipalName,Mail,AccountEnabled |
  Export-Csv ".\inventario-usuarios.csv" -NoTypeInformation -Encoding UTF8

Get-MgGroup -All -Property Id,DisplayName,Mail,MailEnabled,SecurityEnabled |
  Select-Object Id,DisplayName,Mail,MailEnabled,SecurityEnabled |
  Export-Csv ".\inventario-grupos.csv" -NoTypeInformation -Encoding UTF8

6.2 Inventario básico de Exchange Online

Connect-ExchangeOnline

Get-EXOMailbox -ResultSize Unlimited |
  Select-Object DisplayName,UserPrincipalName,PrimarySmtpAddress,RecipientTypeDetails |
  Export-Csv ".\inventario-buzones.csv" -NoTypeInformation -Encoding UTF8

Get-DistributionGroup -ResultSize Unlimited |
  Select-Object DisplayName,PrimarySmtpAddress,ManagedBy |
  Export-Csv ".\inventario-distribution-groups.csv" -NoTypeInformation -Encoding UTF8

Get-Mailbox -ResultSize Unlimited |
  Get-MailboxPermission |
  Where-Object { $_.User -notlike "NT AUTHORITY\SELF" } |
  Export-Csv ".\permisos-buzones.csv" -NoTypeInformation -Encoding UTF8

6.3 Seguimiento de lotes de migración de Exchange

Connect-ExchangeOnline

Get-MigrationBatch |
  Select-Object Identity,Status,TotalCount,ActiveCount,StoppedCount,FailedCount |
  Format-Table -AutoSize

Get-MigrationUser -ResultSize Unlimited |
  Get-MigrationUserStatistics -IncludeReport |
  Select-Object Identity,Status,PercentComplete,ItemsTransferred,BytesTransferred,ErrorSummary |
  Export-Csv ".\estado-migracion-exchange.csv" -NoTypeInformation -Encoding UTF8

6.4 Inventario de OneDrive y SharePoint

Connect-SPOService -Url "https://contoso-admin.sharepoint.com"

Get-SPOSite -Limit All -IncludePersonalSite $true |
  Select-Object Url,Owner,Template,StorageUsageCurrent,LastContentModifiedDate |
  Export-Csv ".\inventario-sharepoint-onedrive.csv" -NoTypeInformation -Encoding UTF8

6.5 Inventario de Teams y miembros

Connect-MicrosoftTeams

$teams = Get-Team
$teams | Select-Object GroupId,DisplayName,Visibility,Archived |
  Export-Csv ".\inventario-teams.csv" -NoTypeInformation -Encoding UTF8

foreach ($team in $teams) {
  Get-TeamUser -GroupId $team.GroupId |
    Select-Object @{Name="Team";Expression={$team.DisplayName}},User,Role |
    Export-Csv ".\miembros-teams.csv" -Append -NoTypeInformation -Encoding UTF8
}

6.6 Detección de Teams sin propietarios suficientes

Connect-MicrosoftTeams

$report = foreach ($team in Get-Team) {
  $owners = Get-TeamUser -GroupId $team.GroupId -Role Owner
  [PSCustomObject]@{
    TeamName = $team.DisplayName
    GroupId = $team.GroupId
    Owners = ($owners.User -join ";")
    OwnerCount = $owners.Count
  }
}

$report | Where-Object { $_.OwnerCount -lt 2 } |
  Export-Csv ".\teams-con-pocos-propietarios.csv" -NoTypeInformation -Encoding UTF8

6.7 Plantilla de CSV de mapeo

SourceUPN,TargetUPN,SourcePrimarySmtp,TargetPrimarySmtp,Wave,Department
ana.perez@origen.com,ana.perez@destino.com,ana.perez@origen.com,ana.perez@destino.com,Oleada-01,Finanzas
juan.garcia@origen.com,juan.garcia@destino.com,juan.garcia@origen.com,juan.garcia@destino.com,Oleada-01,Operaciones

7. Automatización, logging y control de errores

En la práctica: automatizar no significa “lanzar scripts sin mirar”; significa repetir de forma segura, con logs, validaciones y puntos de control.

Buenas prácticas de automatización

• Separar scripts por función: inventario, preparación, validación, ejecución, reporting y rollback.
• Usar logging estructurado: CSV, JSON o Log Analytics para poder revisar errores por usuario y por workload.
• Implementar reintentos: especialmente ante throttling, errores 429/503 o respuestas temporales.
• Controlar paralelismo: demasiadas tareas en paralelo pueden empeorar el rendimiento.
• Proteger secretos: nada de contraseñas en texto plano; usar vaults, identidades administradas o certificados cuando sea posible.
• Versionar scripts: Git permite saber qué se cambió, cuándo y por qué.
• Validar antes y después: no basta con ejecutar; hay que comprobar resultado.

Ejemplo de patrón Try/Catch con log

$log = ".\log-migracion.csv"

function Write-MigrationLog {
  param(
    [string]$ObjectId,
    [string]$Action,
    [string]$Status,
    [string]$Message
  )

  [PSCustomObject]@{
    Timestamp = (Get-Date).ToString("s")
    ObjectId  = $ObjectId
    Action    = $Action
    Status    = $Status
    Message   = $Message
  } | Export-Csv $log -Append -NoTypeInformation -Encoding UTF8
}

foreach ($item in Import-Csv ".\mapeo.csv") {
  try {
    # Acción de ejemplo
    Write-Host "Procesando $($item.SourceUPN)"
    Write-MigrationLog -ObjectId $item.SourceUPN -Action "PreCheck" -Status "OK" -Message "Validación completada"
  }
  catch {
    Write-MigrationLog -ObjectId $item.SourceUPN -Action "PreCheck" -Status "ERROR" -Message $_.Exception.Message
  }
}

8. Coexistencia: correo, calendarios, Teams e identidad

En la práctica: la coexistencia permite que la empresa siga trabajando mientras la migración avanza.

8.1 Coexistencia de correo

En migraciones por oleadas, parte de los usuarios puede estar en el tenant origen y otra parte en el destino. Hay que diseñar cómo se entrega el correo, cómo se resuelven alias, cómo se enrutan mensajes internos y cuándo se mueve el dominio principal.

• Conectores y reglas de transporte temporales.
• Contactos o mail users para representar usuarios del otro tenant.
• Forwarding temporal por oleada cuando sea necesario.
• Validación de SPF, DKIM y DMARC en el dominio destino.
• Plan claro para mover MX y Autodiscover.

8.2 Coexistencia de calendarios

La disponibilidad free/busy es crítica para ventas, dirección, soporte y equipos de proyecto. Si los usuarios están repartidos entre tenants, conviene preparar relaciones de organización o alternativas de visibilidad antes de iniciar oleadas grandes.

8.3 Coexistencia de Teams

Teams requiere especial cuidado: chats, canales, reuniones, invitados, archivos, pestañas y permisos no dependen de una sola capa. Durante la coexistencia se pueden usar B2B, acceso externo, canales compartidos y reglas de federación, pero hay que definir claramente dónde se trabaja: tenant origen, tenant destino o ambos durante un periodo limitado.

8.4 Movimiento del dominio

El dominio corporativo no puede estar activo como dominio aceptado principal en dos tenants a la vez de forma indefinida. El movimiento debe ensayarse: limpiar referencias en origen, preparar destino, reducir TTL cuando aplique, cambiar DNS y validar entrega.

9. Identidad y directorio: Entra ID cross-tenant

En la práctica: si la identidad no está bien pensada, todo lo demás se complica.

Microsoft Entra ID ofrece varias capacidades para colaboración y coexistencia entre organizaciones: cross-tenant access, B2B collaboration, B2B direct connect y cross-tenant synchronization. En una migración, estas piezas ayudan a que los usuarios puedan acceder a recursos antes de que todos los datos estén movidos.

Qué decidir antes de configurar identidad

• UPN temporal y UPN final.
• Dominio de correo principal durante cada fase.
• Usuarios invitados vs usuarios miembros.
• Grupos que se replican o se reconstruyen.
• Roles administrativos en destino.
• Políticas MFA y Acceso Condicional.
• Aplicaciones empresariales y SSO.

Cross-tenant synchronization

La sincronización entre tenants puede ayudar a crear, actualizar y retirar usuarios B2B en un tenant de destino. No sustituye la migración de datos, pero facilita permisos, colaboración y acceso gradual.

10. Exchange Online: opciones, scripts y buenas prácticas

En la práctica: Exchange suele ser la carga más visible. Si el correo falla, el usuario percibe que toda la migración falla.

Opciones habituales

• Cross-tenant mailbox migration: vía nativa para mover buzones entre tenants cuando se cumplen requisitos.
• Herramientas de terceros: útiles para reporting, coexistencia avanzada o escenarios no estándar.
• PST: opción residual para casos puntuales, históricos o usuarios especiales.

Buenas prácticas

• Trabajar por lotes y no mezclar usuarios críticos con oleadas masivas.
• Preparar usuarios destino antes de iniciar migraciones.
• Validar buzones compartidos, permisos, delegaciones y calendarios.
• Revisar reglas de transporte y conectores.
• Comunicar al usuario qué cambia en Outlook y móviles.
• Medir tamaño de buzones, elementos corruptos, archivo online y retención.

Validaciones post-migración

• Envío y recepción interna/externa.
• Acceso Outlook y Outlook en la Web.
• Calendario y reuniones existentes.
• Permisos delegados y buzones compartidos.
• Archivado, retención y eDiscovery.

11. OneDrive y SharePoint: migración cross-tenant y reorganización

En la práctica: el problema no es solo mover archivos, sino conservar contexto, permisos y estructura útil.

OneDrive

OneDrive suele contener información personal de trabajo: documentos en curso, borradores, archivos compartidos con compañeros y enlaces enviados a externos. La migración debe gestionar expectativas: algunos enlaces deberán recrearse y ciertos permisos no se traducen exactamente.

SharePoint

SharePoint es más complejo porque suele contener sitios de departamento, intranets, bibliotecas con metadatos, páginas modernas, listas, permisos heredados, automatizaciones, formularios, pestañas de Teams y enlaces externos. Aquí conviene decidir si se migra tal cual o si se aprovecha para ordenar.

Buenas prácticas

• Inventariar sitios, tamaño, propietarios, actividad y permisos.
• Archivar sitios inactivos antes de migrar.
• Revisar bibliotecas con demasiadas versiones.
• Mapear usuarios y grupos antes de mover contenido.
• Probar con sitios representativos: uno sencillo, uno grande y uno complejo.
• Validar navegación, páginas, permisos y enlaces tras la migración.

12. Microsoft Teams: qué se puede mover y qué conviene reconstruir

En la práctica: Teams es una capa de colaboración, no un repositorio aislado. Por eso suele requerir un enfoque más cuidadoso.

En Teams conviven muchas piezas: grupo de Microsoft 365, sitio de SharePoint, canales, miembros, propietarios, archivos, mensajes, pestañas, apps, bots, reuniones, grabaciones y permisos. Algunas piezas se pueden migrar, otras se recrean y otras conviene rediseñarlas.

Qué revisar en Teams

• Equipos activos, archivados e inactivos.
• Propietarios y miembros.
• Canales estándar, privados y compartidos.
• Archivos asociados a canales.
• Pestañas: Planner, OneNote, SharePoint, Power BI, apps de terceros.
• Reuniones recurrentes y grabaciones.
• Invitados y usuarios externos.

Enfoques habituales

• Recrear estructura: equipos y canales nuevos con archivos migrados.
• Migrar con terceros: cuando se quiere conservar más contexto y acelerar ejecución.
• Reconstruir con gobierno: aprovechar para eliminar equipos duplicados y crear una estructura más limpia.

13. Planner, Bookings, Stream y otras cargas

En la práctica: las cargas “pequeñas” pueden generar muchas incidencias si nadie las revisa.

Planner

Planner suele estar asociado a Teams. Al migrar un equipo, conviene revisar planes, cubos, tareas, adjuntos, responsables y fechas. En muchos casos se recrea o se usa herramienta de terceros.

Bookings

Bookings puede depender de buzones, calendarios, usuarios y servicios. Si hay citas con clientes o integraciones, se debe revisar antes del corte.

Stream en SharePoint

Los vídeos almacenados en SharePoint u OneDrive deben tratarse como archivos, pero con atención adicional: enlaces incrustados, permisos, pestañas de Teams y páginas donde aparezcan embebidos.

Lists, Forms, OneNote y Whiteboard

Estas cargas suelen requerir revisión individual. Algunas se pueden exportar, otras se recrean y otras dependen del equipo o sitio al que están vinculadas.

14. Power Platform, Power BI y aplicaciones conectadas

En la práctica: una migración puede “romper” automatizaciones aunque el correo y los archivos funcionen perfectamente.

Power Automate, Power Apps, Power BI, Dataverse y conectores suelen depender de usuarios, permisos, URLs, listas de SharePoint, buzones, credenciales y aplicaciones registradas. Si no se inventarían, los errores aparecen después del corte.

Qué inventariar

• Flujos críticos de Power Automate.
• Aplicaciones Power Apps usadas por negocio.
• Conexiones y credenciales.
• Entornos de Power Platform.
• Tablas Dataverse y dependencias.
• Workspaces, datasets y gateways de Power BI.
• Aplicaciones registradas en Entra ID.

Estrategia recomendada

• Clasificar automatizaciones por criticidad.
• Exportar soluciones cuando sea posible.
• Recrear conexiones con cuentas de servicio controladas.
• Probar flujos end-to-end con usuarios de negocio.
• Documentar propietarios y soporte de cada automatización.

15. Rendimiento, throttling y escalabilidad

En la práctica: más velocidad no siempre significa más paralelismo. A veces, lanzar demasiadas tareas empeora el resultado.

Microsoft 365 protege sus servicios mediante mecanismos de throttling. Esto significa que, si una migración hace demasiadas solicitudes, el servicio puede responder con límites temporales. La solución no es insistir sin control, sino respetar cabeceras como Retry-After, reducir concurrencia y planificar ventanas de trabajo.

Factores que afectan al rendimiento

• Tamaño de buzones y número de elementos.
• Número de archivos pequeños en OneDrive/SharePoint.
• Versiones de documentos.
• Permisos únicos y estructuras heredadas.
• Red, latencia y ubicación geográfica.
• Horas punta del servicio.
• Estado del tenant origen y destino.
• Herramienta utilizada y concurrencia configurada.

Buenas prácticas

• Empezar con piloto realista, no con un usuario vacío.
• Medir GB/h, elementos/h y errores por lote.
• Separar usuarios VIP o críticos.
• Evitar migrar todo en una sola tarea gigante.
• Usar reintentos controlados.
• No aumentar agentes o hilos sin medir impacto.

16. Seguridad, cumplimiento y retención

En la práctica: la migración es una oportunidad para mejorar seguridad, pero también puede romper cumplimiento si no se coordina.

Controles a revisar

• MFA y Acceso Condicional.
• Roles administrativos y cuentas privilegiadas.
• Microsoft Purview: retención, etiquetas, eDiscovery y DLP.
• Defender for Office 365 y políticas antiphishing.
• Compartición externa en SharePoint y OneDrive.
• Invitados y B2B en Teams.
• Protocolos heredados y aplicaciones antiguas.

Retención y eDiscovery

Las políticas de retención y los casos legales pueden bloquear movimientos o exigir preservación de datos. Antes de migrar, conviene revisar qué información está bajo retención, qué debe conservarse en origen y qué debe recrearse en destino.

Servicio relacionado: Seguridad y cumplimiento Microsoft 365.

17. Checklists operativos

17.1 Antes de elegir herramienta

• Inventario de usuarios, buzones, OneDrive, SharePoint y Teams.
• Mapa de dominios y DNS.
• Mapa de aplicaciones, Power Platform y conectores.
• Identificación de usuarios críticos.
• Definición de alcance: qué se migra, qué se archiva, qué se reconstruye.
• Requisitos de cumplimiento y retención.

17.2 Antes del piloto

• Usuarios destino creados y licenciados.
• Permisos administrativos preparados.
• Mapeos revisados.
• Herramienta configurada.
• Scripts probados en modo lectura.
• Plan de comunicación preparado.

17.3 Durante las oleadas

• Seguimiento de estado por carga.
• Registro de errores y reintentos.
• Validación con usuarios reales.
• Comunicación a negocio.
• Control de incidencias y decisiones pendientes.

17.4 Después del corte

• Validar correo, calendarios, Teams y archivos.
• Revisar permisos y enlaces externos.
• Confirmar DNS y autenticación de correo.
• Revisar seguridad y cumplimiento.
• Actualizar documentación.
• Planificar retirada del tenant origen.

18. Riesgos frecuentes y cómo mitigarlos

19. Preguntas frecuentes sobre herramientas para migrar entre tenants de Microsoft 365

20. Recursos oficiales y enlaces externos

Documentación oficial de Microsoft

• Microsoft 365 tenant-to-tenant migrations
• Cross-tenant mailbox migration
• Cross-tenant OneDrive migration
• Cross-tenant SharePoint site migration
• Microsoft Entra cross-tenant access
• Microsoft Entra cross-tenant synchronization
• SharePoint y OneDrive migration performance
• Microsoft Graph throttling guidance
• Power Platform tenant-to-tenant migration

Servicios relacionados de MSAdvance

• Migración entre tenants Microsoft 365
• Migración a Microsoft 365
• Modern Workplace Microsoft 365
• Seguridad y cumplimiento Microsoft 365
• Arquitectura Azure
• Todos los servicios

21. Conclusión y siguientes pasos

Una migración entre tenants de Microsoft 365 bien planteada no depende de una sola herramienta. Depende de entender el entorno, elegir el método adecuado para cada carga, automatizar lo repetitivo, controlar riesgos y acompañar a los usuarios durante el cambio.

El enfoque más sólido suele combinar capacidades nativas de Microsoft, herramientas especializadas cuando aportan valor y scripts PowerShell para inventario, validación y reporting. Así se evita improvisar, se reducen cortes y se consigue que el nuevo tenant no sea una copia desordenada del anterior, sino una base más limpia, segura y gobernable.