Migración de OneDrive entre tenants de Microsoft 365: guía completa paso a paso (cross-tenant) para mover datos sin perder control

Resumen rápido: migración de OneDrive entre tenants en 10 puntos

1. Definir el escenario: fusión (M&A), carve-out, cambio de dominio, reorganización, consolidación de tenants o cambio de partner.
2. Decidir el alcance: qué usuarios migran, qué se hace con OneDrive de ex-empleados, y qué contenido se archiva en vez de migrar.
3. Diseñar identidad: UPN/dominios en destino, estrategia de invitados (B2B), y mapeo de usuarios/grupos para conservar permisos.
4. Licenciar CTUDM: validar y adquirir Cross-Tenant User Data Migration (requisito en el enfoque nativo).
5. Prerrequisitos que bloquean: Customer Key en el origen, OneDrive en solo lectura, OneDrive ya creado en destino, holds legales activos, límites de ruta/volumen.
6. Preparar “identity mapping”: CSV que relaciona origen y destino (usuarios/grupos y URLs) para preservar permisos.
7. Establecer confianza: relación cross-tenant con PowerShell (source & target) y verificación.
8. Migrar por oleadas: colas planificadas y ventanas (hasta 4.000 OneDrive en cola por lote), monitorización y reintentos si hay fallos.
9. Gestionar la experiencia del usuario: sincronización (OneDrive Sync), redirecciones, enlaces compartidos, comunicación y soporte post-go-live.
10. Cerrar el proyecto con gobierno: recertificación de accesos, limpieza de invitados, políticas Purview en destino y plan de backup/recuperación.

Resumen de contexto: mover archivos es solo una parte. El éxito suele depender de identidad, permisos, enlaces, adopción y cumplimiento.

¿Cuándo se necesita migrar OneDrive entre tenants de Microsoft 365?

La migración de OneDrive entre tenants suele aparecer cuando el cliente cambia de estructura, marca o perímetro de operación. OneDrive es “lo personal de trabajo” de cada usuario: borradores, documentación en curso, entregables, notas y archivos compartidos por enlace. Si se mueve mal, la sensación habitual es simple: “falta información” y “se han roto cosas”.

Escenarios habituales

• Fusiones y adquisiciones (M&A): dos organizaciones con tenants distintos y necesidad de consolidar a personas y archivos.
• Carve-out / spin-off: parte del negocio se separa y necesita su propio tenant, moviendo solo un subconjunto de usuarios.
• Rebranding / cambio de dominio: se normaliza identidad y se reordenan UPN y correos, con impacto directo en OneDrive.
• Consolidación de tenants históricos: varios tenants heredados se unifican para simplificar gobierno y licencias.
• Reorganización internacional: cambios por país/región, o adopción de Multi-Geo en el destino.

Resumen de esta sección: si el usuario cambia de “casa” (tenant), OneDrive también tiene que cambiar. La clave es hacerlo manteniendo permisos, enlaces y una transición entendible.

Introducción: qué cambia realmente al mover OneDrive a otro tenant

En una migración de OneDrive entre tenants de Microsoft 365 no se trata solo de copiar archivos. Se mueve un espacio que está conectado a identidad, sincronización en dispositivos, compartición con terceros y, en muchos casos, cumplimiento (retención, eDiscovery, auditoría).

Por eso, un plan serio responde a preguntas concretas:

• ¿Qué OneDrive migran? (usuarios activos, usuarios de baja, buzones compartidos no aplican, cuentas especiales).
• ¿Qué ocurre con los enlaces compartidos? (internos, externos, “cualquiera con el enlace”, enlaces antiguos en correos).
• ¿Cómo se conserva el acceso? (mapeo de grupos/usuarios y recertificación en destino).
• ¿Cómo se trabaja el “día después”? (OneDrive Sync, Teams, Office, favoritos, rutas locales, móviles).

La ventaja del enfoque nativo cross-tenant es que deja redirecciones desde el OneDrive original para que enlaces sigan funcionando, y el impacto típico se reduce a una ventana breve donde el OneDrive de origen queda en modo solo lectura.

Resumen de esta sección: la migración es tanto técnica como operativa: lo importante es que el usuario encuentre sus archivos, que los enlaces no “mueran” y que seguridad/compliance queden igual o mejor.

1. Metodología y gobierno del proyecto (oleadas, piloto, roles)

