Asistente de migración Microsoft 365: alcance y uso

Qué debe controlar un asistente de migración y qué decisiones siguen siendo humanas

Un asistente de migración de Microsoft 365 puede organizar operaciones, ayudar a preparar lotes y mostrar resultados, pero necesita un proyecto definido. Debe conocer qué objetos relacionar, qué datos trasladar y qué límites respetar. Si las cuentas de origen y destino no están correctamente asociadas, automatizar la transferencia puede extender un error de correspondencia a muchos usuarios en poco tiempo.

Antes de ejecutar un lote se revisa su lista de objetos y el destino previsto. El responsable valida las excepciones y confirma las condiciones de inicio. Esa aprobación resulta especialmente relevante si la operación tiene efectos sobre el origen o si la herramienta requiere que el destino esté en un estado determinado. El asistente debe utilizarse con esas condiciones documentadas, no como sustituto de su comprobación.

La automatización aporta valor cuando permite repetir un procedimiento conocido y obtener evidencia comprensible. El equipo debe saber qué ha intentado la herramienta, qué ha completado y qué necesita intervención. Un panel con un porcentaje global puede ocultar que una parte pequeña del lote contiene los datos o permisos más importantes para el negocio.

Cómo utilizar los errores para corregir el proceso

Un error debe investigarse antes de reintentar. Se localiza el objeto, el mensaje y la fase de ejecución, y se revisan los requisitos relacionados. Corregir una cuenta de destino o un permiso puede resolver una causa compartida por varios fallos; repetir la transferencia sin esa corrección solo añade tiempo y dificulta interpretar los informes.

El piloto también debe comprobar qué sucede con una operación repetida y con contenido que cambia. La capacidad de actualizar o reanudar depende del método. Al entregar el proyecto se conservan los lotes, correspondencias y resultados necesarios para explicar el estado final. Esta trazabilidad permite que otro administrador atienda una incidencia sin depender de quien ejecutó la primera migración.

Qué es realmente un asistente de migración Microsoft 365

Un asistente de migración Microsoft 365 es cualquier herramienta que simplifica y estructura determinadas operaciones necesarias para trasladar usuarios o información entre entornos Microsoft. Puede ser una aplicación instalada localmente, una plataforma SaaS, un wizard de configuración o un orquestador capaz de coordinar varias cargas de trabajo. La idea fundamental es que el administrador no tenga que ejecutar manualmente cada operación y mantener por separado cientos de scripts, hojas de cálculo y logs.

Por ejemplo, una herramienta puede descubrir automáticamente los buzones de origen, permitir seleccionar cuáles se migrarán, emparejarlos con sus usuarios de destino y ejecutar varias pasadas del contenido. Otra puede ir mucho más allá y relacionar al mismo tiempo Exchange, OneDrive, SharePoint, Microsoft Teams e identidad. La palabra “asistente” abarca herramientas muy distintas.

Qué no hace un asistente de migración

Una interfaz sencilla puede dar la impresión de que una migración es un proceso completamente automatizable. No lo es. La herramienta puede encontrar un Team, pero no sabe si ese Team corresponde a un proyecto terminado que debería archivarse. Puede encontrar 800 GB de documentos, pero no sabe cuáles tienen valor legal o cuáles son copias obsoletas. Puede copiar un buzón, pero no decide cuándo debe transferirse empresa.com al nuevo tenant.

Hay decisiones que siguen siendo responsabilidad del proyecto.

“Completed” tampoco significa “el usuario puede trabajar”. Un asistente puede decir que una tarea terminó correctamente porque consiguió copiar 30.000 objetos. La validación real consiste en comprobar después que el usuario: puede iniciar sesión, enviar correo, abrir documentos, acceder a los equipos correctos, utilizar aplicaciones críticas y trabajar con los permisos esperados.

Wizard, asistente y orquestador: diferencias importantes

Los tres términos se utilizan a menudo como sinónimos, pero técnicamente describen enfoques distintos.

Esta última diferencia es particularmente importante. Un proyecto puede disponer de excelentes asistentes independientes para Exchange y OneDrive y seguir teniendo problemas si nadie controla la secuencia en la que deben ejecutarse. El valor de un orquestador está precisamente en comprender que los workloads no son completamente independientes.

