Quest On Demand Migration: guía entre tenants

Cómo preparar un proyecto de Quest On Demand Migration con correspondencias verificadas

Quest On Demand Migration necesita una preparación coherente de los objetos que relaciona entre origen y destino. Antes de iniciar transferencias se revisa qué cuenta continuará utilizando cada persona, qué cargas se incluyen y qué objetos ya existen en el tenant de llegada. La coincidencia de un nombre visible no debería utilizarse como única prueba de que dos objetos representan a la misma identidad.

En una adquisición pueden convivir cuentas antiguas, duplicadas y personas con acceso previo a ambos entornos. El responsable del proyecto debe resolver esas situaciones y aprobar las correspondencias. Después se comprueba cómo las utiliza el módulo y el procedimiento elegidos. Esta revisión evita que un error inicial se propague a datos y permisos de varios servicios.

La preparación también debe confirmar requisitos, licencias y permisos de las funciones que se utilizarán. La plataforma agrupa distintos componentes, pero no conviene suponer que todos realizan las mismas operaciones ni que tienen idénticas limitaciones. El diseño debe especificar qué resultado se espera de cada carga y qué tareas quedan fuera de la herramienta o necesitan intervención adicional.

Cómo utilizar los lotes y los informes para controlar el resultado

Los lotes deben organizarse de forma que el equipo pueda interpretar los resultados y los responsables puedan validar el trabajo. Una agrupación solo por número de usuarios puede separar personas y recursos que dependen entre sí. Conviene considerar esos vínculos y los procesos del departamento cuando se define la secuencia, además del volumen de información que se va a tratar.

Durante el piloto se comprueban preparación, ejecución, errores y reintentos admitidos para la carga elegida. El informe se contrasta con pruebas funcionales y se conservan los identificadores necesarios para investigar diferencias. La aceptación debe explicar tanto los resultados correctos como los elementos omitidos o pendientes, evitando que un porcentaje global oculte un caso de alto impacto para la organización.

Qué es Quest On Demand Migration

Quest On Demand Migration es una plataforma SaaS de Quest diseñada para ayudar en proyectos de migración y consolidación de entornos Microsoft. En Microsoft 365 se utiliza principalmente en escenarios tenant-to-tenant, aunque la familia de productos también contempla Active Directory, Microsoft Entra ID y dispositivos. Su propuesta es especialmente útil en proyectos donde existen varios workloads. En vez de abordar el correo con una herramienta, SharePoint con otra y Teams con procedimientos independientes, ODM permite gestionar gran parte del proyecto desde el ecosistema On Demand.

Quest documenta actualmente capacidades para Exchange Online, OneDrive, SharePoint Online, Microsoft Teams, Microsoft 365 Groups, chats, Power BI, dominios de correo, Active Directory y Microsoft Entra ID. Eso no significa que exista exactamente el mismo procedimiento o licenciamiento para todos ellos. ODM está compuesto por diferentes workspaces, servicios y capacidades, y algunas funciones requieren licencias adicionales. Documentación oficial: Quest – On Demand Migration.

Qué papel desempeña Quest en el proyecto

La herramienta es más útil cuando se entiende como una plataforma de ejecución de una estrategia de migración previamente diseñada. Por ejemplo, Quest puede descubrir un Team y migrarlo, pero no puede decidir por la empresa si ese Team lleva tres años sin utilizarse y debería eliminarse. Puede copiar documentos de SharePoint, pero no decidir si un modelo de permisos heredado debe mantenerse en el nuevo entorno. Puede ayudar con el correo, pero la organización sigue teniendo que decidir cuándo libera el dominio corporativo y cambia los registros DNS.

Esa separación entre herramienta y arquitectura es fundamental.

Cuándo tiene sentido utilizar Quest On Demand Migration

Quest puede utilizarse tanto en migraciones relativamente sencillas como en proyectos complejos, pero su valor suele crecer cuando hay varias cargas de trabajo y muchas relaciones entre ellas.

Microsoft también continúa ampliando sus propias capacidades nativas de cross-tenant migration. Por eso la decisión entre Quest, Microsoft o una combinación de ambos debe tomarse después de conocer el escenario, y no basándose únicamente en cómo se resolvían estos proyectos hace unos años. Referencia Microsoft: Microsoft – Plan a Microsoft 365 tenant-to-tenant migration.