En la práctica: OneDrive se migra mejor por oleadas. Un piloto representativo evita sorpresas y permite ajustar comunicación, mapeos y soporte.

1.1 Enfoque recomendado por oleadas

1. Piloto: 10–30 usuarios representativos (distintos perfiles, volumen y formas de compartir).
2. Oleadas progresivas: por departamento, ubicación o criticidad (ventas, finanzas, operaciones, etc.).
3. Corte y estabilización: soporte reforzado, validaciones y ajustes finales (permisos, invitados, DLP).

1.2 Roles típicos (RACI simplificado)

Un punto que suele ahorrar muchas incidencias: acordar qué se considera “hecho” para cada oleada (por ejemplo, sincronización del cliente OneDrive revisada, validación de acceso a carpetas compartidas clave, y cierre de tickets críticos).

Resumen de esta sección: si hay oleadas, hay control. Si se intenta “todo a la vez”, el soporte se satura y los problemas pequeños se vuelven grandes.

2. Assessment: inventario, dependencias y “bloqueos” típicos

En la práctica: el assessment evita que la migración falle por causas conocidas (holds, rutas largas, OneDrive ya creado en destino, etc.).

2.1 Inventario mínimo que conviene tener

• Usuarios a migrar: activos, externos relevantes, cuentas de baja (decidir archivo vs migración).
• Volumen por usuario: tamaño, número de ítems, patrones de compartición (interno/externo).
• Rutas largas: directorios heredados con estructuras profundas (riesgo real de fallo).
• Controles de cumplimiento: retención/holds/eDiscovery y políticas DLP existentes.
• Dispositivos: cuántos usan OneDrive Sync, cuántos son equipos compartidos o con restricciones.

2.2 Bloqueos frecuentes que conviene detectar ya

• OneDrive en destino ya creado: si existe, la migración nativa no puede sobrescribirlo.
• Holds legales: OneDrive con política de “hold” aplicado queda bloqueado para migración.
• Customer Key (Service encryption): si está habilitado en el tenant origen, la migración falla.
• Rutas superiores a límite: estructuras profundas + URL destino más larga pueden romper el movimiento.

También conviene decidir pronto algo muy práctico: qué ocurrirá con OneDrive de usuarios que ya no están. A menudo, en M&A o carve-out existen OneDrive con contenido crítico que pertenece a procesos, no a personas. En esos casos se suele:

• Reasignar propiedad o recuperar contenido hacia un sitio de SharePoint (repositorio de equipo) antes de migrar.
• Migrar OneDrive igualmente, pero estableciendo un propietario/gestor de ese contenido en destino (y revisando comparticiones).
• Archivar (exportar o backup) si hay obligación, pero sin mantenerlo como OneDrive activo.

Resumen de esta sección: el assessment no es burocracia: es la forma de evitar fallos previsibles y de decidir el destino del contenido “huérfano”.

3. Identidad y estrategia de mapeo: UPN, dominios y grupos

En la práctica: si el usuario cambia de identidad, los permisos y comparticiones dependen de que el mapeo esté bien diseñado.

3.1 Decisiones típicas de identidad

• ¿Se mantiene el dominio principal? (por ejemplo, empresa.com) o se adopta uno nuevo.
• ¿Cómo quedarán los UPN? (mismo alias, alias distinto, coexistencia temporal).
• ¿Qué grupos “viven” en Entra/M365? y cómo se recrean en destino (mapeo de miembros y propietarios).

3.2 Invitados y colaboración externa

OneDrive se usa mucho para compartir con terceros. Antes de migrar conviene clasificar:

• Colaboración estable: proveedores o clientes recurrentes (conviene que sean invitados controlados, con revisión periódica).
• Colaboración puntual: enlaces con caducidad y acceso restringido a personas específicas cuando sea viable.
• Enlaces históricos: enlaces antiguos en correos o chats (el riesgo es que se conviertan en “puntos ciegos” si no hay gobierno).

La migración nativa puede conservar permisos si usuarios y grupos están incluidos en el archivo de mapeo. Por eso, el cliente debe tratar el mapeo como una pieza crítica del proyecto, no como un CSV más.

Resumen de esta sección: la migración de OneDrive no se sostiene si identidad y grupos no están ordenados. El contenido puede llegar, pero los accesos y enlaces pueden quedar inconsistentes.

4. Licenciamiento CTUDM y decisiones de enfoque (nativo vs terceros)

En la práctica: el enfoque nativo requiere CTUDM. Si no se decide esto al inicio, el proyecto se frena en el peor momento.

