Herramientas para migrar entre tenants: cómo elegir

Cómo elegir herramientas entre tenants por carga y resultado esperado

Las herramientas para migrar entre tenants deben evaluarse con el resultado que necesita conservar la organización. Correo, archivos y colaboración pueden requerir métodos diferentes. Incluso dentro de una misma carga hay propiedades con distinto tratamiento: miembros, permisos, versiones, enlaces o conversaciones. La propuesta debe señalar qué resuelve cada herramienta y qué trabajo quedará fuera de su ejecución.

En una consolidación, una herramienta puede encajar con el correo mientras otra se utiliza para una parte documental. La combinación debe tener límites claros sobre qué objetos crea o modifica cada una. Si ambas actúan sobre el mismo destino sin coordinación, puede resultar difícil distinguir una limitación del método de un conflicto introducido por la propia secuencia de migración.

La matriz de evaluación debe incluir requisitos del origen y del destino, preparación de identidades, licencias y evidencias de validación. El piloto prueba esas condiciones con casos comunes y casos difíciles. El criterio no es acumular más productos, sino disponer del conjunto mínimo que cubra el alcance y que el equipo pueda administrar e investigar con claridad.

Cómo incorporar el trabajo manual a la comparación

Una herramienta puede transferir un dato y dejar una tarea importante de reconstrucción. Esa intervención debe figurar en la estimación junto con el coste de licencia. Durante el piloto se mide el esfuerzo de preparar, ejecutar, corregir y validar, utilizando el mismo alcance para cada alternativa. Así se evita comparar precios que corresponden a resultados diferentes.

La elección final debe recoger las limitaciones aceptadas y cómo se comunicarán al usuario. También debe especificar quién conservará los informes y retirará los accesos concedidos cuando termine el trabajo. Esta perspectiva facilita comparar opciones por su encaje operativo y evita depender de una demostración que solo muestra el caso más sencillo de transferencia.

Por qué no deberías empezar el proyecto eligiendo herramienta

Es muy habitual recibir una petición del tipo: “Tenemos que migrar dos tenants. ¿Usamos Quest o BitTitan?” La pregunta llega demasiado pronto. Antes de comparar herramientas habría que conocer, como mínimo, la distribución real de los datos:

Una herramienta que encaja perfectamente con 100 buzones puede no ser la mejor para un entorno con 70 Teams, 300 sitios SharePoint y una escisión de Active Directory. Por eso, el orden lógico es: discovery → alcance → arquitectura → comparación de herramientas → piloto → decisión definitiva.

Las cuatro familias de herramientas que aparecen en una migración Microsoft 365

No todas las herramientas que utilizamos durante una migración son herramientas de migración en sentido estricto.

Esta clasificación evita comparar herramientas que realmente no compiten entre sí.

Herramientas nativas de Microsoft para migraciones entre tenants

Las capacidades nativas de Microsoft han evolucionado de forma considerable. Actualmente Microsoft distingue entre migraciones realizadas con herramientas individuales por workload y una migración coordinada mediante Microsoft 365 Migration Orchestrator. Eso significa que ya no es correcto afirmar de forma genérica que “Microsoft no tiene herramientas tenant-to-tenant”. Sí las tiene, aunque su cobertura, licenciamiento y comportamiento deben analizarse workload por workload.

Referencia oficial: Microsoft – Microsoft 365 Migration Overview.

Microsoft 365 Migration Orchestrator

Migration Orchestrator es el intento de Microsoft de resolver uno de los grandes problemas de las migraciones tenant-to-tenant: coordinar distintos workloads de un mismo usuario sin tratarlos como proyectos completamente independientes. Microsoft lo orienta a fusiones, adquisiciones, divestitures y reorganizaciones empresariales. La documentación disponible en el momento de redactar esta guía continúa indicando que la funcionalidad tenant-to-tenant con Orchestrator está en preview, por lo que su disponibilidad, requisitos y capacidades deben comprobarse antes de diseñar un proyecto de producción.

Qué aporta el enfoque orquestado

