¿Se necesita una migración de SharePoint entre tenants con seguridad, trazabilidad y un plan que no rompa el trabajo diario?
Si el objetivo es una migración de SharePoint Online entre tenants de Microsoft 365 (tenant-to-tenant) sin improvisaciones —cuidando permisos, enlaces compartidos, estructura y cumplimiento— MSAdvance acompaña de extremo a extremo: assessment, estrategia, ejecución por oleadas y estabilización.
La meta no es “copiar archivos”. La meta es trasladar sitios, bibliotecas, listas y experiencia de usuario con un modelo claro para que el cliente pase de “dos entornos y dudas” a “un único SharePoint gobernado”.
- Diseño de estrategia SharePoint tenant-to-tenant (nativo Microsoft vs herramientas vs enfoque mixto).
- Plan de identidad y permisos: mapeo de usuarios y grupos, mínimo privilegio, recertificación.
- Gobierno y seguridad: Microsoft Purview (sensibilidad, retención, DLP), compartición externa y auditoría.
Contactar con el equipo Ver servicio de Microsoft 365 y SharePoint
Una migración de SharePoint entre tenants es el proceso de mover sitios de SharePoint Online (y su contenido) desde un tenant de Microsoft 365 a otro, manteniendo (en la medida de lo posible) permisos, estructura, historial y enlaces. Bien planificada, permite consolidar entornos por fusiones, separaciones o reestructuraciones, reduciendo riesgo y evitando que la organización pierda productividad por “sitios duplicados”, accesos rotos o contenido desordenado.
Resumen rápido: migración de SharePoint entre tenants en 11 puntos
- Definir el motivo real: fusión/adquisición, carve-out, rebranding, consolidación, cambio de grupo/organización, requisitos legales o de soberanía.
- Elegir estrategia: migración nativa Microsoft (cross-tenant), herramienta de terceros o enfoque mixto con rediseño (cuando conviene ordenar el modelo).
- Inventario serio: sitios, hubs, bibliotecas, listas, personalizaciones, SPFx, flujos Power Automate, Power Apps, compartición externa y contenido sensible.
- Arquitectura destino: modelo de hubs, sitios por área/proceso, bibliotecas por tipo documental, naming y ownership (evitar “un sitio para todo”).
- Identidad y mapeo: preparar usuarios y grupos en destino y construir identity mapping para que permisos funcionen tras el traslado.
- Confianza entre tenants: establecer relación de confianza (trust) y verificar estado antes de lanzar migraciones masivas.
- Compatibilidad sitio a sitio: validar compatibilidad y resolver avisos antes del movimiento (mejor corregir antes que “arrastrar problemas”).
- Plan por oleadas: piloto representativo → oleadas progresivas → estabilización; comunicación y soporte cercano en momentos clave.
- Post-migración realista: validación de navegación, búsqueda, permisos, Teams relacionado, flujos, y revisión de compartición externa.
- Cumplimiento: revisar Purview (sensibilidad/retención/DLP) y recrear lo necesario donde no migre de forma automática.
- Cierre ordenado: retirar trusts cuando ya no hagan falta, limpiar redirecciones cuando proceda, y dejar gobierno operativo para que no se degrade con el tiempo.
¿Cuándo se necesita una migración de SharePoint entre tenants?
No todas las organizaciones necesitan una migración de SharePoint Online entre tenants. Pero cuando existen dos o más tenants (por historia, estructura legal o compras), suele llegar un momento en el que mantener SharePoint duplicado genera coste, riesgo y fricción: contenido repartido, permisos difíciles de auditar y usuarios que no saben “dónde está lo oficial”.
Escenarios habituales
- Fusiones y adquisiciones (M&A): se desea consolidar intranet, documentación operativa y espacios de proyectos en un solo entorno.
- Carve-out / spin-off: una parte del negocio se separa y necesita su propio tenant, moviendo solo determinados sitios y contenido.
- Consolidación de tenants: varias adquisiciones históricas han dejado múltiples SharePoint dispersos y se quiere gobierno centralizado.
- Rebranding o cambio de estructura: se reorganiza el negocio y se decide unificar identidad, navegación y repositorios.
- Requisitos de cumplimiento o región: cambios en políticas internas, auditorías o necesidades regulatorias que aconsejan mover datos a otro tenant.
La señal más clara de que hace falta un proyecto
Cuando la organización ya no puede responder con facilidad a preguntas básicas como: “¿Cuál es el sitio oficial?”, “¿Quién tiene acceso a contratos?”, “¿Dónde se publica el procedimiento vigente?” o “¿Qué se comparte con proveedores?”, normalmente el problema no es técnico: es de gobierno. La migración es la oportunidad de ordenar.
Resumen de transición: antes de hablar de comandos o herramientas, conviene entender por qué se migra y qué se considera éxito (consolidar, separar, reducir riesgo o mejorar gobierno). Con ese objetivo claro, la introducción aterriza qué elementos de SharePoint se ven afectados y por qué el “día después” importa tanto como el movimiento.
Introducción: qué se mueve realmente en una migración SharePoint tenant-to-tenant
Hablar de migración de SharePoint entre tenants suele sonar a “mover sitios”. En la práctica, lo que se traslada (o lo que se debe revisar) es más amplio: contenido, permisos, enlaces compartidos, navegación, búsqueda y dependencias (Teams, Power Platform, integraciones y automatizaciones).
Un sitio no es solo una URL. Un sitio suele tener: bibliotecas con versionado, listas que soportan procesos, páginas (comunicación/intranet), flujos de aprobación, permisos por grupos, invitados externos, y en muchos casos relación con un Microsoft 365 Group (cuando el sitio está conectado a Teams).
Por qué se generan incidencias “inesperadas” si no hay plan
- Permisos: si se cambia de tenant, cambian los identificadores de usuarios/grupos. Sin mapeo correcto, el contenido migra pero los accesos no “encajan”.
- Enlaces: enlaces compartidos, referencias en correos, wikis o pestañas de Teams pueden quedar apuntando al origen si no hay redirecciones o si se cambia el nombre/URL.
- Automatización: Power Automate y Power Apps suelen “atarse” a conexiones (conectores) y a entornos; al cambiar de tenant, puede exigir reautenticación y ajustes.
- Cumplimiento: etiquetas, retención y DLP requieren un tratamiento específico para no perder consistencia ni “dejar huecos”.
Resumen de transición: una migración SharePoint tenant-to-tenant toca contenido, identidad, enlaces y procesos. Por eso, el siguiente paso es definir una metodología: roles, oleadas, decisiones de arquitectura y un modo de validar con negocio.
1. Metodología del proyecto: oleadas, roles y decisiones que evitan sorpresas
En la práctica: una migración de SharePoint entre tenants sale bien cuando se ejecuta con oleadas, piloto real y validación con responsables de negocio, no solo con IT.
En SharePoint, el principal riesgo rara vez es “que falle una copia”. El riesgo real es que el cliente se encuentre, tras el movimiento, con: permisos inconsistentes, sitios que nadie “posee”, enlaces que apuntan a lo viejo o procesos internos rotos. Para reducirlo, funciona un enfoque por oleadas: piloto representativo → oleadas progresivas → estabilización.
1.1 Decisiones que deben cerrarse al inicio
- ¿Se migra tal cual o se aprovecha para ordenar? Si el origen está desordenado, “copiar” traslada el problema al destino.
- ¿Se mantiene la misma estructura de URLs? Cambiar URLs puede ser saludable, pero incrementa el trabajo de comunicación y revisión de referencias.
- ¿Qué se hace con sitios antiguos? Se define si quedan en modo consulta, si se redirigen o si se retiran según política interna.
- ¿Qué se considera “crítico”? contratos, RRHH, finanzas, calidad, proyectos activos, portales con proveedores… para priorizar soporte.
1.2 RACI recomendado (orientativo)
| Actividad | R | A | C | I |
|---|---|---|---|---|
| Inventario y assessment | MSAdvance | IT | Owners de negocio | Dirección |
| Arquitectura destino (hubs/sitios) | MSAdvance | IT | Owners de negocio | Usuarios |
| Identidad, grupos y mapeo | IT | IT | MSAdvance | Seguridad |
| Ejecución técnica por oleadas | MSAdvance | IT | Owners de negocio | Service Desk |
| Validación UAT (sitios críticos) | Owners de negocio | IT | MSAdvance | Dirección |
| Cumplimiento (Purview) | Seguridad/Compliance | Dirección | IT | Owners de negocio |
1.3 Cómo se valida una oleada (sin quedarse en “parece que está”)
- Acceso por rol: el responsable de negocio valida que quien debe editar/leer lo hace sin pedir “permisos manuales”.
- Flujos y procesos: si hay aprobaciones o automatizaciones, se ejecuta un caso real con datos de prueba.
- Compartición externa: si el sitio se comparte con terceros, se valida un acceso real desde un invitado.
- Búsqueda y navegación: los documentos “normales” se encuentran sin tener que conocer el árbol de carpetas.
Resumen de transición: con metodología y validación, el proyecto deja de ser una “copia” y pasa a ser un cambio controlado. El siguiente paso es inventariar: sin un assessment serio, es fácil olvidar dependencias (flujos, invitados, hubs, personalizaciones) que luego generan incidencias.
2. Assessment e inventario: saber qué hay antes de mover un solo sitio
En la práctica: el assessment responde a tres preguntas: qué hay, qué depende de qué, y qué no se debe tocar sin un plan de validación.
El inventario en SharePoint no se limita a contar sitios. Se trata de entender: qué sitios están activos, quién los “posee”, qué bibliotecas tienen contenido sensible, qué se comparte externamente y qué automatizaciones dependen de ese contenido.
2.1 Qué conviene inventariar (mínimo útil)
- Mapa de sitios y hubs: sitios asociados a hubs, intranet, sitios de comunicación, sitios de equipo (a menudo conectados a Teams).
- Volumen y complejidad: tamaño, número de elementos, bibliotecas con muchas versiones, listas grandes, y contenido con uso intensivo.
- Permisos: grupos usados, herencias rotas, accesos directos por usuario (si existen) y bibliotecas con permisos especiales.
- Externo: número de invitados, sitios compartidos con proveedores/clientes, políticas de enlace y caducidad.
- Automatización: flujos Power Automate, formularios, Power Apps, integraciones con ERP/CRM, conectores con credenciales.
- Personalización: SPFx, webparts, páginas modernas críticas, plantillas, scripts, temas, navegación personalizada.
- Cumplimiento: etiquetas de sensibilidad y retención, DLP aplicado, eDiscovery, auditoría y requisitos regulatorios.
2.2 Entregables típicos del assessment (para poder decidir)
| Entregable | Qué contiene | Para qué sirve |
|---|---|---|
| Catálogo de sitios | Owner, uso, criticidad, relación con Teams, externos, volumen | Priorizar oleadas y soporte |
| Mapa de permisos | Grupos, herencias rotas, bibliotecas sensibles, accesos especiales | Preparar identity mapping y evitar caos post |
| Mapa de dependencias | Flujos, apps, integraciones, enlaces críticos | Evitar “funcionaba ayer” |
| Plan de arquitectura destino | Hubs, sitios, bibliotecas, naming, ownership | Que el destino sea sostenible |
| Plan de validación UAT | Casos reales por área | Medir éxito con negocio |
El cliente cree que “solo hay documentos” en un sitio… hasta que se descubre que ese sitio tiene una lista usada por un proceso, un flujo que notifica aprobaciones y una biblioteca compartida con un proveedor. Sin inventario, el riesgo no se ve hasta después de migrar.
Resumen de transición: el assessment convierte un “movamos SharePoint” en un plan con prioridades, dependencias y validación. Con ese inventario, se puede elegir estrategia: nativa de Microsoft, herramienta de terceros o un enfoque mixto (que suele ser lo más realista en entornos complejos).
3. Estrategias de migración de SharePoint entre tenants: nativo vs terceros vs enfoque mixto
En la práctica: la herramienta se elige por objetivo (consolidar, separar, ordenar), no por moda. A veces conviene “mover”, y otras conviene “reconstruir” con migración selectiva.
3.1 Enfoque nativo de Microsoft (cross-tenant SharePoint migration)
Microsoft dispone de un método nativo para migración de sitios de SharePoint entre tenants mediante PowerShell y un modelo de confianza (trust) entre tenants. Es una opción sólida cuando el caso encaja con sus requisitos y límites, y cuando se desea apoyarse en capacidad nativa sin depender de un tercero.
3.2 Herramientas de terceros (cuando se necesita más flexibilidad)
En escenarios con muchas personalizaciones, necesidad de reporting avanzado, transformaciones (reorganizar información) o coexistencia prolongada, es habitual usar herramientas especializadas. La ventaja suele estar en: mapeos complejos, transformaciones, reintentos granulares y paneles de seguimiento.
Un enfoque frecuente es combinar: mover lo “estándar” con el método que mejor encaje, y tratar casos especiales (sitios con particularidades) con una ruta diferente.
3.3 Enfoque mixto (muy común en la práctica)
- “Lift & shift” controlado para sitios simples y bien gobernados.
- Rediseño para intranets o sitios que ya estaban desordenados (mejor reconstruir navegación y publicar contenido “limpio”).
- Migración selectiva de bibliotecas críticas y archivo del resto (evita llevar contenido obsoleto a destino).
3.4 Comparativa rápida (para decidir con criterio)
| Enfoque | Cuándo encaja | Qué exige | Riesgo típico |
|---|---|---|---|
| Nativo Microsoft | Casos alineados con límites; deseo de capacidad soportada por Microsoft | Preparación de trust + identity mapping; cumplimiento de requisitos | Forzar el método en sitios “especiales” y descubrir límites tarde |
| Terceros | Transformación, reporting, casos complejos, muchas excepciones | Licencias del fabricante + diseño de mapeos | Sobre-migrar (mover todo sin filtrar) y heredar desorden |
| Mixto | Organizaciones reales: parte estándar, parte compleja | Buen inventario + segmentación por oleadas | No definir criterios y acabar con dos métodos aplicados “al azar” |
Resumen de transición: elegida la estrategia, el siguiente paso es bajar al detalle del método nativo (si se usa): requisitos, licencias y límites. Entenderlos pronto evita diseñar un plan que luego obliga a “cambiar de carril” a mitad del proyecto.
4. Migración nativa de SharePoint entre tenants (Microsoft cross-tenant): requisitos, licencias y límites
En la práctica: el método nativo funciona muy bien cuando el caso encaja, pero conviene leer los límites con calma para no descubrirlos en el peor momento.
4.1 Licenciamiento (punto que suele olvidarse)
La migración nativa de SharePoint entre tenants requiere licencias específicas de migración cross-tenant (según el programa/licenciamiento del cliente). Esto afecta al calendario: si se compran tarde o se dejan para el final, se bloquea el proyecto cuando ya está todo listo.
4.2 Límites y condiciones típicas (resumen comprensible)
- Compatibilidad: antes de migrar, se debe comprobar el estado de compatibilidad del origen hacia el destino.
- Batching: se pueden poner en cola migraciones por lotes (hay un límite de volumen por batch y conviene planificar varias tandas).
- Tamaño y elementos: hay límites por sitio (tamaño y número de elementos) que influyen en el orden de oleadas.
- Sin incremental: el método no está pensado como “sincronización continua”; es una migración controlada (preflight + ejecución).
- Cifrado/Customer Key: hay escenarios de cifrado avanzado que pueden impedir la migración nativa y exigen alternativa.
- Destino y URL: el destino debe cumplir requisitos de URL y, en ciertos casos, no debe existir previamente.
4.3 Qué ocurre durante y después (lo que los usuarios notan)
- Durante la migración, el sitio origen puede pasar a solo lectura para asegurar consistencia.
- Tras completarse, se pueden crear redirecciones para que quien entre en la URL antigua termine en la nueva (según el flujo nativo de Microsoft).
- Los enlaces compartidos del contenido migrado pueden redirigir al nuevo destino, pero deben validarse casos reales (internos y externos).
Resumen de transición: una vez asumidos requisitos y límites, toca preparar el tenant destino: arquitectura, hubs, seguridad base y gobierno. El destino no debe ser “un contenedor vacío”; debe estar listo para recibir sitios sin convertirse en otro SharePoint desordenado.
5. Preparar el tenant destino: arquitectura, seguridad base y gobierno
En la práctica: la mejor migración fracasa si el destino no tiene ownership, naming, reglas de compartición y un modelo de hubs que ayude a navegar.
5.1 Arquitectura recomendada (evitar el “todo dentro de un sitio”)
- Hubs por área o función: Operaciones, Comercial, Finanzas, RRHH, Calidad, IT, Proyectos.
- Sitios de comunicación: intranet, políticas, procedimientos oficiales (contenido publicado).
- Sitios de equipo: colaboración diaria, documentación en elaboración, proyectos (normalmente conectados a Teams).
5.2 Gobierno mínimo viable (lo que se debe definir sí o sí)
- Ownership: cada sitio con propietario de negocio y responsable técnico.
- Naming: convención para sitios, bibliotecas y grupos (para soporte y escalado).
- Permisos: por grupos, mínimo privilegio, herencia controlada.
- Compartición externa: política por tipo de sitio (interno vs colaboración externa), con caducidad y control de invitados.
- Ciclo de vida: alta, operación, archivo y cierre (especialmente en proyectos).
5.3 Seguridad base antes de abrir el grifo
Antes de recibir contenido, conviene dejar configurado un “suelo” de seguridad: MFA y Acceso Condicional (según política del cliente), revisión de compartición externa, y criterios claros para “sitios con terceros”. Si el destino abre compartición sin control, la migración puede aumentar exposición en lugar de reducirla.
Migrar primero “porque urge” y gobernar después suele acabar en cientos de sitios sin propietarios claros. Preparar el destino con un catálogo de sitios y un proceso de ownership evita ese escenario.
Resumen de transición: con el destino preparado, el siguiente factor crítico es identidad: usuarios, grupos y roles deben existir (y mapearse) para que los permisos del origen tengan sentido en el destino.
6. Identidad y permisos: cómo preparar usuarios, grupos y roles (sin caer en permisos manuales)
En la práctica: si el contenido migra pero los grupos no están bien preparados, el resultado es una avalancha de “no tengo acceso” y cambios manuales que nunca terminan.
6.1 Qué se debe decidir sobre identidad antes de migrar
- UPN y dominios: cómo quedarán los usuarios en destino (mantener direcciones cuando sea posible reduce fricción).
- Grupos: qué grupos se recrean (o se crean) en destino y con qué criterio (por área, por rol, por proceso).
- Propietarios: quién será propietario de cada sitio en destino (pocos y claros).
- Invitados externos: política para invitados existentes: mantener, recrear o depurar por proyecto/caso.
6.2 Principios de permisos que mejor resisten una migración
- Grupos por rol (edición/lectura/propietarios) y evitar permisos individuales salvo excepción justificada.
- Herencia por defecto y romperla solo cuando sea necesario (y documentado).
- Recertificación de accesos en bibliotecas sensibles (por ejemplo, contratos y finanzas).
6.3 Sitios conectados a Microsoft 365 Group (y Teams): por qué requieren atención especial
Cuando un sitio está conectado a un Microsoft 365 Group, los miembros y propietarios del grupo controlan buena parte del acceso. Por eso, al migrar estos sitios, conviene preparar cómo se recrean los grupos en destino y cómo se mapean (alias, owners, miembros).
Resumen de transición: con identidad decidida, el siguiente paso técnico del método nativo es establecer la relación de confianza entre tenants. Ese trust habilita el movimiento y es un requisito previo para ejecutar migraciones y para que el mapeo de identidad funcione.
7. Establecer confianza entre tenants para migrar SharePoint (trust cross-tenant)
En la práctica: el trust es el “puente” entre tenants. Sin trust verificado, la migración nativa no arranca de forma fiable.
En el método nativo de Microsoft, se configura una relación de confianza entre el tenant origen y el tenant destino. Esto no es un detalle menor: se debe planificar quién lo ejecuta, con qué roles, y cómo se valida que ha quedado correctamente establecido.
7.1 Conectar a SharePoint Online (origen y destino)
# Origen
Connect-SPOService -Url https://TENANTORIGEN-admin.sharepoint.com
# Destino (en otra sesión o alternando credenciales)
Connect-SPOService -Url https://TENANTDESTINO-admin.sharepoint.com7.2 Establecer trust (concepto y cuidado)
El trust se configura en ambos lados siguiendo el flujo nativo. Lo importante aquí es: identificar correctamente el Cross-tenant host URL del partner, y ejecutar el comando con el escenario correcto.
7.3 Verificar que el trust está realmente establecido
Tras configurarlo, se consulta el estado del trust para confirmar que ambas partes “se ven” y que el escenario está listo para migrar. Esta verificación debe entrar en checklist; evitar “asumir que está” ahorra muchas horas.
Resumen de transición: con trust listo, la siguiente pieza crítica es el identity mapping: el archivo que le dice a la migración qué usuario/grupo del origen corresponde a qué usuario/grupo del destino.
8. Identity mapping en migración SharePoint entre tenants: el punto crítico para que los permisos funcionen
En la práctica: un identity mapping bien hecho evita el 80% de incidencias post-migración relacionadas con accesos.
Cuando se migra entre tenants, los usuarios y grupos cambian de “identidad técnica” (IDs). Aunque un usuario se llame igual, el identificador interno en el nuevo tenant es distinto. El identity mapping permite que permisos y propietarios se reasignen correctamente.
8.1 Preparación: precrear usuarios y grupos en destino
Antes de mapear, se debe asegurar que los usuarios y grupos relevantes existen en destino. El enfoque suele ser: usuarios y grupos críticos primero (owners, grupos de edición/lectura, seguridad y M365 Groups conectados a Teams).
8.2 Formato de mapping (visión práctica)
En la práctica se prepara un CSV con pares origen→destino. Lo importante no es “rellenar un Excel”: lo importante es que el CSV refleje el modelo real de permisos.
SourceObjectId,TargetObjectId,ObjectType
11111111-1111-1111-1111-111111111111,aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa,User
22222222-2222-2222-2222-222222222222,bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb,Group8.3 Reglas que ayudan a no equivocarse
- Mapear owners y grupos clave antes de mover sitios críticos (si no, se migra “sin dueño”).
- Reducir grupos redundantes durante el proyecto: si hay diez grupos “parecidos”, el destino se vuelve inmanejable.
- Documentar excepciones: bibliotecas con permisos rotos, sitios sensibles, accesos temporales a terceros.
Resumen de transición: con identity mapping preparado, toca validar compatibilidad. La compatibilidad es el filtro que indica si un sitio puede migrar tal cual, si tendrá avisos o si requiere estrategia alternativa.
9. Compatibilidad y preflight: validar antes de ejecutar la migración de SharePoint tenant-to-tenant
En la práctica: compatibilidad “Warning” no siempre bloquea, pero sí exige revisión. Ignorar warnings suele convertirse en incidencias post.
Antes de iniciar el movimiento, se debe comprobar el estado de compatibilidad del origen respecto al destino. Esto permite detectar bloqueos y avisos de forma temprana.
# Ejecutar desde el tenant origen (indicando el host URL del destino)
Get-SPOCrossTenantCompatibilityStatus -PartnerCrossTenantHostURL https://TENANTDESTINO-my.sharepoint.com/9.1 Qué hacer con los resultados
- Compatible: se puede planificar la migración en oleada estándar.
- Warning: se revisa la causa, se decide si se asume o se corrige antes.
- No compatible: se saca del carril nativo y se define estrategia alternativa.
9.2 Buenas prácticas con compatibilidad
- Priorizar la compatibilidad de sitios críticos en el piloto.
- Separar en oleadas diferentes “sitios limpios” y “sitios con avisos”.
- Evitar que el calendario lo decida todo: el orden debe seguir criticidad y complejidad.
Resumen de transición: con compatibilidad revisada, llega el momento de ejecutar. En SharePoint conviene pensar la ejecución como una cola de trabajos: lotes, programación, monitorización y validación al cierre de cada oleada.
10. Ejecución: iniciar migraciones de sitios y de grupos conectados a Microsoft 365
En la práctica: ejecutar no es “lanzar un comando”. Ejecutar es controlar lotes, programar ventanas, monitorizar estados y validar con negocio.
10.1 Migración de un sitio SharePoint (site-to-site)
Para migrar un sitio, el administrador del origen inicia el movimiento indicando: URL de origen, URL de destino y el host cross-tenant del destino.
Start-SPOCrossTenantSiteContentMove `
-SourceSiteUrl "https://TENANTORIGEN.sharepoint.com/sites/ProyectoX" `
-TargetSiteUrl "https://TENANTDESTINO.sharepoint.com/sites/ProyectoX" `
-TargetCrossTenantHostUrl "https://TENANTDESTINO-my.sharepoint.com/"10.2 Migración de sitio conectado a Microsoft 365 Group (normalmente Teams)
Cuando el sitio está conectado a un Microsoft 365 Group, el arranque se hace por alias de grupo. Aquí es donde una buena preparación de grupos (y su alias) en destino reduce incidencias.
Start-SPOCrossTenantGroupContentMove `
-SourceGroupAlias "equipo-proyectox" `
-TargetGroupAlias "equipo-proyectox" `
-TargetCrossTenantHostUrl "https://TENANTDESTINO-my.sharepoint.com/"10.3 Programar migraciones para una hora concreta
Si se desea controlar ventanas (por ejemplo, fuera de horario), se pueden programar migraciones con fecha/hora preferida en UTC. Esto ayuda a coordinar lotes grandes y a alinear con soporte.
Start-SPOCrossTenantSiteContentMove `
-SourceSiteUrl "https://TENANTORIGEN.sharepoint.com/sites/Finanzas" `
-TargetSiteUrl "https://TENANTDESTINO.sharepoint.com/sites/Finanzas" `
-TargetCrossTenantHostUrl "https://TENANTDESTINO-my.sharepoint.com/" `
-PreferredMoveBeginDate "2026-01-18T20:00:00Z"10.4 Qué conviene comunicar al usuario final en ejecución
- Si habrá periodos de solo lectura en el origen.
- Cómo acceder al nuevo sitio en destino (y con qué credenciales).
- Qué hacer si aparece un “no tengo acceso” (canal de soporte y plazo de resolución).
- Qué ocurrirá con enlaces compartidos a terceros durante la transición.
Resumen de transición: una vez lanzadas migraciones, el trabajo pasa a ser monitorizar y corregir: estados, reintentos, cancelación si procede y, sobre todo, validación post para no acumular “deuda” de incidencias.
11. Monitorización y control: estados, cancelación y resolución de errores
En la práctica: monitorizar es lo que convierte una migración en un proceso predecible. Sin seguimiento, el proyecto se convierte en una lista de sorpresas.
11.1 Consultar estado de migraciones
El estado se consulta desde origen o destino indicando el host del partner. Conviene usar una convención interna (oleada, lote, criticidad) para saber qué se está mirando y qué soporte debe estar atento.
Get-SPOCrossTenantUserContentMoveState `
-PartnerCrossTenantHostURL "https://TENANTDESTINO-my.sharepoint.com/"11.2 Estados típicos (para entender qué está pasando)
- NotStarted / Scheduled: está en cola.
- ReadyToTrigger: preflight / preparación.
- InProgress: en ejecución (validación, backup, restore, cleanup).
- Success: completada.
- Rescheduled: reencolada para reintento.
- Failed: fallida; se analiza causa y se decide reintento o cambio de estrategia.
11.3 Cancelar una migración (cuando procede)
En ocasiones conviene cancelar: por ejemplo, si se detecta un error de destino (URL incorrecta, grupo no preparado, ventana equivocada) antes de que el proceso esté “en progreso”.
Stop-SPOCrossTenantSiteContentMove -SourceSiteURL "https://TENANTORIGEN.sharepoint.com/sites/ProyectoX"Resumen de transición: tras la migración técnica llega el trabajo más visible: post-migración (redirecciones, enlaces, limpieza, retirada de trusts, validación funcional y estabilización). Es donde se decide si el cliente percibe la migración como “orden” o como “problemas nuevos”.
12. Post-migración: redirecciones, enlaces compartidos, limpieza y estabilización
En la práctica: el post-migración es lo que protege la experiencia del usuario. La migración “termina” cuando el trabajo diario vuelve a ser normal, no cuando el comando devuelve Success.
12.1 Redirecciones: por qué ayudan (y por qué hay que gestionarlas)
En el flujo nativo de Microsoft, tras completar migraciones se pueden crear redirecciones para que quien acceda al sitio origen sea llevado al nuevo sitio en destino. Esto reduce consultas y evita que usuarios sigan trabajando “en lo viejo”.
Sin embargo, las redirecciones deben gestionarse con cuidado: si en el futuro se necesita “mover de vuelta” un sitio o un usuario, las redirecciones pueden generar conflictos de URL si no se retiran.
12.2 Retirada de la relación de confianza (cuando ya no hace falta)
Una vez completada la migración y estabilizado el entorno, conviene retirar la relación de trust para no mantener un puente abierto más tiempo del necesario. Además, hay que considerar los plazos asociados al licenciamiento del escenario de migración.
12.3 Verificaciones post-migración (mínimo por sitio crítico)
- Accesos: owners, editores, lectores y externos (si aplica).
- Bibliotecas: versionado, vistas y metadatos obligatorios.
- Enlaces compartidos: prueba real con un usuario interno y, si aplica, un invitado.
- Navegación: pertenencia a hub, menús, accesos desde intranet.
- Búsqueda: documentos principales aparecen con permisos correctos.
Resumen de transición: tras estabilizar SharePoint, el siguiente bloque es revisar dependencias: Power Automate, Power Apps, formularios y conexiones suelen ser la causa de incidencias “silenciosas” (nadie lo ve hasta que falla un proceso).
13. Power Automate, Power Apps y dependencias: qué revisar para que no se rompa negocio
En la práctica: una migración de SharePoint entre tenants puede mover contenido, pero los procesos automatizados suelen necesitar reconfiguración y validación funcional.
13.1 Power Automate: patrones de fallo habituales
- Conexiones: un flujo que usaba una cuenta/connector del tenant origen puede requerir reautenticación en destino.
- Referencias: flujos que apuntan a URLs antiguas o a listas específicas pueden necesitar actualización.
- Permisos: el propietario del flujo en destino debe tener permisos equivalentes.
13.2 Power Apps y formularios
Si hay Power Apps integradas con listas/bibliotecas, conviene validar: fuentes de datos, roles, entornos (si se usa Dataverse) y permisos de lectura/escritura. Un error típico es que la app “abre” pero no guarda porque el conector apunta al tenant antiguo o porque el usuario no tiene permisos en destino.
13.3 Estrategia práctica
- Inventario de flujos/apps por criticidad (no todo se prueba igual).
- Reautenticación y revisión de conectores en una ventana controlada.
- UAT con negocio (casos reales, no pruebas superficiales).
Resumen de transición: revisadas dependencias, se entra en el terreno de personalizaciones: páginas, listas y componentes. Parte suele migrar bien, pero conviene anticipar qué elementos requieren ajuste para evitar regresiones en intranet o portales.
14. Páginas, listas y personalizaciones: qué suele migrar y qué suele requerir ajuste
En la práctica: el contenido se mueve, pero la “experiencia” (navegación, webs, integraciones) puede necesitar ajustes para que el usuario no perciba retrocesos.
14.1 Páginas modernas e intranet
En intranets, el reto no es solo mover páginas: es asegurar que: enlaces internos apuntan a destino, componentes siguen disponibles y la navegación del hub se mantiene. Si el proyecto aprovecha para reordenar la intranet, conviene migrar contenido “publicado” y reconstruir navegación con un criterio claro.
14.2 Listas y procesos
Muchas organizaciones usan listas como base de procesos (registro de solicitudes, incidencias internas, inventarios, etc.). Aunque el contenido migre, conviene revisar: columnas calculadas, formatos, reglas, vistas, permisos específicos y automatizaciones conectadas.
14.3 SPFx y componentes personalizados
Si existen webparts SPFx o integraciones con APIs, el cambio de tenant puede exigir: reconfiguración de permisos, nuevo registro de app, ajustes de URLs y validación de autenticación. Estos componentes deben entrar en el inventario y en la planificación de UAT.
Resumen de transición: el siguiente bloque es cumplimiento: etiquetas de sensibilidad, retención y DLP. Es lo que hace defendible el entorno ante auditoría y lo que reduce riesgos de exposición.
15. Seguridad y cumplimiento en migración de SharePoint entre tenants: Purview, retención y DLP
En la práctica: cumplimiento no es un “extra”. En sectores auditados, es parte del criterio de éxito. Incluso en sectores no regulados, reduce exposición y ordena el ciclo de vida de la información.
15.1 Etiquetas de sensibilidad (Purview)
Las etiquetas de sensibilidad permiten clasificar y proteger información (por ejemplo, Interno, Confidencial, Alto). En migraciones entre tenants, conviene: documentar qué etiquetas existen en origen, definir el catálogo en destino y planificar la re-aplicación donde no se transfiera automáticamente o donde el proceso exija retirarlas antes de mover.
15.2 Retención y disposición
Retención define cuánto tiempo se conserva la información y qué pasa después (revisión, eliminación, archivo). En una migración, la práctica recomendada es: acordar con legal/compliance el marco de retención destino y recrear políticas/etiquetas según el modelo del cliente, evitando que el contenido se quede “sin reglas” tras el movimiento.
15.3 DLP (Data Loss Prevention)
DLP ayuda a detectar y limitar escenarios de fuga, como compartir externamente documentos con datos personales o financieros. La implantación suele ser gradual: empezar en modo auditoría, medir impacto y endurecer cuando el cliente confirma que procesos legítimos no se bloquean.
Resumen de transición: con seguridad y cumplimiento encajados, el “día después” se centra en experiencia: enlaces, navegación, búsqueda y accesos. Ahí se percibe si el entorno quedó “más fácil” o “más confuso”.
16. Enlaces, navegación, búsqueda y experiencia de usuario: el “día después” de la migración SharePoint tenant-to-tenant
En la práctica: cuando un usuario dice “no encuentro nada”, casi siempre es una mezcla de navegación, permisos y expectativas sobre dónde está lo oficial.
16.1 Enlaces internos y externos
- Internos: enlaces en páginas, wikis, news, Teams y correos guardados pueden necesitar revisión si cambian URLs.
- Externos: colaboración con proveedores/clientes exige pruebas reales con invitados; conviene revisar caducidad, “personas específicas” y políticas del tenant destino.
16.2 Navegación y hubs
Si el destino se basa en hubs por área, tras migrar cada sitio conviene: asociarlo al hub correcto, revisar menús y asegurar que el usuario llega sin “conocer la URL”. Esto reduce dependencia de marcadores antiguos.
16.3 Búsqueda y resultados
La búsqueda funciona bien cuando hay: naming razonable, metadatos mínimos y permisos consistentes. Tras migrar, conviene validar búsquedas típicas por área (contratos por cliente, procedimientos vigentes, facturas por año…), asegurando que los resultados respetan permisos.
Publicar una guía corta (una página) con: “dónde está ahora”, “cómo acceder”, “cómo pedir acceso”, “cómo compartir externamente”. Es simple, pero reduce tickets en la primera semana.
Resumen de transición: para cerrar el proyecto con orden, conviene usar checklists y KPIs: qué se revisa antes/durante/después y cómo se mide éxito (menos tickets, permisos correctos, procesos funcionando).
17. Checklists operativos (pre, durante, post) y KPIs para migración de SharePoint entre tenants
17.1 Checklist antes de migrar (por oleada)
- Inventario de sitios de la oleada: owners, criticidad, externos, dependencias.
- Destino listo: arquitectura, hubs, políticas de compartición aplicadas.
- Usuarios y grupos precreados en destino; identity mapping revisado.
- Trust establecido y verificado; compatibilidad comprobada.
- Plan de comunicación y soporte para la oleada.
- Plan de validación UAT (quién valida y qué casos).
17.2 Checklist durante la migración
- Monitorizar estados (Scheduled/InProgress/Success/Failed).
- Registrar incidencias por sitio y decidir acción (reintento, ajuste, estrategia alternativa).
- Confirmar si el origen entra en solo lectura y comunicarlo si afecta.
- Coordinar con service desk para tratar incidencias de acceso en tiempo real.
17.3 Checklist después (por sitio crítico)
- Acceso por rol (propietarios, editores, lectores) validado.
- Compartición externa validada (si aplica).
- Navegación/hub revisados; enlaces internos principales corregidos.
- Flujos y apps dependientes probados (caso real).
- Revisión de cumplimiento (sensibilidad/retención/DLP según modelo destino).
17.4 KPIs prácticos (para hablar con negocio)
| Métrica | Qué mide | Objetivo típico |
|---|---|---|
| Incidencias por sitio migrado (semana 1) | Ruido post | Controlado y decreciente |
| Accesos correctos en UAT | Calidad del mapping | ≥ 95–98% según criticidad |
| Procesos críticos operativos | Power Platform / integraciones | 100% en sitios críticos |
| Reducción de “doble trabajo” | Usuarios trabajando en el origen por error | Reducir a mínimo por redirecciones y comunicación |
Resumen de transición: por último, conviene documentar riesgos típicos y mitigaciones. No para asustar, sino para que el cliente vea que hay un plan ante escenarios frecuentes (permisos, enlaces, sitios especiales, cumplimiento).
18. Riesgos frecuentes y mitigaciones en migración de SharePoint entre tenants
En la práctica: el riesgo se reduce cuando se identifica temprano y se decide: corregir, aceptar con plan, o sacar del carril estándar.
| Riesgo | Impacto | Señal temprana | Mitigación |
|---|---|---|---|
| Identity mapping incompleto | Alta | Muchos “no tengo acceso” en piloto | Precrear usuarios/grupos, mapear owners, validar por rol en UAT |
| Ignorar warnings de compatibilidad | Media/Alta | Compatibilidad “Warning” repetida en sitios críticos | Analizar causa, separar oleada, ajustar antes o cambiar estrategia |
| Enlaces externos críticos | Alta | Muchos accesos de terceros y enlaces antiguos | Plan de validación con invitado real, política de enlaces y comunicación |
| Subestimar Power Automate/Apps | Alta | Flujos “fantasma” con cuentas antiguas | Inventario, reautenticación, UAT por proceso |
| Destino sin gobierno | Alta | Se crean sitios sin owners/naming | Modelo de hubs, ownership, proceso de provisión y ciclo de vida |
Resumen de transición: cerrando el cuerpo de la guía, se incluyen FAQs para resolver dudas comunes y recursos oficiales para profundizar, además de una conclusión con siguientes pasos prácticos.
19. Preguntas frecuentes (FAQ) sobre migración de SharePoint entre tenants de Microsoft 365
¿Qué diferencia hay entre migrar SharePoint y migrar OneDrive entre tenants?
SharePoint implica sitios, bibliotecas, listas, páginas y, a menudo, estructura de intranet y permisos por roles/grupos. OneDrive es almacenamiento personal por usuario. En tenant-to-tenant, los dos pueden coexistir en el proyecto, pero la gobernanza y la experiencia de usuario en SharePoint suelen requerir más trabajo de arquitectura y validación.
¿Se puede migrar por fases (oleadas) en lugar de hacerlo todo de golpe?
Sí. De hecho, suele ser lo recomendable: piloto representativo, oleadas por áreas y estabilización por lote. Migrar por fases permite aprender, corregir y reducir impacto en operaciones.
¿Qué pasa con los permisos al cambiar de tenant?
Como los identificadores cambian, se necesita un enfoque de mapeo (identity mapping) y preparación de grupos en destino. Con un mapping bien hecho, los permisos por rol se mantienen y se reduce la necesidad de ajustes manuales.
¿Los enlaces compartidos a documentos se rompen?
Depende del método y del escenario. En el enfoque nativo, el flujo contempla redirecciones y continuidad de enlaces compartidos, pero siempre conviene validar casos reales (internos y externos) porque el “día después” es donde se detectan enlaces críticos.
¿Qué se recomienda hacer con sitios antiguos tras la migración?
Normalmente se redirigen temporalmente para reducir confusión y, cuando el proyecto está estabilizado, se planifica retirada ordenada: limpieza, archivo o cierre según gobierno. La decisión depende de obligaciones de retención, auditoría y necesidades de consulta histórica.
¿Qué suele dar más problemas: contenido, permisos o automatización?
En muchos entornos, lo más delicado es el conjunto permisos + automatización: accesos por grupos mal mapeados y flujos Power Automate con conexiones antiguas. Por eso se insiste en inventario, mapping y UAT por proceso.
¿SharePoint tenant-to-tenant es viable en organizaciones grandes?
Sí, siempre que exista gobierno y segmentación por oleadas, y se trate por separado lo estándar y lo especial. El tamaño exige más disciplina (checklists, KPIs, validación) pero no cambia la lógica del enfoque.
20. Recursos oficiales y enlaces recomendados
- Cross-tenant SharePoint migration overview (Microsoft Learn)
- Step 1: Connect to the source and target tenants
- Step 2: Establish trust
- Step 5: Prepare identity mapping
- Step 6: Start a cross-tenant SharePoint migration
- Step 7: Post migration steps
- Microsoft Purview: sensitivity labels
- Servicios relacionados de MSAdvance: Modern Workplace y SharePoint
21. Conclusión y siguientes pasos en una migración de SharePoint entre tenants
Una migración de SharePoint entre tenants de Microsoft 365 es un proyecto de contenido, identidad y gobierno. Funciona cuando se apoya en: inventario real, estrategia adecuada (nativa/terceros/mixta), identity mapping sólido, ejecución por oleadas, y una fase post-migración centrada en experiencia (permisos, enlaces, navegación y procesos).
Como siguientes pasos, suele ser útil:
- Realizar un assessment que identifique sitios críticos, dependencias y riesgos (externos, automatización, cumplimiento).
- Definir arquitectura destino (hubs, sitios, naming, ownership) antes de mover.
- Diseñar plan por oleadas con piloto representativo y validación UAT por rol.
- Preparar identidad, y ejecutar con monitorización y estabilización (no solo “mover”).
¿Se desea que MSAdvance ejecute la migración de SharePoint entre tenants de forma controlada?
MSAdvance puede encargarse del assessment, la estrategia (nativa/terceros/mixta), la ejecución por oleadas y la estabilización, cuidando seguridad, cumplimiento y adopción.