4.1 CTUDM (Cross-Tenant User Data Migration)

En la vía nativa de Microsoft, la migración cross-tenant de OneDrive requiere licencias CTUDM por usuario migrado (pago de una sola vez por migración). Estas licencias cubren también la migración de buzón cross-tenant si aplica en el mismo programa.

4.2 ¿Cuándo considerar herramientas de terceros?

Aunque el método nativo es una opción sólida, hay casos donde herramientas de terceros ayudan:

• Necesidad de reporting más detallado (por archivo, por error, por reintento) o paneles ejecutivos.
• Escenarios donde se quiere una orquestación más guiada (descubrimiento, mapeo, oleadas, reintentos).
• Casos con requisitos específicos (por ejemplo, estrategias concretas de compartición o transformaciones).

Resumen de esta sección: decidir “nativo vs terceros” no va de gustos. Va de alcance, reporting, requisitos y capacidad interna para operar la migración.

5. Prerrequisitos técnicos que hay que validar antes de migrar OneDrive entre tenants

En la práctica: muchos fallos de migración se deben a prerequisitos ignorados. Validarlos primero reduce reintentos y ventanas perdidas.

5.1 Prerrequisitos base

• Disponer de SharePoint Online PowerShell actualizado.
• Validar que el OneDrive origen está en Read/Write (si está en solo lectura falla).
• Evitar que existan OneDrive ya creados en el tenant destino para esos usuarios (no se pueden sobrescribir).

5.2 Prerrequisitos que bloquean (y cómo tratarlos)

• Customer Key en el origen: si está habilitado, la migración falla. Debe planificarse el tratamiento con seguridad/compliance.
• Legal holds activos: OneDrive con hold aplicado queda bloqueado; se retira el hold, se migra, y se reaplica en el destino según corresponda.
• Entornos no soportados: la funcionalidad cross-tenant de OneDrive no está disponible en ciertos clouds (por ejemplo, Government Cloud).

5.3 “Detalle pequeño” que provoca fallos grandes: rutas y URLs

En migraciones reales, una causa frecuente de fallo es la combinación de:

• Carpetas heredadas con subcarpetas profundas.
• Nombres de carpetas largos (con años, versiones, descripciones, etc.).
• URL de OneDrive en destino más larga de lo esperado (por ejemplo, por convenciones de naming).

El resultado: rutas que exceden el límite permitido. La solución suele ser práctica: acortar estructura en origen antes de mover, y mantener URLs de destino razonablemente cortas.

Resumen de esta sección: prerequisitos y límites son parte del diseño. Si se ignoran, el proyecto se convierte en una cadena de “reintentar y rezar”.

6. Precrear usuarios/grupos y evitar que se cree OneDrive en el tenant destino

En la práctica: si el usuario entra al destino y crea su OneDrive antes de tiempo, la migración nativa puede fallar.

6.1 Precrear identidad y licencias en destino

• Crear usuarios y grupos identificados para migración (incluidos los grupos usados en permisos).
• Asignar licencias necesarias (OneDrive/SharePoint según plan y CTUDM si aplica).

6.2 Restringir la creación de OneDrive durante el proyecto

Durante la migración cross-tenant, conviene restringir la creación de OneDrive en el tenant destino para evitar que se genere el sitio de OneDrive antes del movimiento. Si el OneDrive ya existe en destino, el proceso no puede sobrescribirlo.

En proyectos con coexistencia (usuarios trabajando aún en el tenant origen), también puede ser necesario restringir creación de nuevos OneDrive en origen para evitar que “aparezca contenido nuevo” fuera del control del plan (especialmente si se migra por oleadas).

Resumen de esta sección: precrear es obligatorio, pero precrear “demasiado” (crear OneDrive antes de tiempo) puede romper la migración. Hay que controlar el timing.

7. Identity mapping en migración de OneDrive entre tenants: CSV, URLs y reglas para mantener permisos

En la práctica: el archivo de mapeo es la traducción “de quién es quién” entre tenants. Si falla, los permisos y accesos se degradan.

7.1 Qué debe reflejar el mapeo

• Relación entre UPN origen y UPN destino.
• Relación entre URLs de OneDrive origen y destino.
• Inclusión de usuarios y grupos relevantes para conservar permisos en el destino.

7.2 Ejemplo de CSV (simplificado para entender la lógica)