Cuándo merece la pena utilizar una plataforma guiada

En una migración de tres buzones pequeños puede resultar innecesario desplegar una plataforma sofisticada. A medida que aumenta el número de usuarios, workloads o dependencias, el beneficio crece rápidamente.

El volumen no es el único factor. Una migración de 30 usuarios puede ser más difícil que una de 300 si contiene muchos sitios SharePoint personalizados, identidades híbridas, varias aplicaciones empresariales y canales privados de Teams. La complejidad depende de las relaciones entre objetos, no únicamente del número de empleados.

Funciones que deberías exigir a un buen asistente de migración

No todas son necesarias en todos los proyectos, pero conviene saber qué comparar. Discovery real. La herramienta debería permitir entender qué existe antes de ejecutar. Un discovery útil no se limita a indicar “300 usuarios”. Debería ayudar a localizar workloads y excepciones que puedan modificar el alcance. Mapping configurable. El matching automático resulta muy útil, pero también debe existir alguna forma de controlar las excepciones.

El hecho de que: nombre.apellido@empresa-a.com deba corresponder a: n.apellido@empresa.com no siempre puede deducirse sin reglas de mapping. Pre-checks. Un asistente que descubre los problemas antes de migrar suele ahorrar mucho más tiempo que uno que únicamente proporciona buenos logs después del fallo. Migraciones incrementales. Cuando la tecnología y el workload lo permiten, los deltas son muy útiles.

Se puede copiar la mayor parte de la información días antes y trasladar durante el cutover únicamente aquello que cambió. No todas las tecnologías funcionan así. Algunas capacidades nativas de Microsoft son deliberadamente movimientos de una sola pasada. Reintentos controlados. En un proyecto grande siempre aparecerán incidencias: objetos bloqueados, permisos, throttling o elementos incompatibles. El asistente debería permitir identificar y reintentar únicamente los elementos necesarios.

Informes exportables

Los informes son necesarios no solo para TI, sino también para el cierre formal del proyecto. Hay que poder demostrar qué se migró, qué falló, qué se excluyó y qué debe tratarse manualmente.

Microsoft Migration Orchestrator

Microsoft 365 Migration Orchestrator es actualmente la opción de Microsoft para coordinar determinadas migraciones tenant-to-tenant de datos de usuario. La documentación oficial sigue indicando que la solución está en preview, por lo que su disponibilidad, licencias y comportamiento deben comprobarse nuevamente antes de diseñar una migración de producción. Microsoft soporta actualmente cuatro workloads dentro de un batch orquestado:

Referencia oficial: Microsoft – Migration Orchestrator Overview. Un detalle crítico: Orchestrator mueve contenido, no identidades. El administrador sigue siendo responsable de preparar correctamente los usuarios de destino. Eso significa que Migration Orchestrator no debe confundirse con una herramienta completa de migración de Microsoft Entra ID. También hay contenido fuera de alcance. Microsoft indica actualmente que la solución de Cross-Tenant User Data Migration no mueve los datos compartidos de: Teams, Channels y SharePoint Sites.

Estos elementos necesitan su estrategia correspondiente.

Cómo funciona actualmente Microsoft Migration Orchestrator

La parte interesante de Orchestrator no es simplemente que disponga de varios workloads, sino que intenta controlar su orden. Microsoft recomienda que, cuando un usuario vaya a migrar Exchange, OneDrive, chats y reuniones, estos workloads se ejecuten conjuntamente para que el orquestador gestione las dependencias. 1. Preparación e Identity Mapping. Los usuarios deben existir correctamente en ambos tenants y cumplir los requisitos de cada workload.

2. Validación. Microsoft proporciona una fase de validación independiente que puede repetirse antes de migrar. Comprueba elementos como: permisos, relaciones entre tenants, licencias e identity mappings. 3. Batch. Los usuarios se agrupan en batches. La documentación vigente establece un máximo de 100 usuarios por batch. 4. Pre-Cutover. Exchange puede comenzar a sincronizar contenido antes de la fecha de corte mientras los usuarios siguen trabajando en el buzón origen.

Microsoft recomienda actualmente enviar los batches aproximadamente dos semanas antes de la fecha CompleteAfterDate para permitir esta sincronización previa.

5. Cutover