La principal ventaja es la coordinación. Microsoft conoce las dependencias entre sus propios workloads y puede gestionar secuencias dentro del conjunto soportado. Por ejemplo, Teams tiene dependencias con Exchange y OneDrive, y determinadas cargas no deberían ejecutarse en cualquier orden. La migración se organiza mediante batches y Microsoft ofrece una fase de validación previa para comprobar requisitos de aplicación, relaciones entre tenants, licencias e identity mapping.

Referencia oficial: Microsoft – Migration Orchestrator Overview. Cuándo lo evaluaría. Tiene especial interés cuando el proyecto encaja bien con los workloads soportados y la organización prefiere mantener el movimiento dentro de las capacidades de Microsoft. Sin embargo, si existen muchas necesidades de transformación, coexistencia avanzada, Teams complejos, reporting específico o múltiples cargas no cubiertas por el modelo actual, una plataforma especializada puede simplificar el proyecto.

Microsoft Cross-Tenant Mailbox Migration

Microsoft dispone de una solución nativa para mover buzones de Exchange Online entre tenants utilizando MRS y Exchange Online PowerShell. No es una copia IMAP ni una exportación/importación. El usuario debe prepararse correctamente en el destino como MailUser y el procedimiento conserva una lógica específica de routing y coexistencia después del movimiento. Ventajas. Al tratarse de una capacidad nativa, el movimiento se realiza dentro de Exchange Online y encaja bien en determinados proyectos centrados en buzones.

Aspectos que debes comprobar.

Referencia oficial: Microsoft – Cross-Tenant Mailbox Migration.

Microsoft Cross-Tenant OneDrive Migration

Microsoft también dispone de una capacidad nativa para mover cuentas de OneDrive entre tenants. Es importante entender su comportamiento porque es diferente al de muchas herramientas SaaS de terceros. Microsoft define actualmente el proceso como one-and-done: el contenido se mueve de origen a destino y se coloca una redirección en la antigua ubicación. No hay una primera copia seguida de múltiples pases delta.

Puede programarse un máximo de 4.000 OneDrive simultáneamente en la cola y Microsoft documenta un máximo de 5 TB o un millón de elementos por OneDrive. Cuándo puede resultar atractivo. Cuando el comportamiento de movimiento directo encaja con el cutover y la empresa no necesita un modelo de premigración incremental. Cuándo comparar con una herramienta especializada. Cuando se buscan varias pasadas, una operativa distinta de pre-stage, reporting consolidado con otros workloads o mayor flexibilidad en determinadas transformaciones.

Referencia oficial: Microsoft – Cross-Tenant OneDrive Migration.

Microsoft Cross-Tenant SharePoint Migration

Microsoft dispone también de una solución específica para mover sitios SharePoint entre tenants. Esta capacidad cubre actualmente sitios conectados a Microsoft 365 Groups —incluidos sitios asociados con Teams—, sitios modernos sin Group y sitios clásicos, aunque existen limitaciones que deben analizarse antes de escogerla.

Su existencia hace que Microsoft nativo sea actualmente una alternativa real también para proyectos con SharePoint, siempre que la arquitectura encaje con estos requisitos. Referencia oficial: Microsoft – Cross-Tenant SharePoint Migration.

Quest On Demand Migration

Quest On Demand Migration es probablemente una de las plataformas que merece evaluarse primero cuando el proyecto abarca varios componentes de Microsoft 365. Quest publica actualmente soporte dentro de su ecosistema para Exchange Online, OneDrive, SharePoint Online, Microsoft Teams, Microsoft 365 Groups y Chats, Power BI, dominios de correo, Active Directory y Microsoft Entra ID. La principal diferencia frente a utilizar varias herramientas nativas independientes es la existencia de una plataforma orientada específicamente a discovery, mapping, ejecución, seguimiento y coexistencia.

Qué aporta especialmente Quest

Quest también sigue evolucionando. Durante 2026 Quest ha incorporado mejoras en Teams y SharePoint, incluyendo mayor control sobre filtros de equipos y canales, migración de membresía de SharePoint Groups dentro de determinados procesos de Teams y nuevas posibilidades de mapping en SharePoint. Esto es relevante porque demuestra por qué no conviene utilizar una comparativa de herramientas escrita hace varios años para tomar una decisión actual.