SourceUserPrincipalName,TargetUserPrincipalName,SourceOneDriveUrl,TargetOneDriveUrl
ana.perez@origen.com,ana.perez@destino.com,https://origen-my.sharepoint.com/personal/ana_perez_origen_com,https://destino-my.sharepoint.com/personal/ana_perez_destino_com
juan.garcia@origen.com,juan.garcia@destino.com,https://origen-my.sharepoint.com/personal/juan_garcia_origen_com,https://destino-my.sharepoint.com/personal/juan_garcia_destino_com

En la práctica, el mapeo real incluye también grupos y casos especiales. La recomendación es tratar el CSV como un entregable controlado: versionarlo (repositorio interno), revisarlo con IT y seguridad, y usarlo como fuente de verdad durante toda la ejecución.

7.3 Reglas prácticas que evitan errores

• Normalizar UPN: evitar variantes “parecidas” que luego confunden (alias distintos, dominios temporales, etc.).
• URLs cortas y limpias: reducir riesgo de rutas largas, y evitar caracteres problemáticos.
• Incluir grupos usados en permisos: si un grupo no está mapeado, el permiso puede no reconstruirse como se espera.

Resumen de esta sección: si el cliente quiere conservar permisos y trazabilidad, el mapeo es la pieza central. Sin mapeo, el contenido llega, pero el acceso se vuelve impredecible.

8. Establecer confianza entre tenants para migrar OneDrive (Set-SPOCrossTenantRelationship)

En la práctica: la relación de confianza se establece en ambos tenants. No es un paso “de una sola vez” si hay Multi-Geo o varios destinos.

La migración cross-tenant se apoya en la creación de una relación entre el tenant origen y el destino. En términos operativos: se autoriza el movimiento y se define el “partner” con el que se va a migrar.

8.1 Comandos típicos (ilustrativos)

# Conectar al tenant ORIGEN
Connect-SPOService -Url https://origen-admin.sharepoint.com

# Establecer relación hacia el tenant DESTINO
Set-SPOCrossTenantRelationship -Scenario MnA `
  -PartnerCrossTenantHostUrl "https://destino-my.sharepoint.com" `
  -PartnerCrossTenantHostUrl "https://destino-my.sharepoint.com" `
  -Enabled $true

El proyecto suele incluir una verificación posterior para confirmar que la relación está lista antes de programar oleadas. En entornos con Multi-Geo, hay que repetir la configuración donde corresponda (y mantener ordenado qué instancia confía con cuál).

Resumen de esta sección: la confianza es el “puente” entre tenants. Si no está bien establecida (y verificada), las oleadas fallan o quedan bloqueadas.

9. Iniciar la migración de OneDrive entre tenants: Start-SPOCrossTenantUserContentMove (con oleadas)

En la práctica: se programa por lotes, se controla la cola y se migra con monitorización. La planificación de oleadas manda más que el “botón de iniciar”.

9.1 Antes de lanzar una oleada

• Confirmar estado de compatibilidad (compatible o warning según criterios del entorno).
• Validar que el usuario existe en destino, con licencias y sin OneDrive creado previamente.
• Confirmar que el usuario no está bloqueado por hold legal.

9.2 Ejecutar el movimiento por usuario (o en serie controlada)

# En el tenant ORIGEN
Connect-SPOService -Url https://origen-admin.sharepoint.com

Start-SPOCrossTenantUserContentMove `
  -SourceUserPrincipalName ana.perez@origen.com `
  -TargetUserPrincipalName ana.perez@destino.com `
  -TargetCrossTenantHostUrl https://destino-my.sharepoint.com/

9.3 Programación en ventana (cuando se quiere “controlar el momento”)

Cuando el cliente necesita que el inicio ocurra en una franja concreta (por ejemplo, fuera de horario), se puede programar con parámetros de fecha en UTC. Esto es especialmente útil para oleadas grandes o para usuarios críticos con soporte dedicado.

Start-SPOCrossTenantUserContentMove `
  -SourceUserPrincipalName juan.garcia@origen.com `
  -TargetUserPrincipalName juan.garcia@destino.com `
  -TargetCrossTenantHostUrl https://destino-my.sharepoint.com/ `
  -PreferredMoveBeginDate "2026-01-12T20:00:00Z" `
  -PreferredMoveEndDate   "2026-01-12T23:30:00Z"

Resumen de esta sección: el “start” no es el proyecto. Lo importante es que cada oleada se pueda explicar, medir y soportar, con control de impacto.

10. Monitorización, cancelación, estados y errores frecuentes

En la práctica: monitorizar es lo que permite decidir si se sigue, se reprograma o se detiene un caso concreto antes de que impacte a más usuarios.

10.1 Consultar estado de migración

# Puede ejecutarse en origen o destino
Get-SPOCrossTenantUserContentMoveState `
  -PartnerCrossTenantHostURL https://destino-my.sharepoint.com/