Qué puede migrar Quest On Demand Migration

Hablar de “migrar Microsoft 365” puede resultar demasiado genérico. Cada workload almacena información diferente y tiene sus propias limitaciones.

“Soportado” no significa “todo se conserva exactamente igual”

Este matiz es especialmente importante para Teams y SharePoint. Que una herramienta soporte un workload no significa que todas las propiedades, aplicaciones, relaciones y experiencias de usuario puedan reproducirse al 100 % en el nuevo tenant. Las APIs de Microsoft, los modelos de seguridad y la propia arquitectura de Microsoft 365 establecen límites. Por eso Quest mantiene en su documentación apartados específicos de What We Migrate, Limitations, Considerations y Prerequisites para cada workload.

En una propuesta de migración conviene describir el alcance por objeto: por ejemplo, “Teams y canales estándar”, “chats 1:1”, “archivos asociados”, “Planner no incluido”, etc., en lugar de utilizar simplemente la frase “migración completa de Teams”.

Quest frente a las herramientas nativas de Microsoft

Esta comparación es hoy mucho más relevante que hace unos años. Microsoft ya dispone de capacidades nativas para Exchange Online, OneDrive y SharePoint y está desarrollando una experiencia de Migration Orchestrator para movimientos coordinados. Quest sigue teniendo ventajas en determinados proyectos, especialmente cuando la organización busca una consola común, discovery, mapping, remigraciones, coexistencia o cobertura multiworkload.

No existe una respuesta universal. En algunos proyectos el método nativo será suficiente y más conveniente. En otros, el valor operativo de Quest justificará su licenciamiento.

Cómo plantear la arquitectura de una migración con Quest

Una migración con ODM debería comenzar en una hoja de arquitectura, no en el botón Create Project. Lo primero es decidir cuál será el tenant definitivo, qué usuarios se moverán, qué dominio utilizarán, qué datos se trasladarán y durante cuánto tiempo deben convivir ambos entornos. A partir de ahí se diseña el orden de los workloads. El principio general es resolver primero la identidad y las correspondencias entre objetos. Después se preparan y migran las cargas de datos. Finalmente se ejecutan aquellos cambios que necesariamente deben concentrarse en el cutover, como el dominio corporativo y determinadas configuraciones de correo o aplicaciones.

Assessment e inventario antes de configurar Quest

Quest puede realizar discovery de muchos objetos, pero eso no sustituye un assessment funcional. La herramienta puede encontrar un sitio SharePoint; el negocio debe decidir si ese sitio sigue siendo necesario. Un buen assessment busca tres cosas: qué existe, qué depende de qué y qué merece la pena trasladar.

Usa el proyecto para limpiar, no para duplicar problemas

Una consolidación de tenants es un buen momento para eliminar Teams sin actividad, sitios SharePoint abandonados, cuentas antiguas y permisos que ya no deberían existir. Migrar absolutamente todo suele ser más fácil de decidir, pero no necesariamente mejor. Incrementa el volumen, el coste, el tiempo de ejecución y la cantidad de información que habrá que gobernar posteriormente.

Permisos y seguridad de Quest On Demand Migration

Una plataforma de migración necesita acceder a una gran cantidad de información. Por eso los permisos deben formar parte del diseño de seguridad del proyecto y no tratarse simplemente como una pantalla de consentimiento que hay que aceptar. Quest mantiene una Permissions Reference Guide en la que documenta los permisos necesarios por workload y dispone de opciones para reducir el alcance de determinados accesos.

SharePoint y Sites.Selected. Quest documenta actualmente el uso de Sites.Selected para determinados escenarios de SharePoint. Este modelo permite autorizar a la aplicación únicamente sobre sitios concretos, en lugar de conceder acceso indiscriminado a todas las colecciones del tenant. En proyectos donde el tenant contiene información que no forma parte de la migración, este enfoque puede ayudar a aplicar mejor el principio de mínimo privilegio.

Exchange y RBAC for Applications. Quest también documenta compatibilidad con RBAC for Applications en Exchange Online, que permite delimitar el ámbito de acceso de la aplicación utilizada para migrar buzones. Es una mejora importante frente a modelos donde la aplicación dispone automáticamente de acceso global a todo Exchange Online. Microsoft Teams. Teams presenta un escenario más complejo porque determinadas operaciones dependen de Microsoft Graph y pueden requerir permisos de aplicación, permisos delegados y cuentas temporales de servicio para determinadas tareas.