Referencia oficial: Quest – On Demand Migration. Cuándo lo evaluaría especialmente. En fusiones y adquisiciones con varios workloads, migraciones con Teams y SharePoint relevantes, proyectos con identidad híbrida, dispositivos o escenarios donde se necesita coexistencia y una gestión centralizada. Qué comprobar antes de comprar. Quest utiliza planes y módulos con distintas capacidades. La cobertura comercial exacta debe validarse según el workload, número de usuarios, necesidades de Domain Move o Domain Rewrite y cualquier componente adicional.

No conviene presupuestar únicamente “una licencia Quest por usuario” sin validar antes qué funcionalidad necesita realmente el proyecto.

ShareGate: mucho más que SharePoint

Durante mucho tiempo ShareGate estuvo especialmente asociado a SharePoint y Teams. En 2026 su posicionamiento tenant-to-tenant es más amplio. Actualmente ShareGate presenta su solución como un flujo que cubre identidades, buzones y contenido, además de sus conocidas capacidades de SharePoint, OneDrive y Microsoft Teams. Esto obliga a revisar comparativas antiguas en las que se descartaba automáticamente ShareGate para proyectos que incluían Exchange.

SharePoint y Teams siguen siendo uno de sus puntos fuertes. ShareGate permite seleccionar y reorganizar contenido, migrar Teams completos o canales específicos y trabajar sobre estructuras de SharePoint con un enfoque muy orientado a la administración y transformación. Para Teams, ShareGate publica actualmente soporte para elementos como: canales estándar y privados, permisos, archivos, associated SharePoint sites, tabs, apps y Planner, con limitaciones documentadas que deben consultarse para cada caso.

Mailboxes. ShareGate Migrate ya incluye funciones de copia de buzones y ha seguido incorporando mejoras de mapping, autenticación mediante aplicación y automatización durante 2026. Identidades Entra ID. ShareGate lanzó en 2026 una funcionalidad de migración de identidades Entra ID en beta dentro de determinados planes. Precisamente por tratarse de una funcionalidad relativamente nueva, conviene confirmar el estado actual y las limitaciones antes de convertirla en una pieza crítica de producción.

Referencia oficial: ShareGate – Tenant-to-Tenant Migration. Cuándo lo evaluaría. Cuando SharePoint y Teams tienen un peso importante, cuando se quiere aprovechar la migración para reorganizar o limpiar contenido y, cada vez más, cuando se busca reducir el número de herramientas utilizadas dentro del proyecto.

BitTitan MigrationWiz

MigrationWiz es una plataforma SaaS con una larga trayectoria en migraciones de correo y Microsoft 365. Su modelo se organiza mediante distintos tipos de proyectos y licencias, lo que permite cubrir buzones, documentos, Teams, SharePoint y, actualmente, Teams Private Chats bajo proyectos específicos. Tenant Migration Bundle. BitTitan documenta actualmente un Tenant Migration Bundle orientado específicamente a consolidaciones Microsoft 365 tenant-to-tenant.

Según su documentación vigente, incluye cobertura para workloads como:

Teams Private Chat ha cambiado en 2026. BitTitan actualizó durante julio de 2026 su implementación de Teams Private Chat para utilizar las APIs de importación actuales de Microsoft. La documentación vigente establece, entre otros aspectos, un máximo de concurrencia de 20 usuarios para estos trabajos y especifica limitaciones concretas como determinadas menciones y usuarios invitados. Esto ilustra otra regla importante: no presupuestes una migración basándote en lo que una herramienta hacía hace seis meses. En Teams, especialmente, los cambios son frecuentes.

Cuándo evaluaría MigrationWiz. En proyectos donde Exchange tiene mucho peso, cuando se busca una plataforma SaaS basada en proyectos bien documentados o cuando los workloads se ajustan a los bundles y tipos de proyecto disponibles. Referencia oficial: BitTitan – Microsoft 365 Tenant Migrations.

Cloudiway

Cloudiway es otra plataforma especializada que merece evaluarse tanto en Microsoft 365 tenant-to-tenant como en migraciones cross-platform. Su documentación actual dispone de guías específicas para: correo, OneDrive, SharePoint, Microsoft Teams, Intune y dispositivos entre tenants, además de diferentes orígenes externos. Una ventaja: variedad de escenarios. Cloudiway puede resultar especialmente interesante cuando el proyecto no es exclusivamente Microsoft 365 → Microsoft 365 o cuando además de contenido existen dispositivos o configuraciones de administración que deben tratarse.