En operaciones reales, conviene filtrar por usuario para soporte de oleada (sobre todo cuando se reciben tickets):

Get-SPOCrossTenantUserContentMoveState `
  -PartnerCrossTenantHostURL https://destino-my.sharepoint.com/ `
  -SourceUserPrincipalName ana.perez@origen.com -Verbose

10.2 Cancelar (cuando aún es posible)

Stop-SPOCrossTenantUserContentMove -SourceUserPrincipalName ana.perez@origen.com

10.3 Errores frecuentes y mitigación

• OneDrive ya existe en destino: restringir creación antes y verificar caso a caso.
• Hold legal aplicado: retirar hold, migrar, reaplicar según política en destino.
• Exceso de tamaño o ítems: limpiar/archivar o dividir contenido (y documentar decisión).
• Rutas demasiado largas: acortar estructura, renombrar carpetas, reducir profundidad antes de migrar.
• Problemas de enlaces/externos: reforzar política de invitados y revisar “quién tenía acceso” tras el movimiento.

Resumen de esta sección: la migración sin monitorización termina en “se migró, pero no se sabe qué pasó”. Monitorizar permite priorizar y dar respuestas claras.

11. Experiencia del usuario: OneDrive Sync, redirecciones y soporte después del cambio

En la práctica: el usuario no pregunta por PowerShell. Pregunta por sus carpetas, su sincronización y si los enlaces siguen funcionando.

11.1 Qué suele notar el usuario

• Una ventana corta donde el OneDrive de origen puede quedar en solo lectura.
• Al terminar, el OneDrive “vive” en el tenant destino y el origen queda con una redirección.
• En equipos con OneDrive Sync, puede ser necesario volver a iniciar sesión o re-sincronizar.

11.2 Comunicación que reduce tickets

Suele funcionar bien una comunicación simple por oleada (sin tecnicismos), con tres apartados:

• Qué pasará: “el OneDrive se moverá al nuevo tenant y se mantendrán redirecciones”.
• Qué hacer: “si la sincronización se pausa o pide credenciales, seguir el procedimiento interno”.
• Qué no hacer: “no crear manualmente carpetas espejo, no duplicar datos, no ‘subir de nuevo’ lo que ya existe”.

11.3 Soporte post-migración (primeros 5–10 días)

El soporte debería estar preparado para incidencias típicas:

• Conflictos de sincronización (archivos en uso, rutas largas, caracteres no válidos).
• Carpetas compartidas que “desaparecen” hasta que el usuario vuelve a autenticarse.
• Accesos de terceros (invitados) que requieren revalidación por políticas del destino.

Resumen de esta sección: la migración técnica puede ir perfecta y aun así el usuario percibir caos si no se guía la sincronización y la compartición.

12. Compartición y enlaces en OneDrive tras migrar entre tenants: qué se conserva y cómo evitar pérdidas de control

En la práctica: el gran punto sensible en OneDrive son los enlaces compartidos (especialmente externos) y los accesos directos de usuarios.

12.1 Enlaces compartidos y redirecciones

Una de las ventajas del enfoque cross-tenant es que, al finalizar, se coloca una redirección en la ubicación original del OneDrive, de modo que enlaces antiguos puedan seguir llevando al nuevo destino (si la persona que accede sigue teniendo permisos).

12.2 Permisos: por qué el mapeo importa tanto

Si usuarios y grupos están incluidos en el identity mapping, los permisos relacionados con el OneDrive migrado se conservan en el destino. Cuando falta una identidad (usuario o grupo) en el mapeo, el permiso puede perderse o transformarse en un caso que requiere intervención manual.

12.3 Colaboración con terceros (clientes/proveedores)

En entornos con compartición externa intensa, conviene hacer dos cosas:

• Catalogar “comparticiones sensibles” (carpetas con datos críticos) y validarlas tras migración con el área dueña del proceso.
• Aplicar reglas en destino (caducidad de enlaces, “personas específicas”, revisión periódica de invitados) para evitar que la migración amplíe el riesgo.