El diseño del proyecto debería documentar qué aplicaciones de Quest se autorizan, qué permisos reciben, qué cuentas de servicio se utilizan y qué elementos deben retirarse o revisarse al finalizar. Documentación oficial: Quest – On Demand Migration Permissions Reference Guide.

Discovery y mapping: la base de una migración correcta

Uno de los conceptos más importantes de ODM es el matching o mapping. La herramienta necesita saber que ana@empresa-antigua.com en el tenant de origen corresponde a ana@empresa.com en el tenant destino. La misma lógica afecta a grupos y otros objetos. Un error de mapping puede traducirse en datos asociados al usuario equivocado, permisos que no se reconstruyen correctamente o chats cuyos participantes no existen en destino.

Qué debe comprobarse antes de aprobar el mapping.

Para entornos grandes, conviene revisar el resultado del matching automático y utilizar mapping explícito para las excepciones.

Dominios personalizados, DNS y coexistencia

Quest puede facilitar determinadas fases de coexistencia, pero el dominio corporativo sigue estando sujeto a las reglas de Microsoft 365. Un dominio como empresa.com debe liberarse del tenant de origen antes de incorporarse plenamente al tenant destino. Eso obliga a encontrar y cambiar todas las referencias existentes.

Domain Rewrite

Quest dispone de una capacidad denominada Domain Rewrite, orientada a determinados escenarios de coexistencia de correo. El servicio puede reescribir direcciones para ayudar a que los usuarios mantengan una identidad de correo coherente mientras están repartidos entre dos entornos durante la transición. Su despliegue tiene implicaciones en mail flow, conectores, SPF y DKIM, por lo que debe diseñarse como parte de la arquitectura de coexistencia y no activarse de forma aislada.

Documentación oficial: Quest – Domain Rewrite Quick Start Guide. Free/busy entre tenants. Quest también ofrece capacidades de coexistencia para Exchange que pueden ayudar a mantener la visibilidad de calendario durante una migración por fases. Esto es especialmente útil cuando parte de la empresa ya está en el nuevo tenant y otra parte permanece en el origen durante varias semanas. Referencia oficial: Quest – Exchange Online migration and coexistence.

Migrar Exchange Online con Quest

Exchange suele ser el workload que define el éxito percibido de la migración. Los usuarios pueden tolerar que un enlace de SharePoint necesite corregirse, pero cualquier interrupción prolongada del correo genera inmediatamente un problema de negocio. ODM permite trabajar con buzones de Exchange Online y coordinar la migración con otras cargas como OneDrive, SharePoint y Teams.

Qué analizar antes de empezar

No todos los buzones son iguales. Un usuario con 5 GB de correo y sin delegaciones es muy diferente de un directivo con archivo online, asistentes con Full Access y varias direcciones SMTP.

Premigración y sincronización final

Una de las ventajas habituales de utilizar una herramienta especializada es poder separar el movimiento de datos del momento en que el usuario cambia de tenant. Se puede migrar una parte importante del contenido con antelación y ejecutar posteriormente tareas adicionales para acercar el destino al estado actual del origen antes del cutover, siempre siguiendo el comportamiento documentado por Quest para la carga y opciones utilizadas.

Esto ayuda a reducir la cantidad de información que debe tratarse durante la ventana final. El correo no termina en el buzón. Durante el cutover también deben resolverse: MX, Autodiscover, SPF, DKIM, DMARC, aliases, mail routing, Outlook, móviles, aplicaciones SMTP y servicios de seguridad de terceros. Por eso Exchange debe tener un runbook específico para la ventana de cambio. Referencia oficial: Quest – Exchange Online Migration.

Migrar OneDrive con Quest

OneDrive necesita un enfoque diferente al mecanismo cross-tenant nativo de Microsoft. En Quest, el OneDrive destino debe estar aprovisionado antes de iniciar determinadas tareas de migración. La documentación actual recomienda que esté provisionado al menos 24 horas antes. Este detalle es especialmente importante si se está comparando Quest con el mecanismo nativo de Microsoft, porque en Cross-tenant OneDrive Migration de Microsoft sucede prácticamente lo contrario: el sitio destino no debe existir previamente.