Cuando llega CompleteAfterDate, Exchange realiza el cambio antes de que los otros workloads comiencen su movimiento final. Después se procesan OneDrive, chats y reuniones según el alcance seleccionado.

CodeTwo Office 365 Migration

CodeTwo Office 365 Migration es un ejemplo excelente de un asistente que tiene un objetivo muy claro: simplificar migraciones de Exchange y Microsoft 365 sin obligar al administrador a construir el procedimiento completo mediante PowerShell. Es una aplicación que puede instalarse en un equipo con conectividad hacia los tenants y que utiliza asistentes para configurar origen, destino y jobs. Qué puede migrar en tenant-to-tenant.

CodeTwo está orientado fundamentalmente a:

Provisioning y matching. Una de las funcionalidades útiles de CodeTwo es que puede ayudar a crear y licenciar usuarios en destino y realizar matching automático entre buzones. Esto reduce operaciones repetitivas cuando el alcance está fundamentalmente en Exchange. Delta Migration. CodeTwo permite realizar nuevas pasadas para copiar elementos que hayan aparecido después de la primera migración. Esto permite hacer un pre-stage del buzón y dejar para la ventana final una cantidad menor de datos.

¿Cuándo elegiría CodeTwo?. Cuando el correo es claramente el centro del proyecto y buscamos una interfaz administrativa guiada, sin necesidad de desplegar una plataforma multiworkload mucho más amplia. Si además debemos trasladar 80 Teams y 4 TB de SharePoint, CodeTwo debería considerarse una pieza para Exchange, no la solución completa. Referencia oficial: CodeTwo – Microsoft 365 Tenant-to-Tenant Migration.

ConnectWise Cloud Migration: la evolución del ecosistema SkyKick

SkyKick fue durante años una de las marcas más conocidas en migraciones cloud para partners Microsoft. ConnectWise adquirió SkyKick en 2024 y actualmente presenta estas capacidades dentro de su oferta ConnectWise Cloud Migration. Por tanto, para un artículo actualizado conviene hablar ya principalmente de ConnectWise Cloud Migration, explicando que procede del ecosistema SkyKick. Enfoque especialmente orientado a partners. ConnectWise mantiene un fuerte enfoque hacia MSPs y proveedores de servicios que ejecutan migraciones de clientes de forma recurrente.

Su oferta actual incluye suites para diferentes escenarios:

Tenant-to-tenant. Para migraciones entre tenants, ConnectWise destaca actualmente funcionalidades como: discovery, object matching, soporte multidominio, adaptación de mappings cuando cambian direcciones y procesos staged antes del cutover. La propia documentación comercial describe la posibilidad de realizar sincronizaciones previas y una delta final próxima al corte. Cuándo resulta especialmente interesante. En proyectos de correo y Microsoft 365 gestionados por partners que quieren automatizar muchas tareas repetitivas y disponer de un flujo operativo consistente entre clientes.

Antes de seleccionarlo para una migración multiworkload compleja, debe confirmarse qué workloads concretos están cubiertos por la suite contratada. Referencia oficial: ConnectWise – Cloud Migration.

ShareGate Migrate: de SharePoint a una propuesta tenant-to-tenant mucho más amplia

ShareGate ha cambiado notablemente durante 2026. Históricamente era habitual asociarlo principalmente con SharePoint, OneDrive y Teams. Su oferta tenant-to-tenant actual se presenta de forma mucho más amplia y cubre un flujo formado por: identidades → buzones → contenido. Identity Migration. ShareGate permite actualmente preparar y copiar usuarios y grupos de Microsoft Entra ID dentro de los planes compatibles. La función permite realizar mapping, detectar conflictos, crear identidades destino y asignar licencias.

Esto es relevante porque elimina una de las grandes limitaciones que tenían versiones anteriores del producto en proyectos tenant-to-tenant. Exchange Online. ShareGate también ha incorporado migración de mailboxes. Su oferta actual contempla diferentes tipos de buzones y funcionalidades relacionadas con calendarios, contactos, archivos online, reglas y otras propiedades soportadas. SharePoint y OneDrive. Siguen siendo cargas donde ShareGate tiene una experiencia especialmente amplia.