Cuándo evaluarla. En migraciones con múltiples tipos de contenido, entornos cross-platform, Teams, Intune o dispositivos, o cuando interesa comparar una plataforma multiworkload alternativa a Quest. Referencia oficial: Cloudiway – Official Migration Admin Guides.

Comparativa de herramientas por workload

Una tabla útil no debería decir simplemente qué proveedor tiene una casilla marcada. La pregunta importante es qué tipo de proyecto resuelve mejor cada opción.

Esta tabla no debe utilizarse como una matriz contractual de funcionalidades. Sirve para orientar el análisis. El soporte exacto de cada objeto debe verificarse contra la versión actual de la herramienta antes de contratarla.

Cuando la migración dura meses, la coexistencia cambia la decisión

Dos herramientas pueden migrar exactamente el mismo buzón y, sin embargo, una ser mucho más adecuada para el proyecto porque la empresa necesita mantener ambos tenants funcionando simultáneamente durante tres meses. Una migración por fases puede necesitar: mail routing entre tenants, free/busy, domain rewrite, colaboración Teams entre organizaciones, identidad sincronizada y una estrategia para usuarios que ya han migrado y usuarios que todavía no.

En estos proyectos la herramienta no debe evaluarse únicamente por lo que copia, sino por lo que permite mantener operativo mientras se copia.

La fidelidad de migración importa más que una tabla con muchos checks

Dos proveedores pueden indicar que ambos migran “Teams” y ofrecer resultados diferentes. Lo mismo ocurre en SharePoint, OneDrive y Exchange. Hay que preguntar qué significa exactamente cada funcionalidad. SharePoint. No preguntes únicamente si migra SharePoint. Pregunta: ¿migra versiones?, ¿metadata?, ¿permisos únicos?, ¿sharing links?, ¿listas?, ¿content types?, ¿term store?, ¿sites conectados a Teams?, ¿apps? Teams. No preguntes únicamente si migra Teams. Pregunta por: standard channels, private channels, shared channels, posts, chats, Planner, tabs, apps, files, meeting chats, invitados y attachments.

Exchange

No preguntes únicamente por mensajes. Revisa: Archive, calendario, contactos, reglas, shared mailboxes, Full Access, Send As, delegaciones, meeting links y coexistencia.

Permisos y seguridad: una parte de la comparación que no debería ignorarse

Una herramienta de migración necesita acceder potencialmente a correo, documentos, chats y otra información sensible de la organización. Por eso, comparar únicamente funcionalidades y precio es insuficiente. También deberíamos revisar:

Ejemplo: Quest y mínimo privilegio. Quest documenta actualmente posibilidades como Sites.Selected para restringir determinados accesos de SharePoint y RBAC for Applications para reducir el ámbito de Exchange Online en escenarios compatibles. Este tipo de detalle puede tener más importancia para una organización regulada que una pequeña diferencia en el precio de las licencias.

Cómo comparar realmente el precio de las herramientas

Comparar únicamente “precio por usuario” puede llevar a conclusiones equivocadas. El coste real debería calcularse como: licencia de migración, licencias Microsoft necesarias, coexistencia, infraestructura, horas técnicas, soporte, duración de doble licenciamiento.

Una herramienta aparentemente más cara puede acabar reduciendo el coste total si elimina muchas horas de scripting, troubleshooting y operación manual. También puede ocurrir lo contrario: para una migración sencilla, adquirir una plataforma multiworkload muy amplia puede ser innecesario.

PowerShell: imprescindible en muchas migraciones, pero no es una herramienta de migración completa

PowerShell es uno de los elementos más útiles de un proyecto Microsoft 365, pero conviene explicar bien su papel. PowerShell administra y automatiza Microsoft 365. Puede además iniciar algunas migraciones nativas. Pero un script no se convierte automáticamente en una plataforma tenant-to-tenant capaz de migrar todos los workloads. Módulos actuales que pueden intervenir.