Resumen de esta sección: el objetivo no es “que todo siga igual”, sino que la colaboración siga funcionando y quede mejor gobernada en el tenant destino.

13. Cumplimiento y seguridad en migración de OneDrive: Purview, retención, holds y auditoría

En la práctica: si el cliente está auditado (o quiere estarlo), la migración debe cerrar con reglas claras de retención, clasificación y evidencias.

13.1 Sensibilidad y protección de la información

Tras migrar, es el momento de asegurar que el tenant destino aplica una política coherente de clasificación y protección. Las etiquetas de sensibilidad ayudan a que un archivo siga bajo control incluso fuera del navegador, según la política definida.

13.2 Retención, disposición y eDiscovery

La retención no es un “extra”; es una decisión de negocio y compliance: cuánto tiempo se conserva cada categoría de información y cómo se dispone. En OneDrive hay contenido personal de trabajo y también contenido “de proceso” que nunca debió estar ahí. La migración es una oportunidad para ordenar:

• Contenido operativo que debería vivir en SharePoint (repositorio de equipo).
• Contenido personal de trabajo que debe retenerse y migrarse.
• Contenido que requiere archivo por obligación legal o por política interna.

13.3 Holds legales

Si un OneDrive tiene un hold aplicado, la migración cross-tenant puede quedar bloqueada. Esto obliga a coordinar con legal/compliance: retirar el hold para migrar, y reaplicarlo en destino de forma controlada.

Resumen de esta sección: una migración “cumplidora” no se mide solo por gigas movidos. Se mide por control, trazabilidad y capacidad de respuesta ante auditoría.

14. Límites y consideraciones que afectan a la migración de OneDrive entre tenants

En la práctica: los límites no son teoría: son la razón de muchos fallos y reprogramaciones si no se tratan antes.

14.1 Límites típicos que conviene revisar

• Tamaño e ítems: OneDrive con grandes volúmenes o demasiados ítems puede fallar si excede límites.
• Rutas largas: estructuras profundas pueden exceder el máximo de caracteres permitido.
• Cola por lote: hasta 4.000 migraciones programadas por lote; para más usuarios, dividir oleadas.

14.2 Multi-Geo

En entornos Multi-Geo, la planificación es más exigente: hay que definir el destino correcto por región, cargar mapeos donde corresponda y asegurar relaciones de confianza entre instancias implicadas. Si no se documenta, el proyecto se vuelve difícil de operar.

14.3 Un punto importante: “one and done”

La migración cross-tenant de OneDrive está diseñada como una actividad “de una vez”: se mueve el contenido y se deja un redirect en el origen. Esto obliga a planificar bien el momento de cada oleada: no está pensada para pasadas incrementales tipo “pre-stage + delta” como se hace en otras tecnologías.

Resumen de esta sección: límites y “one-and-done” condicionan el plan. La mitigación es oleadas, limpieza previa y control de creación de OneDrive en destino.

15. Backup y recuperación en una migración de OneDrive entre tenants: enfoque práctico

En la práctica: “resiliencia” no equivale a “recuperación”. Conviene decidir cómo se restaura si algo sale mal o si se elimina contenido crítico.

15.1 Qué escenarios conviene cubrir

• Borrado accidental: carpetas eliminadas por error antes o después del movimiento.
• Ransomware / cifrado por cuenta comprometida: propagación a carpetas sincronizadas.
• Sobrescritura o cambios no deseados: usuario reemplaza versiones sin darse cuenta.
• Errores de permisos/compartición: exposición indebida o pérdida de acceso.

15.2 Cómo plantearlo sin complicar la operación

Un enfoque razonable combina:

• Controles nativos (papelera, versiones, auditoría) como “primera respuesta”.
• Un plan definido de restauración con roles, tiempos y evidencias (quién restaura, cómo y cuándo).
• Si el cliente lo requiere, una solución de backup adicional (por ejemplo, capacidades específicas de Microsoft 365 Backup o soluciones de terceros), con pruebas periódicas.

Resumen de esta sección: la migración termina bien cuando hay un plan de recuperación probado y responsabilidades claras, no cuando “no pasó nada”.

16. Herramientas y métodos para migrar OneDrive entre tenants: nativo vs terceros (comparativa realista)

En la práctica: la herramienta se elige por requisitos y capacidad operativa. No por “la que siempre se usa”.