Su enfoque permite combinar migración con reorganización, selección de contenido y revisión de permisos. Microsoft Teams. ShareGate permite trabajar con: Teams, standard channels, private channels, archivos, permisos, tabs, apps, Planner y sitios SharePoint asociados, dentro de las características y limitaciones documentadas. Migraciones incrementales. La plataforma permite realizar nuevas pasadas para trasladar cambios producidos entre oleadas. Esto encaja bien en proyectos donde los usuarios deben continuar trabajando durante varios días o semanas.

Cuándo evaluaría ShareGate

Cuando SharePoint y Teams tienen un peso relevante y, especialmente, si se quiere reducir el número de herramientas necesarias para cubrir identidad, correo y contenido. Referencia oficial: ShareGate – Tenant-to-Tenant Migration.

Quest On Demand Migration

Quest On Demand Migration no funciona tanto como un wizard lineal, sino como una verdadera plataforma de migración Microsoft 365. Está especialmente orientada a escenarios de fusiones, adquisiciones, carve-outs, consolidaciones y proyectos con múltiples workloads. Quest documenta actualmente capacidades para:

Discovery y collections. Quest permite descubrir el entorno y trabajar con grupos lógicos de objetos, lo que facilita organizar pilotos y oleadas. Account Matching. El mapping de usuarios forma parte central de su enfoque. Esto es especialmente importante para SharePoint, OneDrive y Teams, donde los datos y permisos dependen de que los objetos de usuario estén correctamente relacionados. Coexistencia. Quest también tiene capacidades específicas para escenarios en los que los dos tenants deben continuar colaborando durante la transición.

Esto puede ser decisivo en una migración de varios meses. Cuándo lo evaluaría. En proyectos amplios de Microsoft 365 donde buscamos una consola única y necesitamos combinar varios workloads, identidad o coexistencia. Referencia oficial: Quest – On Demand Migration.

BitTitan MigrationWiz

MigrationWiz utiliza un enfoque basado en proyectos y licencias por tipo de migración. Esto hace que el administrador configure un proyecto dependiendo de aquello que necesita trasladar. Tipos de licencia. BitTitan documenta actualmente diferentes opciones, entre ellas:

Teams Private Chat. BitTitan renovó durante julio de 2026 el procedimiento de Teams Private Chat. La documentación actual establece un proyecto específico y una concurrencia máxima de 20 usuarios para estas tareas. Este tipo de cambios demuestra por qué el soporte de Teams debería comprobarse siempre justo antes del proyecto. Cuándo evaluaría BitTitan. Cuando queremos una plataforma SaaS madura, especialmente para Exchange y workloads asociados, con proyectos relativamente estructurados y una extensa base documental.

Referencia oficial: BitTitan – Microsoft 365 Tenant Migration.

Comparativa práctica de asistentes y plataformas de migración

Si la migración es casi exclusivamente de correo

No siempre tiene sentido desplegar una plataforma capaz de migrar AD, dispositivos, Teams, SharePoint y Power BI si el alcance real son 70 buzones. En un escenario centrado en Exchange conviene comparar:

Si hay Exchange, OneDrive, SharePoint y Teams

En este caso la necesidad cambia completamente. El valor ya no está únicamente en que cada workload pueda migrarse, sino en disponer de una forma coherente de: descubrir, mapear, ejecutar, monitorizar y validar todas las cargas. Quest y ShareGate resultan especialmente interesantes en este tipo de proyectos por su amplitud actual. BitTitan y otras plataformas también pueden cubrir diferentes workloads mediante proyectos o bundles.

Microsoft Orchestrator puede ser una alternativa nativa interesante cuando los workloads incluidos encajan con el alcance, aunque SharePoint Sites y las estructuras compartidas de Teams necesitan seguir analizándose aparte.

Si Teams y SharePoint son críticos

Teams debe cambiar la forma en la que evaluamos la herramienta. Decir simplemente que una plataforma “migra Teams” resulta insuficiente.

En estos escenarios, ShareGate y Quest merecen normalmente una evaluación detallada, junto con BitTitan o alternativas especializadas dependiendo del alcance concreto.

Si también hay que mover identidad