Para nuevos desarrollos es preferible evitar scripts basados en los antiguos módulos AzureAD y MSOnline cuando existe alternativa soportada en Microsoft Graph.

Ejemplo: inventario básico de usuarios con Microsoft Graph

Install-Module Microsoft.Graph -Scope CurrentUser

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

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

Inventario de Exchange Online

Install-Module ExchangeOnlineManagement -Scope CurrentUser

Connect-ExchangeOnline

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

Buzones compartidos

Get-EXOMailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited |
    Select-Object DisplayName,PrimarySmtpAddress |
    Export-Csv "C:\Temp\shared-mailboxes.csv" -NoTypeInformation -Encoding UTF8

Inventario de Teams

Install-Module MicrosoftTeams -Scope CurrentUser

Connect-MicrosoftTeams

Get-Team |
    Select-Object DisplayName,GroupId,Visibility,MailNickName,Archived |
    Export-Csv "C:\Temp\teams.csv" -NoTypeInformation -Encoding UTF8

Inventario de canales

$Teams = Get-Team

$Channels = foreach ($Team in $Teams) {

    Get-TeamChannel -GroupId $Team.GroupId | ForEach-Object {

        [PSCustomObject]@{
            TeamName       = $Team.DisplayName
            GroupId        = $Team.GroupId
            ChannelName    = $_.DisplayName
            MembershipType = $_.MembershipType
        }
    }
}

$Channels |
    Export-Csv "C:\Temp\teams-canales.csv" -NoTypeInformation -Encoding UTF8

Estos ejemplos son de inventario. Antes de ejecutar automatizaciones que creen, cambien o eliminen objetos en producción deben probarse en un entorno controlado y adaptarse al tenant.

Microsoft Graph: la API que hay detrás de cada vez más migraciones

Microsoft Graph tiene cada vez más peso en los proyectos de migración. No solo sirve para inventariar usuarios y grupos. Microsoft publica APIs específicas que permiten a herramientas y desarrolladores trabajar con determinados escenarios de migración, incluyendo capacidades tenant-to-tenant y APIs de importación para Microsoft Teams. Esto explica por qué algunas funcionalidades que antes eran imposibles —como determinados escenarios de historial de chats— están apareciendo ahora tanto en Microsoft como en herramientas de terceros.

Sin embargo, utilizar Graph directamente significa asumir también: desarrollo, permisos, autenticación, gestión de errores, throttling, logging, reintentos, monitorización y validación. Construir internamente una solución puede tener sentido para una necesidad muy concreta o repetitiva. Para una migración puntual compleja, a menudo no compensa replicar las funciones de una plataforma ya desarrollada.

SharePoint Migration Tool: útil, pero para otro tipo de migración

SharePoint Migration Tool (SPMT) es una herramienta gratuita de Microsoft diseñada principalmente para trasladar contenido desde SharePoint Server hacia Microsoft 365. Microsoft documenta actualmente compatibilidad con versiones como SharePoint Server 2010, 2013, 2016 y 2019, además de determinados workflows. Puede migrar hacia SharePoint, OneDrive o ubicaciones relacionadas con Teams. Pero eso no la convierte en una solución completa para: Tenant A Microsoft 365 → Tenant B Microsoft 365.

No resuelve por sí sola Exchange, identidades, dominio, chats, aplicaciones ni una migración Microsoft 365 multiworkload. Referencia oficial: Microsoft – SharePoint Migration Tool.

Migration Manager: muy útil para migraciones externas hacia Microsoft 365

Migration Manager se encuentra en el SharePoint Admin Center y está pensado para administrar y monitorizar migraciones de contenidos hacia Microsoft 365. En los escenarios de file shares utiliza agentes desplegados en servidores o máquinas virtuales y permite distribuir tareas de migración entre ellos. Microsoft ha ampliado además Migration Manager para diferentes orígenes externos.

Esta última distinción es importante porque Migration Manager y Migration Orchestrator no son lo mismo. Referencia oficial: Microsoft – Migration Manager.

Robocopy: útil para archivos locales, no para migrar Microsoft 365