Sharing y orden de migración. La documentación de Quest destaca además una consideración importante para permisos compartidos: cuando un usuario comparte contenido de su OneDrive con otro, conviene que el OneDrive del propietario se migre antes que el del usuario que recibe el acceso. De lo contrario, determinados permisos compartidos pueden no conservarse como se esperaba. Por eso no siempre conviene crear las oleadas únicamente por departamento. También deben analizarse las relaciones de sharing entre usuarios.

Qué validar después

La validación debería combinar volumen e interacción real. No basta con comparar el número de archivos.

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

Migrar SharePoint Online con Quest

SharePoint es uno de los workloads donde el assessment previo tiene mayor impacto. La propia documentación de Quest separa claramente descubrimiento, assessment, matching y migración. Esto permite analizar un sitio antes de decidir si debe trasladarse. ODM puede copiar, entre otros elementos, metadatos relevantes como Created Date, Created By, Last Modified Date y Last Modified By, lo que puede resultar importante en repositorios documentales donde conservar contexto histórico es necesario.

No todos los sitios deberían tratarse igual

Un sitio de proyecto con una biblioteca y veinte usuarios puede migrarse de forma relativamente sencilla. Un portal departamental con permisos únicos, listas, Power Apps, automatizaciones y external sharing necesita pruebas específicas.

Premigration Assessment. Quest dispone de informes de premigración que ayudan a identificar problemas antes de mover el contenido. Estos informes son particularmente útiles para encontrar objetos o configuraciones que requieren tratamiento especial. Conviene utilizarlos antes del piloto y repetirlos si se producen cambios importantes en SharePoint durante el proyecto.

Permisos limitados con Sites.Selected

En proyectos donde solo se migrará una parte de SharePoint, la posibilidad de utilizar Sites.Selected puede reducir significativamente el ámbito al que accede la aplicación de migración. Esto permite plantear una configuración más restrictiva que conceder permisos tenant-wide innecesarios. Referencia oficial: Quest – SharePoint Migration.

Migrar Microsoft Teams con Quest

Quest dispone de un workspace específico para Microsoft Teams Migration. La herramienta migra Microsoft Teams y los Microsoft 365 Groups asociados y dispone además de funciones específicas para conversaciones y chats. Teams, sin embargo, sigue siendo una de las partes más delicadas de cualquier tenant-to-tenant porque la información no reside en un único servicio. Los archivos de los canales dependen de SharePoint. Los archivos compartidos en chats pueden depender de OneDrive. Las reuniones dependen de Exchange. Los miembros se basan en identidades y grupos. Aplicaciones como Planner, OneNote o apps de terceros añaden más relaciones.

Orden de migración

Quest recomienda actualmente migrar los chats después de que se hayan tratado OneDrive, buzones, SharePoint y Teams, y después de que las cuentas estén correctamente emparejadas. Tiene sentido: si los participantes todavía no están mapeados o los archivos a los que hace referencia una conversación no existen en destino, la migración del chat tiene menos posibilidades de conservar correctamente el contexto.

No prometas “Teams completo” sin definir qué significa. Para una propuesta comercial o técnica es mucho más seguro especificar cada componente. Esto evita que el cliente entienda que absolutamente todas las apps, pestañas, conversaciones, reuniones y relaciones del entorno original aparecerán idénticas después del cambio. Referencia oficial: Quest – Microsoft Teams Migration.

Active Directory, Microsoft Entra ID y dispositivos

Una de las diferencias más interesantes de la plataforma Quest frente a una herramienta centrada exclusivamente en datos es que puede ampliar el proyecto hacia la identidad y los endpoints. On Demand Migration for Active Directory está orientado a consolidar y migrar usuarios, grupos y dispositivos entre Active Directory, Microsoft Entra ID y entornos híbridos. Quest documenta escenarios como:

Dispositivos Entra joined e Intune

Quest dispone de capacidades específicas para mover dispositivos Windows 10 y Windows 11 entre escenarios domain-joined, hybrid y Entra-joined. En determinados casos puede cambiar también la inscripción de Intune hacia el tenant destino. Esto puede resultar especialmente interesante en un carve-out donde no solo se trasladan los datos del usuario, sino también su portátil y su perfil. La migración de endpoints, no obstante, debería tener su propio piloto. Windows Hello, certificados, Wi-Fi, VPN, aplicaciones, Intune y Conditional Access pueden modificar la experiencia del usuario.