En proyectos medianos y grandes, lo habitual es una combinación: enfoque nativo para el movimiento principal y herramientas complementarias para inventario, reporting o casos especiales. Lo importante es que el resultado sea verificable y defendible ante negocio y seguridad.

Resumen de esta sección: el mejor método es el que el cliente puede operar con control, soporte y evidencias, no el que “parece más rápido” sobre el papel.

17. Checklists operativos (pre, durante, post) para migración de OneDrive entre tenants

17.1 Antes de migrar

• CTUDM adquirido y asignado (si se usa enfoque nativo).
• Validación de prerequisitos (holds, Customer Key, OneDrive en destino, Read/Write, límites).
• Usuarios y grupos precreados en destino y licencias asignadas.
• Restricción de creación de OneDrive en destino durante el proyecto.
• Identity mapping (CSV) revisado y versionado.
• Plan de comunicación por oleada + plan de soporte reforzado.

17.2 Durante la migración

• Lanzar oleadas con ventana definida (si aplica) y monitorizar estado.
• Atender fallos por usuario y resolver causas (rutas, OneDrive existente, hold).
• Comunicar avance a negocio con métricas simples (migrados OK / fallos / reprogramados).

17.3 Después

• Validar acceso a OneDrive destino y re-sincronización (OneDrive Sync).
• Revisión de compartición externa e invitados (limpieza y recertificación).
• Aplicar o ajustar Purview (sensibilidad, retención, DLP) en destino.
• Cierre con evidencias: informe de oleadas, incidencias y acciones correctivas.

Resumen de esta sección: checklists convierten la migración en un proceso repetible. Sin ellos, cada oleada se opera “a memoria”.

18. Scripts y snippets útiles (PowerShell/CSV) para cross-tenant OneDrive migration

En la práctica: estos comandos ahorran tiempo en tareas repetitivas, pero no sustituyen al diseño y al mapeo.

# Origen
Connect-SPOService -Url https://origen-admin.sharepoint.com

# Destino
Connect-SPOService -Url https://destino-admin.sharepoint.com

Get-SPOCrossTenantCompatibilityStatus -PartnerCrossTenantHostURL https://destino-my.sharepoint.com/

Get-SPOCrossTenantUserContentMoveState -PartnerCrossTenantHostURL https://destino-my.sharepoint.com/

Start-SPOCrossTenantUserContentMove `
  -SourceUserPrincipalName ana.perez@origen.com `
  -TargetUserPrincipalName ana.perez@destino.com `
  -TargetCrossTenantHostUrl https://destino-my.sharepoint.com/

SourceUserPrincipalName,TargetUserPrincipalName,SourceOneDriveUrl,TargetOneDriveUrl
ana.perez@origen.com,ana.perez@destino.com,https://origen-my.sharepoint.com/personal/ana_perez_origen_com,https://destino-my.sharepoint.com/personal/ana_perez_destino_com

Resumen de esta sección: scripts ayudan a operar, pero el orden del proyecto (prerequisitos, mapeo, oleadas, soporte) sigue siendo lo determinante.

19. Preguntas frecuentes (FAQ ampliadas) sobre migración de OneDrive entre tenants de Microsoft 365

20. Recursos oficiales y enlaces recomendados

• Cross-tenant OneDrive migration (overview)
• Step 1: Connect to source and target tenants
• Step 2: Establish trust
• Step 5: Prepare identity mapping
• Step 6: Start migration
• Step 7: Post migration steps
• Purview: sensitivity labels for SharePoint/OneDrive files
• Purview: retention (policies and labels)
• Microsoft 365 Backup: overview

Servicios relacionados de MSAdvance: Servicios · Modern Workplace · Seguridad y cumplimiento M365.

21. Conclusión: cómo ejecutar una migración de OneDrive entre tenants sin perder control

Una migración de OneDrive entre tenants de Microsoft 365 sale bien cuando se apoya en cuatro pilares: assessment real (bloqueos y límites), identidad y mapeo (permisos y enlaces), ejecución por oleadas (operación y soporte) y gobierno post-migración (Purview, recertificación y compartición externa).

Como siguientes pasos, suele ser útil:

• Seleccionar un piloto representativo (perfiles, volumen, compartición externa).
• Definir y validar identity mapping con usuarios y grupos clave.
• Planificar oleadas con ventanas, soporte y comunicación operativa.
• Cerrar con recertificación de accesos y políticas de cumplimiento en destino.