Robocopy sigue siendo una excelente herramienta de Windows para copiar grandes cantidades de datos entre rutas de archivos. Puede resultar útil antes de una migración cloud si necesitamos consolidar varios file shares o trasladar datos desde un servidor antiguo hacia un staging server.

Ejemplo sencillo

robocopy "D:\DatosOrigen" "\\ServidorDestino\Datos" /E /COPY:DAT /R:2 /W:5 /LOG:"C:\Temp\robocopy.log"

Pero copiar un fichero no equivale a migrar un objeto Microsoft 365.

Un proyecto que intenta resolver SharePoint o OneDrive tenant-to-tenant descargando archivos y copiándolos con Robocopy normalmente pierde gran parte de la información que hace que esos servicios sean algo más que un sistema de carpetas.

¿Se pueden combinar varias herramientas en una misma migración?

Sí, y en algunos proyectos es exactamente lo correcto. Una arquitectura podría utilizar:

Eso no significa que debamos utilizar muchas herramientas por defecto. Cada nueva plataforma añade: licencias, permisos, conocimiento, logs, soporte y coordinación. Si una única herramienta cubre correctamente todo el alcance, suele ser más sencillo operar el proyecto desde una misma consola. El peligro de una migración fragmentada. Si cada workload se trata de forma independiente sin una arquitectura común, pueden aparecer errores de secuencia.

Por ejemplo, migrar Teams antes de tener correctamente preparados usuarios, SharePoint y OneDrive puede afectar a permisos, archivos o chats. Las herramientas pueden combinarse, pero la arquitectura debe seguir siendo una sola.

Un método práctico para elegir herramienta

En vez de empezar comparando marcas, podemos evaluar cada proyecto mediante siete preguntas. 1. ¿Qué workloads existen realmente?. El primer filtro es el inventario.

Con este dato ya podemos descartar o priorizar muchas opciones. 2. ¿Qué fidelidad necesita el cliente?. ¿Quiere simplemente los documentos o necesita versiones, metadata, sharing, conversaciones, Planner y permisos? Cuanta más fidelidad se exige, más importante es analizar cada workload en profundidad. 3. ¿Necesitamos premigración y deltas?. Esta pregunta puede descartar inmediatamente determinados métodos nativos one-and-done. En una organización con grandes volúmenes de SharePoint y poco tiempo de cutover, la capacidad de hacer varias pasadas puede ser decisiva.

4. ¿Cuánto durará la coexistencia?. Una migración de una noche y una separación de seis meses no necesitan la misma tecnología. 5. ¿Hay identidad o dispositivos en alcance?. Si además de Microsoft 365 debemos migrar Active Directory, Entra-joined devices o Intune, el conjunto de alternativas cambia significativamente. 6. ¿Qué nivel de automatización y reporting necesitamos?. Una empresa con 20 usuarios puede administrar correctamente varios scripts y hojas de control.

Una migración de 5.000 usuarios necesita probablemente otra escala de reporting y operación. 7. ¿Quién mantendrá la herramienta durante el proyecto?. La facilidad comercial de una consola SaaS no significa que la herramienta pueda operarse sin experiencia. Hay que conocer los permisos, errores, throttling, mappings, reintentos y validaciones de cada workload.

El piloto debe confirmar —o cambiar— la elección de herramienta

Una evaluación teórica puede decir que una herramienta cumple el alcance. El piloto demuestra cómo lo cumple realmente. El piloto debería incluir casos suficientemente variados:

Si el piloto demuestra que una función crítica no se comporta como se esperaba, todavía estamos a tiempo de modificar la arquitectura.

Errores frecuentes al elegir una herramienta de migración

Checklist antes de contratar licencias de migración

Preguntas frecuentes sobre herramientas para migrar tenants Microsoft 365

¿Una herramienta tenant-to-tenant cubre siempre todo Microsoft 365?

No debe interpretarse así. Cada solución tiene un alcance que debe comprobarse por carga y propiedad. Correo, archivos, conversaciones, aplicaciones y permisos pueden tener requisitos o tratamientos distintos. La propuesta debe explicar qué queda disponible en destino y qué necesita adaptación, reconstrucción o conservación por otro procedimiento.

¿Tiene sentido combinar varias herramientas?