Referencia oficial: Quest – Active Directory and Entra ID Migration.

Power BI, Power Platform y aplicaciones

Los workloads más visibles de Microsoft 365 no son necesariamente los que provocarán el mayor problema después de la migración. Una aplicación empresarial que utiliza el tenant antiguo para autenticación puede detener un proceso crítico aunque todos los buzones hayan migrado correctamente. Power BI. Quest incluye Power BI dentro de las capacidades de la plataforma, pero un proyecto de Power BI debe analizar elementos como workspaces, datasets, semantic models, gateways, credenciales, conexiones, refresh y permisos.

No debería tratarse como una simple copia de archivos. Power Platform. Power Apps y Power Automate pueden estar conectados con SharePoint, Outlook, Dataverse, SQL, Teams y aplicaciones externas. Por ello, incluso cuando el contenido relacionado se migra, las conexiones pueden necesitar reautenticación o reconstrucción. Microsoft dispone además de procedimientos específicos para determinadas migraciones tenant-to-tenant de Power Platform. Referencia oficial Microsoft: Microsoft – Power Platform tenant-to-tenant migrations.

Enterprise Applications y App Registrations. El assessment también debería registrar: Enterprise Applications, App Registrations, Service Principals, secretos, certificados, API permissions, SCIM, SSO, redirect URIs y automatizaciones basadas en Microsoft Graph. Muchos de estos elementos contienen identificadores propios del tenant y tendrán que reconfigurarse en destino.

Cómo preparar un piloto con Quest que realmente sirva

Un buen piloto no consiste en seleccionar cinco usuarios aleatorios. Debe representar la complejidad que aparecerá después en producción. Por ejemplo, si existen usuarios con archivos online, Teams con canales privados, OneDrive de gran tamaño o asistentes que gestionan buzones de dirección, alguno de esos casos debe aparecer en el piloto.

El piloto debe reproducir el procedimiento de producción: matching, migración, cambio de identidad cuando aplique, configuración del cliente y validación final.

Premigración y migración por oleadas

Una de las razones para utilizar una plataforma especializada es poder desacoplar parte del movimiento de datos del día del cutover. Cuando el workload lo permite, se puede realizar una primera migración y posteriormente ejecutar nuevas tareas para capturar cambios antes del corte. Esto permite que la ventana final se concentre principalmente en: últimos cambios de datos, dominio, DNS, identidad, mail flow, aplicaciones y experiencia del usuario.

Collections y lotes. En proyectos grandes conviene crear grupos lógicos de usuarios y recursos. Las oleadas pueden organizarse por departamento, país, sede o dependencia técnica. No siempre debe seguirse exclusivamente el organigrama. Si diez usuarios comparten continuamente documentos entre sus OneDrive, puede resultar conveniente moverlos juntos aunque pertenezcan a departamentos diferentes.

Cómo preparar el cutover con Quest

El cutover es el momento donde coinciden la herramienta y todos los elementos que Quest no puede decidir automáticamente: dominio, DNS, aplicaciones, usuarios y comunicación. Conviene preparar un runbook con hora, responsable, resultado esperado y criterio de rollback para cada acción.

Validación y soporte posterior

Uno de los mayores errores es considerar una tarea en estado Completed como prueba suficiente de que la migración ha terminado correctamente. El job demuestra que la herramienta ha finalizado una operación. No demuestra que el usuario pueda trabajar. La validación debería hacerse en dos niveles. Validación técnica.

Validación funcional. Después debe entrar en juego el usuario o el propietario del servicio. El responsable de Finanzas es quien mejor sabe si puede acceder a la biblioteca que utiliza para cierres mensuales. El asistente de dirección sabe si puede abrir el calendario del director. El propietario de una aplicación sabe si sigue recibiendo datos. La combinación de ambas validaciones es mucho más fiable que revisar únicamente estadísticas de Quest.

Hypercare. Durante los primeros días conviene mantener soporte reforzado. Muchas incidencias aparecen cuando el usuario intenta realizar una tarea que no utiliza todos los días. El hypercare también permite encontrar patrones. Si veinte usuarios presentan exactamente el mismo problema, probablemente existe una configuración común que debe corregirse, no veinte incidencias independientes.

Errores frecuentes al utilizar Quest On Demand Migration

Preguntas frecuentes sobre Quest On Demand Migration

¿Qué hay que preparar antes de usar Quest On Demand Migration?