En una fusión o carve-out real, mover documentos puede ser solo la mitad del trabajo. También puede ser necesario tratar: usuarios, grupos, password strategy, Active Directory, dispositivos, Microsoft Entra Join, Intune y aplicaciones. Microsoft Migration Orchestrator no resuelve por sí mismo la migración de identidades. Quest dispone de una familia específica de capacidades para Active Directory y Microsoft Entra ID.

ShareGate ha incorporado durante 2026 la posibilidad de copiar identidades entre tenants dentro de sus planes Pro y Enterprise. Por tanto, el peso de la identidad puede modificar notablemente qué herramienta resulta más adecuada.

Si los tenants van a convivir durante semanas o meses

Una herramienta puede ser excelente copiando datos y, sin embargo, no ser la mejor para una migración de seis meses. Cuando existen oleadas largas, necesitamos pensar también en: mail routing, free/busy, colaboración Teams, acceso a documentos, identity synchronization y experiencia de usuario. Quest dispone de funcionalidades expresamente orientadas a determinados escenarios de coexistencia. Microsoft permite construir coexistencia mediante diferentes servicios y configuraciones, pero normalmente hay que diseñarlos y coordinarlos como piezas independientes.

Hasta dónde conviene automatizar

Automatizar una tarea repetitiva suele ser positivo. Automatizar una decisión que no comprendemos puede ser peligroso. Automatización ideal. Hay operaciones que suelen ser buenas candidatas: discovery, matching basado en reglas, creación de jobs, reintentos, exportación de logs y reporting. Decisiones que deberían mantener supervisión humana. Especialmente: resolución de mappings ambiguos, usuarios duplicados, eliminación de contenido, permisos sensibles, cambios de dominio y aceptación del resultado.

La herramienta debería reducir trabajo mecánico para que el equipo técnico pueda dedicar más atención precisamente a estas excepciones.

Qué permisos estamos concediendo al asistente

Este punto merece tanta atención como las funcionalidades. Una herramienta tenant-to-tenant puede necesitar leer y escribir: correo, documentos, grupos, SharePoint, chats, Teams e identidades. Antes de conceder consentimiento conviene revisar:

El decommission debe formar parte del proyecto. Cuando termina la migración deberían revisarse: Enterprise Applications, App Registrations, service accounts, temporary users, certificados y consentimientos utilizados exclusivamente para la migración.

Proceso recomendado utilizando un asistente de migración

La herramienta debería entrar después del assessment, no antes. 1. Analizar el entorno. Inventariar usuarios, buzones, OneDrive, SharePoint, Teams, dominios, aplicaciones, identidad y requisitos legales. 2. Definir el alcance. Documentar qué se migra, qué se archiva, qué se recrea y qué queda excluido. 3. Elegir arquitectura. Decidir identidad, dominios, coexistencia, secuencia de workloads y modelo de cutover. 4. Seleccionar herramienta.

Comparar plataformas contra el alcance real. 5. Preparar permisos. Autorizar la herramienta en origen y destino y documentar exactamente qué se ha concedido. 6. Ejecutar discovery propio de la herramienta. Comparar el resultado con el inventario previo para localizar discrepancias. 7. Mapping. Resolver automáticamente los casos simples y revisar manualmente los ambiguos. 8. Piloto. Utilizar casos representativos, no únicamente usuarios fáciles.

9. Premigración. Cuando el método lo soporte, trasladar gran parte de los datos antes del cutover. 10. Oleadas. Migrar usuarios y workloads de forma controlada. 11. Cutover. Coordinar identidad, dominio, DNS, Exchange y aplicaciones según el runbook. 12. Validación. Combinar informes de la herramienta con pruebas funcionales. 13. Hypercare. Mantener soporte reforzado durante los primeros días. 14. Decommission. Retirar permisos temporales y cerrar el tenant origen únicamente cuando el proyecto lo permita.

Por qué el piloto sigue siendo imprescindible aunque exista un asistente

La documentación describe lo que una herramienta soporta. El piloto demuestra qué resultado obtiene con tus datos.

Después del piloto puede ocurrir algo perfectamente válido: que decidamos cambiar de herramienta o utilizar una combinación distinta.

Errores frecuentes al utilizar asistentes de migración

Checklist antes de contratar un asistente de migración Microsoft 365

Preguntas frecuentes sobre asistentes de migración Microsoft 365

¿Un asistente de migración decide por sí solo el destino de los datos?