Puede tenerlo si cubren necesidades distintas y la secuencia está probada. Hay que delimitar qué objetos crea o modifica cada una y evitar actuaciones superpuestas sin control. La combinación se valida durante el piloto, incluyendo la investigación de errores y las operaciones de actualización que admita cada método.

¿Cómo se calcula el coste real de una herramienta?

Además de la licencia, se consideran preparación, ejecución, corrección, validación y tareas manuales que quedan fuera de su alcance. El piloto permite estimar ese esfuerzo con una muestra realista. Comparar únicamente el precio por usuario puede ocultar diferencias importantes en el resultado entregado y en el trabajo que mantiene el equipo interno.

¿Qué debe quedar documentado al elegir una solución?

Deben quedar el alcance, los requisitos, las limitaciones aceptadas, los resultados del piloto y el procedimiento de operación. También se identifican responsables de incidencias e informes. Esa documentación permite comprobar que la herramienta elegida responde al proyecto concreto y explica por qué otras alternativas no se ajustaban al mismo resultado.

Recomendaciones finales: primero decide cómo debe quedar el nuevo tenant y después elige la herramienta

El mercado de herramientas para migraciones tenant-to-tenant de Microsoft 365 ha cambiado mucho. Microsoft cuenta ya con Migration Orchestrator y soluciones específicas para Exchange, OneDrive y SharePoint. Quest continúa ofreciendo una plataforma muy amplia para Microsoft 365, identidad y dispositivos. ShareGate ha evolucionado desde su tradicional fortaleza en SharePoint y Teams hacia una propuesta tenant-to-tenant más completa. BitTitan continúa desarrollando MigrationWiz y ha renovado recientemente su migración de chats privados. Cloudiway mantiene una cobertura amplia en Microsoft 365, cross-platform, Intune y dispositivos.

PowerShell y Microsoft Graph siguen siendo fundamentales, pero cumplen principalmente el papel de automatización, preparación y control. SPMT y Migration Manager solucionan otros escenarios de ingesta hacia Microsoft 365. Robocopy sigue siendo una herramienta excelente para archivos locales, pero no debe confundirse con una migración cloud. Por eso, preguntar simplemente “¿qué herramienta es mejor?” ofrece poca información. La pregunta útil es: ¿qué combinación de tecnología permite llevar este entorno concreto desde su estado actual hasta el tenant destino que queremos, conservando los datos y relaciones importantes y manteniendo un nivel de riesgo aceptable?

La respuesta empieza con un assessment, continúa con una comparativa técnica y debería confirmarse con un piloto antes de la migración masiva.

Documentación oficial recomendada

Microsoft – migraciones tenant-to-tenant.

• Microsoft – Microsoft 365 Migration Overview
• Microsoft – Plan a Microsoft 365 Tenant-to-Tenant Migration
• Microsoft – Migration Orchestrator Overview
• Microsoft – Running a Migration with Migration Orchestrator

Microsoft – Exchange, OneDrive y SharePoint.

• Microsoft – Cross-Tenant Mailbox Migration
• Microsoft – Cross-Tenant OneDrive Migration
• Microsoft – Cross-Tenant SharePoint Migration

Microsoft – Migration Manager y SPMT.

• Microsoft – SharePoint Migration Tool
• Microsoft – Migration Manager
• Microsoft – How Migration Manager Works

PowerShell y Microsoft Graph.

• Microsoft – Microsoft Graph PowerShell Overview
• Microsoft – Connect-ExchangeOnline
• Microsoft – Teams PowerShell Overview

Quest On Demand Migration.

• Quest – On Demand Migration
• Quest – On Demand Migration User Guide
• Quest – On Demand Migration Release Notes

ShareGate.

• ShareGate – Tenant-to-Tenant Migration
• ShareGate – Microsoft Teams Migration
• ShareGate – Migrate Release Notes

BitTitan MigrationWiz.

• BitTitan – Microsoft 365 Tenant Migrations
• BitTitan – MigrationWiz Licensing and Migration Types
• BitTitan – Teams Private Chat Migration

Cloudiway.

• Cloudiway – Official Migration Admin Guides
• Cloudiway – Microsoft 365 Tenant-to-Tenant Migration