Hay que definir las cargas, los objetos y las correspondencias de identidad, y comprobar los requisitos del procedimiento elegido. También se revisa el estado del destino, las licencias y los permisos necesarios. La configuración debe responder al alcance aprobado; una coincidencia de nombres o un valor predeterminado no sustituye esa revisión.

¿Todos los módulos de Quest tienen el mismo alcance?

No debe suponerse. Cada carga y función necesita comprobar sus requisitos, capacidades y limitaciones vigentes. El proyecto debe indicar qué resultado obtendrá el usuario y qué requiere reconstrucción o trabajo adicional. Esa revisión permite planificar y validar sin trasladar a todo el entorno las expectativas de una demostración de una sola función.

¿Cómo deben organizarse los lotes?

Se consideran identidades, recursos y dependencias de trabajo además del volumen. Los responsables deben poder validar lo incluido en cada fase y comprender qué permanece temporalmente en origen. El piloto aporta información para ajustar la agrupación y el calendario, evitando separar componentes que necesitan funcionar coordinadamente durante la transición.

¿Basta el informe de Quest para aceptar la migración?

El informe aporta evidencia técnica, pero debe contrastarse con las pruebas de uso incluidas en el alcance. Se revisan errores, elementos omitidos y diferencias, y se comprueban acceso, datos y procesos con cuentas representativas. La aceptación registra esos resultados y las excepciones aprobadas, con sus responsables de seguimiento.

Recomendaciones finales: Quest es potente, pero la migración sigue necesitando arquitectura

Quest On Demand Migration es una de las plataformas más completas para abordar migraciones tenant-to-tenant de Microsoft 365. Su cobertura de Exchange, OneDrive, SharePoint, Teams, identidad, dispositivos y coexistencia permite abordar proyectos que van mucho más allá de copiar buzones. Su mayor valor aparece cuando existen muchos workloads y dependencias. Discovery, matching, tareas por lotes, capacidades de premigración, reporting y los módulos específicos de Teams, Active Directory o Domain Rewrite pueden simplificar proyectos que, de otro modo, requerirían coordinar numerosas herramientas y procedimientos independientes.

Pero utilizar Quest no elimina los principales desafíos de una migración. El dominio debe seguir planificándose, las aplicaciones deben reconfigurarse, los permisos deben validarse y los usuarios necesitan saber qué cambia. Además, las capacidades nativas de Microsoft 365 han evolucionado mucho. Hoy es razonable comparar Quest con Cross-tenant Mailbox Migration, OneDrive, SharePoint y Migration Orchestrator antes de escoger la arquitectura definitiva.

Por eso, el orden correcto debería ser siempre: assessment, definición de alcance, diseño de identidad y coexistencia, selección de herramientas, piloto, premigración, oleadas, cutover, validación y hypercare. La herramienta se elige como consecuencia de ese análisis, no al revés.

Documentación oficial recomendada

Quest On Demand Migration es una plataforma que se actualiza regularmente. Antes de ejecutar un proyecto conviene consultar la documentación vigente del workload concreto. Quest On Demand Migration.

• Quest – On Demand Migration
• Quest – On Demand Migration User Guide
• Quest – Permissions Reference Guide
• Quest – On Demand Migration Technical Documentation

Exchange Online.

• Quest – Exchange Online Migration
• Quest – On Demand Migration Exchange User Guide

OneDrive.

• Quest – OneDrive Migration documentation
• Quest – OneDrive Migration FAQ

SharePoint.

• Quest – SharePoint Migration
• Quest – SharePoint Migration User Guide

Microsoft Teams.

• Quest – Microsoft Teams Migration
• Quest – Teams and Chat Migration documentation

Active Directory, Entra ID y dispositivos.

• Quest – Active Directory and Entra ID Migration
• Quest – Device Migration
• Quest – On Demand Migration Active Directory User Guide

Coexistencia y Domain Rewrite.

• Quest – Domain Rewrite Quick Start Guide

Documentación Microsoft relacionada.

• Microsoft – Plan a Microsoft 365 tenant-to-tenant migration
• Microsoft – Cross-tenant Mailbox Migration
• Microsoft – Cross-tenant OneDrive Migration
• Microsoft – Cross-tenant SharePoint Migration
• Microsoft – Migration Orchestrator
• Microsoft – Power Platform tenant-to-tenant migrations