Quest On Demand Migration: guía completa para migrar entre tenants de Microsoft 365
Las migraciones tenant-to-tenant de Microsoft 365 aparecen normalmente cuando una empresa compra otra, vende una división, consolida varios entornos o necesita separar usuarios y datos en un nuevo tenant. Sobre el papel puede parecer un proyecto de copia de información. En la práctica, afecta simultáneamente a identidades, correo, documentos, permisos, Microsoft Teams, dominios corporativos, aplicaciones, dispositivos y seguridad.
Quest On Demand Migration, habitualmente abreviado como ODM, es una de las plataformas especializadas en este tipo de proyectos. Su principal ventaja no es simplemente poder mover un buzón o copiar una biblioteca de SharePoint, sino ofrecer un entorno desde el que descubrir objetos, relacionar origen y destino, ejecutar migraciones de distintos workloads y hacer seguimiento del proyecto.
Quest cubre actualmente escenarios relacionados con Exchange Online, OneDrive, SharePoint Online, Microsoft Teams, Microsoft 365 Groups y chats, Power BI, dominios de correo, Active Directory, Microsoft Entra ID y dispositivos, aunque las funcionalidades, permisos y licencias concretas dependen del componente utilizado y del alcance contratado.
Eso no significa que la herramienta haga innecesaria la planificación. Una migración con Quest puede fallar igualmente si los usuarios están mal mapeados, se desconoce qué aplicaciones dependen del tenant de origen, el dominio no está preparado para el corte o nadie valida los permisos después de mover los datos.
En esta guía explicamos cómo plantear una migración Microsoft 365 tenant-to-tenant con Quest On Demand Migration, qué aporta realmente la plataforma, cómo preparar ambos tenants, qué hacer con Exchange, OneDrive, SharePoint y Teams, cómo gestionar coexistencia y dominios, y qué deberías validar antes de considerar terminado el proyecto.
Quest On Demand Migration en pocas palabras
| Área | Qué aporta Quest |
|---|---|
| Discovery | Permite descubrir usuarios, grupos, buzones, OneDrive, sitios SharePoint, Teams y otros objetos antes de migrarlos. |
| Mapping | Relaciona los objetos del tenant origen con sus equivalentes en el tenant destino. |
| Migración | Proporciona capacidades específicas para diferentes workloads de Microsoft 365. |
| Coexistencia | Quest dispone de capacidades adicionales para escenarios donde ambos entornos deben funcionar simultáneamente durante la transición. |
| Identidad y dispositivos | La familia On Demand Migration incluye opciones para Active Directory, Microsoft Entra ID y migración de dispositivos. |
| Seguimiento | Centraliza tareas, estados, incidencias y reporting de la migración. |
La clave: Quest ayuda a ejecutar y controlar la migración. La arquitectura, el alcance, el orden de los workloads, el movimiento del dominio y la aceptación final siguen necesitando un diseño específico.
¿Estás valorando Quest para una migración tenant-to-tenant?
Antes de adquirir licencias conviene analizar los dos tenants y comprobar qué workloads, usuarios, dominios y dependencias existen. Así se puede decidir si Quest debe utilizarse para todo el proyecto o solo para determinadas cargas.
Analizar mi migración con QuestÍndice
- Qué es Quest On Demand Migration
- Cuándo tiene sentido utilizar Quest
- Qué puede migrar Quest actualmente
- Quest frente a las herramientas nativas de Microsoft
- Cómo plantear la arquitectura de la migración
- Assessment e inventario previo
- Permisos y seguridad de la herramienta
- Discovery y mapping de usuarios
- Dominios, DNS y coexistencia
- Migración de Exchange Online
- Migración de OneDrive
- Migración de SharePoint Online
- Migración de Microsoft Teams
- Active Directory, Entra ID y dispositivos
- Power BI, Power Platform y aplicaciones
- Cómo preparar un piloto
- Premigración y migración por oleadas
- Cómo preparar el cutover
- Validación y soporte posterior
- Errores frecuentes
- Preguntas frecuentes
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.
| Escenario | Por qué Quest puede resultar interesante |
|---|---|
| Fusión o adquisición | Permite trabajar con usuarios, correo, documentos, Teams, identidad y coexistencia dentro de una estrategia coordinada. |
| Carve-out o escisión | Ayuda a seleccionar qué objetos y datos deben abandonar el tenant existente. |
| Consolidación de tenants | Facilita trabajar por lotes con varios entornos y cargas de trabajo. |
| Migración por departamentos | Collections y tareas permiten estructurar grupos de migración y oleadas. |
| Coexistencia prolongada | Quest dispone de capacidades complementarias para correo, calendario, identidad y domain rewrite según el escenario. |
| Migración con Teams y SharePoint | Permite abordar relaciones más complejas que una migración puramente de buzones. |
| Migración de identidad y endpoints | La familia ODM puede combinar migración Microsoft 365 con Active Directory, Entra ID y dispositivos. |
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.
| Workload | Capacidad de Quest | Qué debería revisarse además |
|---|---|---|
| Exchange Online | Migración de contenido de buzones primarios y archivos online, además de capacidades relacionadas con coexistencia. | Shared mailboxes, delegaciones, reglas, conectores, SMTP, dominio y configuración de clientes. |
| OneDrive | Migración de contenido de usuario y tratamiento de determinados permisos y sharing. | Aprovisionamiento del destino, propietarios, shared users, enlaces, volumen y sincronización. |
| SharePoint Online | Migración de sitios, estructura, contenido y determinados metadatos. | Permisos, personalizaciones, Power Platform, vínculos, apps y sitios conectados a Teams. |
| Microsoft Teams | Migración de Teams y Microsoft 365 Groups, miembros, contenidos y capacidades específicas para conversaciones y chats. | Apps, tabs, canales privados/compartidos, Planner, reuniones y experiencia final del chat. |
| Microsoft 365 Groups | Descubrimiento, matching y migración de grupos y contenido relacionado según el workload. | Owners, miembros, nombres, SharePoint y dependencia con Teams. |
| Identidad | Directory Sync y ODM for Active Directory para usuarios, grupos y escenarios AD/Entra. | UPN, contraseñas, identidad híbrida, dispositivos y aplicaciones. |
| Dispositivos | Migración de determinados dispositivos domain-joined, hybrid o Entra-joined. | Intune, Windows Hello, certificados, aplicaciones y experiencia del usuario. |
| Power BI | Quest incluye Power BI entre los workloads soportados por la plataforma. | Workspaces, datasets, gateways, credenciales, refresh y conexiones. |
| Dominios | Capacidades como Domain Rewrite ayudan en determinados escenarios de coexistencia. | La retirada y alta real del dominio en Microsoft 365 sigue requiriendo planificación del tenant y DNS. |
“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.
| Aspecto | Quest On Demand Migration | Microsoft nativo |
|---|---|---|
| Gestión multiworkload | Plataforma madura orientada específicamente a migraciones y consolidaciones. | Microsoft está ampliando Migration Orchestrator y herramientas por workload. |
| Exchange | Permite migración de contenido y coexistencia dentro del ecosistema Quest. | Cross-tenant Mailbox Migration realiza movimientos nativos de buzones. |
| OneDrive | Puede trabajarse con migraciones y remigraciones según el procedimiento. | Cross-tenant OneDrive es un movimiento one-and-done sin delta. |
| SharePoint | Herramientas de discovery, assessment, migration y remigration. | Cross-tenant SharePoint también es actualmente un movimiento one-and-done. |
| Teams | Quest dispone de un módulo específico de Teams y chat migration. | Las capacidades nativas continúan evolucionando y deben comprobarse según contenido. |
| Identidad | Directory Sync y ODM for Active Directory amplían el proyecto a AD y Entra. | Microsoft dispone de Cross-Tenant Identity Mapping, Entra cross-tenant sync y otras tecnologías. |
| Dispositivos | ODM for AD incluye escenarios específicos de migración de dispositivos. | Normalmente requiere procedimientos separados de rejoin/re-enrollment. |
| Coexistencia | Quest dispone de capacidades específicas como calendar coexistence y Domain Rewrite. | Microsoft ofrece B2B, Cross-Tenant Access, organization relationships y otras piezas independientes. |
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.
¿Quest o herramientas nativas de Microsoft?
Podemos analizar ambos tenants y comparar técnicamente las opciones antes de adquirir licencias. El objetivo es utilizar Quest cuando aporte una ventaja real, no simplemente porque sea una herramienta conocida.
Comparar opciones para mi migraciónCó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.
| Decisión | Ejemplo |
|---|---|
| Identidad destino | usuario@empresa.onmicrosoft.com durante la preparación y usuario@empresa.com después del cutover. |
| Modelo de migración | Piloto + departamentos por oleadas. |
| Correo | Premigración y sincronización final antes del cambio de dominio. |
| OneDrive | Migración anticipada de datos y remigración próxima al corte cuando proceda. |
| SharePoint | Migración por sitios y validación con sus propietarios. |
| Teams | Migrar estructura y archivos antes de la fase de chats. |
| Dominio | Movimiento en una ventana controlada después de eliminar dependencias del origen. |
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.
| Área | Datos relevantes | Decisión que ayudan a tomar |
|---|---|---|
| Usuarios | Activos, inactivos, UPN, licencias, grupos y tipo de identidad. | Quién se migra y cómo se crea en destino. |
| Exchange | Tamaño, archive, shared mailboxes, permisos, aliases y reglas. | Oleadas, tiempos y tratamiento especial. |
| OneDrive | Volumen, sharing y usuarios sin actividad. | Qué migrar, archivar o eliminar. |
| SharePoint | Sitios, volumen, owners, permisos, Teams asociados y personalizaciones. | Orden, alcance y casos especiales. |
| Teams | Actividad, propietarios, miembros, canales, invitados y apps. | Qué Teams se trasladan y hasta qué profundidad. |
| Aplicaciones | SSO, SCIM, Graph, SMTP, certificados y secretos. | Qué debe reconfigurarse durante el cutover. |
| Compliance | Retention, DLP, holds, sensitivity labels y eDiscovery. | Restricciones legales y configuración del destino. |
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.
El discovery puede ahorrar muchas horas de migración
Si todavía no conoces el número real de buzones, OneDrive, sitios SharePoint, Teams o grupos que existen, el primer paso no debería ser presupuestar licencias de migración, sino obtener un inventario fiable.
Solicitar análisis de los tenantsPermisos 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
| Dato | Riesgo si es incorrecto |
|---|---|
| UPN | Usuario relacionado con la cuenta de destino equivocada. |
| SMTP principal | Problemas en correo o matching automático. |
| Aliases | Pérdida de direcciones históricas o conflictos. |
| Usuarios invitados | Duplicidades entre Member y Guest. |
| Grupos | Owners o miembros incorrectos. |
| Identidad híbrida | Conflictos con Entra Connect y objetos sincronizados. |
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.
| Elemento | Qué revisar antes del cutover |
|---|---|
| Usuarios | UPN y proxyAddresses. |
| Exchange | Buzones, shared mailboxes, recursos, contactos y aliases. |
| Microsoft 365 Groups | Direcciones SMTP y objetos asociados a Teams. |
| DNS | MX, Autodiscover, SPF, DKIM, DMARC y verificaciones. |
| Aplicaciones | SMTP, SSO, portales, sistemas de firma y servicios externos. |
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.
| Elemento | Por qué importa |
|---|---|
| Tamaño del buzón | Afecta al tiempo de migración y a la planificación de lotes. |
| Online Archive | Debe contemplarse junto con el buzón principal y el licenciamiento del destino. |
| Shared mailboxes | Hay que mantener o reconstruir accesos y delegaciones. |
| Full Access / Send As | Son esenciales para usuarios que trabajan en nombre de otras cuentas. |
| Reglas y conectores | Pueden ser configuraciones del tenant que necesiten recrearse. |
| SMTP / aplicaciones | ERP, escáneres o aplicaciones pueden depender del tenant origen. |
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.
Quest y Microsoft nativo no tienen los mismos prerrequisitos
No mezcles procedimientos. Si el proyecto utiliza Quest para OneDrive, sigue los prerrequisitos de Quest. Si utiliza Cross-tenant OneDrive Migration de Microsoft, sigue los de Microsoft.
Aprovisionar OneDrive demasiado pronto o demasiado tarde puede ser correcto en un método y bloquear el otro.
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.
| Prueba | Objetivo |
|---|---|
| Acceso web | Confirmar que el usuario abre su OneDrive en destino. |
| Archivos críticos | Comprobar que los documentos importantes están presentes. |
| Sharing | Validar relaciones entre usuarios y accesos externos relevantes. |
| OneDrive Sync | Confirmar que el cliente local se conecta al nuevo tenant. |
| Known Folder Move | Revisar Escritorio, Documentos e Imágenes cuando estén redirigidos. |
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.
| Tipo de complejidad | Qué revisar |
|---|---|
| Permisos | Herencia rota, SharePoint Groups, Microsoft 365 Groups e invitados. |
| Metadatos | Content Types, columnas y valores personalizados. |
| Automatización | Power Automate, workflows y aplicaciones. |
| Personalización | SPFx, webparts, scripts y soluciones de terceros. |
| Teams | Determinar si el sitio pertenece a un Team. |
| External Sharing | Invitados, enlaces y accesos que deben mantenerse o retirarse. |
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.
SharePoint suele esconder la complejidad del proyecto
Podemos realizar un inventario previo de sitios, almacenamiento, Teams asociados, owners y permisos para separar migraciones sencillas de sitios que necesitan un tratamiento específico.
Analizar SharePoint antes de migrarMigrar 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.
| Elemento de Teams | Qué conviene revisar |
|---|---|
| Teams | Owners, miembros, configuración y Microsoft 365 Group asociado. |
| Canales estándar | Conversaciones y documentos. |
| Canales privados | Miembros y SharePoint independiente asociado. |
| Shared Channels | Participantes externos y B2B Direct Connect. |
| Chats | Participantes, fechas, adjuntos y experiencia final en destino. |
| Apps y Tabs | Compatibilidad, permisos y necesidad de recreación. |
| Planner | Confirmar explícitamente el tratamiento previsto. |
| Grabaciones | Revisar ubicación física en OneDrive o SharePoint. |
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:
| Escenario | Ejemplo |
|---|---|
| AD → AD | Consolidación de dominios después de una adquisición. |
| AD → Entra ID | Modernización hacia un modelo cloud-first. |
| Entra ID → Entra ID | Movimiento entre tenants. |
| Hybrid → Entra | Reducción o eliminación de dependencias del AD tradicional. |
| Device migration | Cambio de dispositivos entre dominios o tenants y modificación de su enrollment. |
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.
| Perfil | Qué permite probar |
|---|---|
| Usuario estándar | Flujo habitual de correo, OneDrive y Teams. |
| Usuario con mailbox grande | Rendimiento y ventanas de migración. |
| Usuario con Archive | Migración y licenciamiento de archivo online. |
| Delegado | Full Access, Send As y calendarios compartidos. |
| Owner de Team | Equipos, miembros, canales y archivos. |
| Usuario con OneDrive grande | Rendimiento, sharing y sincronización. |
| Usuario con aplicaciones críticas | SSO, Power Automate, CRM u otras dependencias. |
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.
| Fase | Acciones habituales |
|---|---|
| T-7 días | Revisar errores, mappings, licencias, cuentas y DNS. |
| T-24 horas | Confirmar jobs, comunicación, soporte y dependencias. |
| Inicio del corte | Ejecutar las sincronizaciones finales necesarias y aplicar restricciones de cambio si proceden. |
| Dominio | Eliminar dependencias en origen, transferir el dominio y publicar registros. |
| Servicios | Completar tareas de correo y workloads pendientes. |
| Aplicaciones | Activar nuevas configuraciones de SSO, SMTP, Graph o integraciones. |
| Validación | Probar usuarios y servicios críticos. |
| Go/No-Go | Decidir si el entorno puede pasar a operación normal. |
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
| Área | Qué comprobar |
|---|---|
| Identity | Login, UPN, MFA, grupos y Conditional Access. |
| Exchange | Correo entrante/saliente, calendarios, archive y shared mailboxes. |
| OneDrive | Datos, permisos y sincronización. |
| SharePoint | Sitios, bibliotecas, permisos, metadata y sharing. |
| Teams | Equipos, canales, conversaciones y archivos según alcance. |
| DNS | MX, Autodiscover, SPF, DKIM y DMARC. |
| Aplicaciones | SSO, SCIM, Graph, SMTP y automatizaciones. |
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
| Error | Qué ocurre | Cómo evitarlo |
|---|---|---|
| Comprar licencias antes del assessment | El alcance real resulta distinto al calculado. | Inventariar primero los tenants. |
| Confiar únicamente en matching automático | Objetos especiales quedan relacionados incorrectamente. | Revisar excepciones y duplicidades. |
| No hacer piloto | Las primeras pruebas reales ocurren en producción. | Utilizar usuarios representativos. |
| Tratar Teams como un único objeto | Planner, apps, canales o chats no cumplen las expectativas. | Definir alcance elemento por elemento. |
| No analizar sharing de OneDrive | Algunos accesos pueden no quedar correctamente reconstruidos. | Planificar orden entre propietarios y usuarios compartidos. |
| No usar assessment SharePoint | Los errores se descubren al migrar. | Ejecutar premigration assessment previamente. |
| No revisar aplicaciones | ERP, CRM o automatizaciones dejan de funcionar. | Inventario de SSO, Graph, SMTP y SCIM. |
| Improvisar el dominio | El cutover se retrasa o el correo deja de fluir correctamente. | Runbook específico de dominio y DNS. |
| No retirar accesos al acabar | Quedan permisos o cuentas de migración innecesarios. | Incluir decommission en el proyecto. |
| Dar por buena una tarea Completed | Se cierran incidencias que el usuario descubrirá posteriormente. | Validación técnica y funcional. |
Preguntas frecuentes sobre Quest On Demand Migration
Quest On Demand Migration es una plataforma SaaS especializada en migraciones y consolidaciones de entornos Microsoft.
En Microsoft 365 se utiliza especialmente para proyectos tenant-to-tenant y dispone de capacidades relacionadas con Exchange Online, OneDrive, SharePoint, Microsoft Teams, Microsoft 365 Groups, chats, Power BI, identidad, dominios y dispositivos.
Es habitual utilizarlo en fusiones, adquisiciones, carve-outs, desinversiones, consolidaciones de tenants y reorganizaciones empresariales.
Resulta especialmente interesante cuando hay varias cargas de Microsoft 365 y se busca centralizar discovery, mapping, ejecución y seguimiento.
Quest cubre un número amplio de workloads, pero “todo el tenant” puede incluir configuraciones y servicios que necesitan procedimientos específicos.
Por ejemplo, aplicaciones empresariales, determinadas configuraciones de Microsoft Purview, Power Platform, seguridad o apps de Teams pueden necesitar recreación o reconfiguración adicional.
Quest publica actualmente capacidades relacionadas con Exchange Online, OneDrive, SharePoint Online, Microsoft Teams, Microsoft 365 Groups y chats, Power BI, email domains, Active Directory y Microsoft Entra ID.
El alcance exacto debe comprobarse según licencia y versión vigente.
No necesariamente. Depende del proyecto.
Microsoft dispone actualmente de Cross-tenant Mailbox Migration, Cross-tenant OneDrive Migration, Cross-tenant SharePoint Migration y Migration Orchestrator. Quest puede aportar ventajas cuando se necesita discovery avanzado, remigraciones, coexistencia, Teams, identidad, dispositivos o gestión multiworkload desde una plataforma especializada.
Sí. Quest dispone de capacidades específicas para Exchange Online y permite coordinar la migración de correo con otros workloads.
Además deben planificarse dominios, MX, Autodiscover, SPF, DKIM, DMARC, shared mailboxes, delegaciones y aplicaciones SMTP.
Quest permite ejecutar tareas de migración antes del cutover y volver a trabajar sobre el contenido según las opciones y comportamiento documentados para el workload.
Esto puede ayudar a reducir el volumen pendiente durante la ventana final frente a métodos one-and-done.
Sí. Quest dispone de migración de OneDrive entre tenants.
La documentación actual indica que el OneDrive destino debe estar provisionado antes de la migración y recomienda hacerlo al menos 24 horas antes.
Es un prerrequisito del procedimiento de Quest para sus tareas de OneDrive.
No debe confundirse con Cross-tenant OneDrive Migration nativo de Microsoft, donde el sitio destino no debe existir previamente. Son tecnologías diferentes con requisitos distintos.
Quest dispone de capacidades para tratar determinados permisos, pero el orden de migración importa.
Quest recomienda migrar primero el OneDrive del propietario antes de los usuarios con los que ha compartido contenido para ayudar a conservar correctamente esas relaciones.
Sí. Quest dispone de una solución específica para SharePoint Online con discovery, assessment y migración de sitios y contenido.
Antes de migrar conviene analizar permisos, metadatos, versiones, external sharing, personalizaciones y conexiones con Teams o Power Platform.
Quest documenta soporte para metadatos como Created Date, Created By, Last Modified Date y Last Modified By, entre otros elementos soportados por su migración.
Los metadatos críticos del proyecto deben comprobarse siempre contra la documentación vigente y validarse con un piloto.
Sites.Selected es un modelo de permisos de Microsoft Graph/SharePoint que permite limitar una aplicación a sitios SharePoint específicos.
Quest documenta su uso para reducir el ámbito de acceso de ODM for SharePoint cuando el escenario lo permite.
Sí. On Demand Migration dispone de un workspace específico para Microsoft Teams y Microsoft 365 Groups.
Sin embargo, conviene definir exactamente qué se espera migrar: equipos, canales, miembros, archivos, conversaciones, chats, apps, pestañas y otros componentes pueden tener tratamientos diferentes.
Sí, Quest documenta capacidades específicas de chat migration.
El resultado exacto depende del tipo de conversación y de las limitaciones vigentes de Microsoft y Quest, por lo que debe probarse durante el piloto.
Quest recomienda actualmente migrarlos después de haber tratado contenido como OneDrive, Mailboxes, SharePoint y Teams, y una vez que las cuentas de usuario estén correctamente matched.
El objetivo es que las identidades y los recursos relacionados ya existan cuando se procese el historial de chat.
Sí. Quest dispone de diferentes capacidades de coexistencia, entre ellas funcionalidades relacionadas con Exchange, free/busy y Domain Rewrite.
La arquitectura concreta depende de cuánto tiempo deban convivir los tenants y de qué servicios tengan que compartir los usuarios.
Domain Rewrite es una capacidad orientada a determinados escenarios de coexistencia de correo. Permite reescribir direcciones de los mensajes para ayudar a mantener una identidad coherente mientras los usuarios están distribuidos entre entornos.
Requiere configurar correctamente mail flow, conectores, SPF y otros elementos relacionados.
Sí. Quest dispone de On Demand Migration for Active Directory, que permite trabajar con usuarios, grupos y dispositivos entre Active Directory, Microsoft Entra ID y escenarios híbridos.
Quest dispone de capacidades de device migration para determinados escenarios de Windows 10 y Windows 11, incluidos movimientos relacionados con AD, hybrid y Entra joined.
En determinados escenarios también puede intervenir en el cambio de inscripción de Intune. Es recomendable probar siempre con dispositivos piloto.
Quest incluye Power BI entre los workloads que promociona dentro de On Demand Migration.
El proyecto debe revisar específicamente workspaces, datasets, gateways, credenciales, conexiones, permisos y procesos de actualización.
Power Platform debe tratarse como un workload específico y no debe suponerse que cualquier flujo o aplicación se trasladará simplemente porque SharePoint o Teams hayan sido migrados.
Microsoft dispone además de procedimientos tenant-to-tenant propios para determinados entornos Power Platform.
Depende de los workloads utilizados.
Quest mantiene una Permissions Reference Guide donde documenta permisos de Graph, Exchange, SharePoint y Teams. Actualmente también soporta mecanismos como Sites.Selected para SharePoint y RBAC for Applications en Exchange en determinados escenarios.
No es una obligación técnica en todos los casos, pero es muy recomendable.
El piloto permite verificar la configuración, rendimiento, permisos, experiencia del usuario y comportamiento de cada workload antes de migrar grupos mayores.
Quest puede ayudar a reducir el impacto mediante premigraciones y coexistencia, pero no debería prometerse impacto cero.
El movimiento del dominio, cambios de UPN, Outlook, OneDrive Sync, Teams, dispositivos o aplicaciones pueden requerir acciones y ventanas de cambio.
Significa que Quest ha terminado esa operación, pero no demuestra por sí solo que el usuario pueda trabajar correctamente.
Después hay que validar correo, permisos, datos, Teams, sincronización, aplicaciones, DNS, seguridad y experiencia de usuario.
Cuando el proyecto incluye varios workloads, muchos usuarios, varios dominios, identidad híbrida, SharePoint o Teams complejos, coexistencia, dispositivos, aplicaciones empresariales o una ventana de cutover reducida.
También es útil cuando se quiere definir correctamente qué licencias y módulos de Quest son realmente necesarios antes de contratarlos.
Conclusión: 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.
¿Necesitas realizar una migración con Quest On Demand Migration?
En Kloudeal podemos ayudarte a preparar y ejecutar una migración Microsoft 365 tenant-to-tenant utilizando Quest On Demand Migration cuando sea la tecnología adecuada para el proyecto.
Podemos encargarnos del assessment, discovery, configuración de los tenants, permisos, mapping, Exchange Online, OneDrive, SharePoint, Microsoft Teams, chats, dominios, coexistencia, identidad, pilotos, oleadas, cutover, validación y soporte post-migración.
También podemos comparar Quest con las capacidades nativas actuales de Microsoft para definir qué combinación ofrece un mejor equilibrio entre alcance, complejidad y coste.
Hablar con Kloudeal sobre una migración con QuestDocumentació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
OneDrive
SharePoint
Microsoft Teams
Active Directory, Entra ID y dispositivos
- Quest – Active Directory and Entra ID Migration
- Quest – Device Migration
- Quest – On Demand Migration Active Directory User Guide