Puede ofrecer ayudas y valores predeterminados, pero el destino debe responder a un diseño aprobado. Hay que revisar correspondencias de identidad, ubicaciones y permisos antes de ejecutar operaciones. Automatizar una decisión incorrecta no la corrige y puede extender sus consecuencias a muchos objetos del entorno.

¿Qué debe comprobarse antes de lanzar un lote?

La lista de objetos, sus destinos, los requisitos del método y las excepciones deben estar revisados. También se confirma que existen permisos y licencias adecuados para el alcance. El lote debe tener un criterio de éxito y un responsable de validación, especialmente si su ejecución modifica el origen o condiciona operaciones posteriores.

¿Se debe reintentar un error hasta que desaparezca?

Primero hay que entender la causa y el comportamiento del método ante repeticiones. Algunos errores requieren corregir preparación, acceso o contenido; otros reflejan una limitación. Los reintentos sin diagnóstico pueden añadir duplicados o dificultar los informes. La corrección se prueba en una muestra antes de extenderla al lote afectado.

¿Qué evidencia debe conservar el administrador?

Deben conservarse las correspondencias, los lotes ejecutados, los informes y las decisiones que explican las diferencias del resultado. También se documentan requisitos y pasos de corrección relevantes. Esa información facilita aceptar la entrega y atender incidencias posteriores sin depender únicamente de capturas del panel o de la memoria del operador.

Recomendaciones finales: el mejor asistente es el que automatiza el proyecto correcto

Un asistente de migración Microsoft 365 puede ahorrar cientos de operaciones manuales, pero su valor depende de que se utilice dentro de una arquitectura bien diseñada. Microsoft Migration Orchestrator resulta especialmente interesante porque Microsoft empieza a coordinar de forma nativa Exchange, OneDrive, chats y reuniones teniendo en cuenta las dependencias entre workloads. Pero continúa en preview y no constituye por sí mismo una migración completa de todo un tenant.

CodeTwo sigue siendo una opción muy interesante cuando el proyecto se concentra en Exchange y se busca una experiencia guiada con matching, provisioning, jobs y deltas. ConnectWise Cloud Migration continúa el enfoque de automatización que durante años caracterizó a SkyKick y resulta especialmente relevante para partners que necesitan procesos repetibles. ShareGate ha evolucionado considerablemente y actualmente puede trabajar con identidades, buzones y contenido dentro de una estrategia tenant-to-tenant mucho más amplia.

Quest On Demand Migration sigue destacando como plataforma multiworkload para proyectos complejos de Microsoft 365, identidad, dispositivos y coexistencia, mientras BitTitan mantiene un modelo SaaS muy consolidado basado en proyectos y licencias por workload. Por eso, la elección no debería empezar preguntando “¿qué asistente es el mejor?”. Debería empezar preguntando: ¿qué necesitamos migrar, qué queremos conservar exactamente y qué operaciones queremos automatizar sin perder control sobre el proyecto?

Una vez contestadas esas preguntas, elegir la herramienta es mucho más sencillo.

Documentación oficial recomendada

Microsoft Migration Orchestrator.

• Microsoft – Migration Orchestrator Overview
• Microsoft – Preparing Users for Migration Orchestrator
• Microsoft – Running a Migration with Migration Orchestrator
• Microsoft – Migration Orchestrator FAQ
• Microsoft – Plan a Microsoft 365 Tenant-to-Tenant Migration

CodeTwo Office 365 Migration.

• CodeTwo – Office 365 Migration
• CodeTwo – Tenant-to-Tenant Migration
• CodeTwo – Microsoft 365 Tenant-to-Tenant Walkthrough

ConnectWise Cloud Migration.

• ConnectWise – Cloud Migration
• ConnectWise – Acquisition of SkyKick

ShareGate.

• ShareGate – Tenant-to-Tenant Migration
• ShareGate – Exchange Online Mailbox Migration
• ShareGate – Entra ID Migration
• ShareGate – Microsoft Teams Migration
• ShareGate – Migrate Release Notes

Quest On Demand Migration.

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

BitTitan MigrationWiz.

• BitTitan – Microsoft 365 Tenant Migrations
• BitTitan – Which Migration License Do I Need?
• BitTitan – Teams Private Chat Migration Guide