Kloudeal Journal · Guía para empresas
Migrar SharePoint entre tenants requiere conservar el contexto de los documentos: sitios, bibliotecas, metadatos, versiones y accesos. Esta guía explica cómo definir el alcance, comparar los métodos y validar la información y los procesos que dependen del entorno.
Bibliotecas, listas, documentos, versiones y metadatos.
Identidades, grupos, invitados y permisos.
Teams, automatizaciones, enlaces y aceptación.
Contenido de esta guía
Cómo migrar un expediente de SharePoint conservando su utilidad
Al migrar SharePoint entre tenants, un documento debe revisarse dentro de su contexto de uso. Una biblioteca puede organizar contratos por cliente, estado y responsable, y utilizar esos campos en vistas o procesos. Aunque todos los archivos lleguen al nuevo tenant, el departamento puede perder capacidad de trabajo si no se conservan o adaptan los elementos que permiten encontrarlos y gestionarlos.
Un piloto útil toma un expediente representativo y documenta cómo lo utiliza el propietario en origen. Después se repite el recorrido en destino: localizarlo por sus campos, abrir sus documentos, consultar las versiones incluidas y comprobar el acceso con varios perfiles. Si existe un flujo o una aplicación que actúa sobre ese contenido, se prueba también. Esas dependencias no deben considerarse resueltas únicamente porque la biblioteca sea accesible.
La decisión de conservar o reorganizar debe tomarse antes de la transferencia. Cambiar estructura y permisos puede tener sentido, pero necesita un diseño y una validación diferentes de una réplica del origen. El inventario debe separar qué elementos se trasladan con la herramienta y qué se reconstruye o adapta, para que el propietario conozca el resultado que va a aceptar.
Qué ocurre con los enlaces y los colaboradores después del traslado
Los enlaces forman parte de procesos que a menudo no aparecen en el inventario técnico. Un documento puede estar referenciado desde una página, un correo, una aplicación o un procedimiento interno. El tratamiento de esos accesos depende del método y del alcance, por lo que deben identificarse las rutas de uso críticas y probarlas expresamente en el destino.
Los colaboradores externos requieren una comprobación adicional de identidad y permisos. El propietario confirma quién debe seguir accediendo y el equipo técnico valida el recorrido con una cuenta representativa. El cierre debe incluir las comunicaciones y actualizaciones que queden pendientes; de otro modo, un sitio correctamente migrado puede generar incidencias cuando sus usuarios intenten entrar desde una referencia antigua.
1. Definir qué significa migrar SharePoint entre tenants
Un proyecto de SharePoint entre tenants traslada información de una organización de Microsoft 365 a otra. El trabajo puede responder a una adquisición, una separación empresarial o la consolidación de varias plataformas. Antes de seleccionar una herramienta conviene describir qué espacios deben trasladarse, qué personas los utilizan y qué procesos dependen de ellos. Esa definición evita tratar todos los sitios como si fueran carpetas equivalentes.
El alcance debe distinguir contenido, estructura, acceso y funcionamiento. Copiar documentos es una parte. Las columnas de una biblioteca, las vistas que utiliza un departamento, los grupos que autorizan el acceso o una aprobación automatizada pueden ser igual de importantes. Cada componente necesita una decisión: trasladar, reconstruir, sustituir, conservar temporalmente o retirar con autorización.
Un inventario útil relaciona cada sitio con un propietario de negocio y con un responsable técnico. El primero confirma qué información necesita la actividad; el segundo valida la solución y sus dependencias. Si no existe propietario, la falta de interlocutor debe resolverse durante la preparación. No conviene descubrir quién puede aceptar el resultado cuando el cambio ya está en marcha.
2. Inventariar sitios, bibliotecas y listas
El inventario debe identificar la dirección de cada sitio, su finalidad, el tipo de espacio y su relación con otros servicios. Es importante diferenciar una intranet de comunicación, un área documental de un departamento y un sitio conectado a un equipo de Microsoft Teams. Aunque todos almacenen documentos, su uso y sus criterios de validación pueden ser distintos.
Para cada biblioteca conviene registrar el volumen, el número de elementos, la profundidad de carpetas y las características utilizadas. Las listas necesitan una revisión propia: columnas, relaciones, formularios y aplicaciones que consultan sus datos. Un informe agregado de almacenamiento ayuda a estimar capacidad, pero no permite por sí solo calcular la complejidad del proyecto.
También deben localizarse espacios inactivos, duplicados y repositorios que únicamente se conservan por consulta histórica. Su tratamiento se acuerda con los responsables, sin eliminar información por una decisión técnica unilateral. Clasificar los sitios permite organizar las oleadas por criticidad y dependencia, en lugar de seguir simplemente el orden de una exportación administrativa.
3. Elegir el método a partir del escenario
Las opciones disponibles incluyen funciones nativas de Microsoft y herramientas especializadas. La comparación debe partir del escenario real: sitio completo o contenido seleccionado, destino nuevo o existente, necesidad de reorganización, tratamiento de versiones y permisos, y posibilidad de realizar varias pasadas. Un producto adecuado para un traslado directo puede no ser el más apropiado para una consolidación con cambios de estructura.
La función nativa de traslado de sitios tiene requisitos específicos de disponibilidad y contratación. Microsoft la documenta como un movimiento único, sin pasadas incrementales. Por tanto, no debe diseñarse una premigración con deltas alrededor de ese método sin comprobar su comportamiento. Las herramientas de copia pueden ofrecer estrategias diferentes, que también deben contrastarse con su documentación.
La decisión debe quedar reflejada en una matriz de cobertura y en una prueba. El nombre comercial de la herramienta no demuestra que un objeto concreto se conserve. Conviene registrar para cada requisito el comportamiento esperado, la evidencia del piloto y la alternativa prevista si la funcionalidad no está soportada.
4. Preparar una matriz de cobertura
La matriz traduce las necesidades del negocio a comprobaciones técnicas. Debe ser breve para poder revisarse y suficientemente precisa para evitar interpretaciones distintas. Expresiones como «migración completa» resultan poco útiles si no se ha definido qué significa conservar una versión, un enlace o un permiso.
| Componente | Qué decidir | Qué comprobar |
|---|---|---|
| Documentos | Contenido incluido y excepciones | Apertura, edición y adjuntos relevantes |
| Bibliotecas | Estructura, columnas y vistas | Organización y consulta de la información |
| Versiones | Histórico que debe conservarse | Versiones recuperables en una muestra acordada |
| Permisos | Mapeo y modelo de acceso | Acceso permitido y acceso denegado |
| Enlaces | Continuidad o sustitución | Funcionamiento con identidades del destino |
| Integraciones | Reconstrucción o adaptación | Proceso empresarial de principio a fin |
Cuando aparezca una excepción debe añadirse a esta matriz, con un responsable y una fecha de resolución. Una limitación conocida puede gestionarse; una suposición no documentada suele convertirse en una incidencia durante el cambio. El documento debe acompañar al proyecto hasta la aceptación final.
5. Preparar identidades, grupos y propietarios
Los permisos de origen hacen referencia a identidades de ese entorno. El proyecto debe relacionarlas con las personas, grupos y cuentas que utilizarán los recursos en el destino. Un nombre visible parecido no es suficiente para establecer esa relación. Las cuentas renombradas, los antiguos empleados y las direcciones compartidas merecen una revisión explícita.
El mapeo debe incluir propietarios, miembros, grupos de acceso e invitados que deban conservar su colaboración. También conviene acordar qué ocurre con las identidades que no tendrán equivalente. Asignar sus permisos a una cuenta genérica por comodidad puede modificar la exposición de la información y dificultar la administración posterior. La validación tiene que realizarse con usuarios representativos, no únicamente con una cuenta administradora. Un administrador puede abrir un documento aunque el modelo de acceso de los usuarios esté mal reconstruido. Deben probarse tanto los accesos necesarios como los que deben permanecer restringidos, especialmente en documentación de dirección, recursos humanos o información comercial sensible.
6. Revisar permisos e herencias
Una migración ofrece la oportunidad de comprender los permisos existentes, pero no autoriza a rediseñarlos sin acuerdo. Conviene distinguir una reproducción del modelo actual de un proyecto de reorganización. Si se pretende simplificar grupos o recuperar herencias, esos cambios necesitan aprobación y criterios propios de validación. Los permisos únicos en carpetas, documentos o elementos de lista pueden aumentar considerablemente la complejidad. El inventario debe identificar dónde se utilizan y quién puede explicar su finalidad. Un repositorio con muchas excepciones necesita un muestreo diferente de una biblioteca que hereda todos sus accesos desde el sitio.
La documentación de entrega debe permitir comprender el modelo final. Resulta útil relacionar grupos, responsables y finalidad, sin publicar listados innecesarios de información personal. El objetivo es que una incorporación, una baja o un cambio de función puedan administrarse después de la migración sin depender del conocimiento informal de quien ejecutó la copia.
7. Acordar versiones y metadatos
El contenido de un documento no explica todo su contexto. Fechas, autores, tipos de contenido y columnas ayudan a localizarlo y a utilizarlo en los procesos de la empresa. Antes de migrar conviene decidir cuáles son necesarios y comprobar cómo los trata el método elegido. No todas las herramientas reproducen todos los tipos de columna o las relaciones con otros objetos.
El histórico de versiones también debe definirse como un requisito concreto. Puede ser necesario conservar todas las versiones disponibles, un conjunto acordado o únicamente el documento actual. La decisión afecta al volumen, al tiempo y a las pruebas. Debe tomarla el responsable de la información con el apoyo técnico adecuado.
La muestra de validación debe incluir documentos con cambios reales de versión y metadatos representativos. Revisar solo archivos recién creados puede ocultar problemas. Además de contar elementos, conviene comprobar que los usuarios pueden encontrar la información mediante las vistas y filtros que utilizan habitualmente.
8. Separar SharePoint de sus dependencias con Teams
Muchos documentos de Teams se almacenan en SharePoint, pero trasladar el sitio no demuestra que el equipo, sus canales o sus conversaciones estén migrados. El proyecto debe identificar la relación entre ambos servicios y decidir cómo se coordinarán. Los propietarios de los equipos necesitan conocer qué cambia y desde dónde accederán después.
Los canales con espacios documentales asociados deben inventariarse de forma que no queden repositorios fuera del alcance por una lectura superficial del sitio principal. Conviene comprobar los vínculos y las pestañas utilizados por los usuarios, así como las aplicaciones que ofrecen acceso a bibliotecas o listas. El piloto debe probar la experiencia desde Teams y desde el navegador. Un archivo puede abrirse directamente en SharePoint y, sin embargo, seguir enlazado a una ubicación antigua desde una pestaña. Esa diferencia explica por qué las pruebas funcionales deben seguir las rutas de trabajo habituales, además de verificar la existencia técnica del contenido.
9. Revisar Power Automate, Power Apps e integraciones
Las automatizaciones pueden depender de direcciones, identificadores, conexiones y permisos del tenant de origen. Deben inventariarse por separado de los documentos y asignarse a un responsable. La migración de una lista no implica que un flujo de aprobación o una aplicación que la consulta vaya a continuar funcionando sin intervención.
Para cada integración conviene registrar qué inicia el proceso, con qué identidad se ejecuta, qué datos consulta y qué resultado genera. Esa descripción permite preparar una prueba verificable. También ayuda a detectar credenciales personales utilizadas en procesos empresariales y dependencias de cuentas que se retirarán durante el cambio. La adaptación de aplicaciones y flujos debe presupuestarse y planificarse cuando forme parte del encargo. Si está fuera de alcance, la exclusión debe ser comprensible y tener un responsable en el cliente. Dejarla como una observación al final del informe puede provocar que la información esté disponible, pero el proceso empresarial quede interrumpido.
10. Tratar enlaces y colaboración externa
Los enlaces utilizados por los usuarios pueden estar en documentos, correos, páginas de intranet, accesos directos o aplicaciones. Su comportamiento tras la migración depende del método y de la configuración. Conviene distinguir enlaces compartidos, referencias directas a una dirección y vínculos internos de un documento. No debe prometerse una continuidad universal sin una prueba representativa.
La colaboración externa requiere revisar las identidades invitadas y las políticas del destino. Mantener un archivo compartido no basta si el destinatario no puede autenticarse o si el nuevo entorno restringe la forma de compartirlo. Los responsables deben acordar qué colaboraciones continúan y qué accesos dejan de ser necesarios. La comunicación debe explicar qué enlaces deben actualizarse y cómo se atenderán los avisos de acceso. Para repositorios críticos puede prepararse una relación de referencias prioritarias. Esa lista permite concentrar las pruebas donde una interrupción tendría mayor impacto, en lugar de intentar revisar manualmente todos los enlaces de la organización con el mismo nivel de detalle.
11. Diseñar un piloto representativo
El piloto debe incluir casos habituales y excepciones relevantes. Es útil seleccionar una biblioteca sencilla, otra con permisos únicos, documentos con versiones, una lista utilizada por una aplicación y un sitio relacionado con Teams. La selección se adapta al inventario; no se trata de completar una plantilla sin relación con el entorno.
Antes de ejecutar la prueba deben definirse los resultados esperados. Cada propietario tiene que saber qué revisará y cómo registrará las incidencias. También conviene documentar los tiempos observados, los errores y las tareas manuales. Esa información permite revisar el calendario de las oleadas con una base más realista. Un piloto no termina cuando finaliza la tarea de la herramienta. Se cierra cuando se han probado los escenarios acordados, se han resuelto las incidencias relevantes y se conocen las limitaciones que afectarán a producción. Si cambia el método o aparece un requisito nuevo importante, puede ser necesario repetir la parte de la prueba que resulte afectada.
12. Organizar oleadas y ventana de cambio
Las oleadas pueden agrupar sitios por departamento, relación funcional o dependencia técnica. El criterio debe permitir una transición comprensible para los usuarios y manejable para el equipo de soporte. Separar sitios que forman parte de un mismo proceso puede aumentar las incidencias aunque reduzca el volumen de cada tarea. La posibilidad de copiar previamente y ejecutar una pasada posterior debe comprobarse en el método concreto. Si se utiliza un traslado único, la estrategia será diferente. El plan debe identificar cuándo se permiten cambios en origen, cómo se controla esa actividad y en qué momento se comunica que el destino pasa a ser la ubicación de trabajo.
La ventana de cambio necesita responsables, comprobaciones previas y un criterio de decisión. Si falla una condición crítica, debe saberse quién puede detener la intervención y qué alternativa existe. El calendario técnico se coordina con los periodos de actividad del negocio para evitar que una fecha conveniente para TI coincida con un cierre o una operación importante.
13. Validar datos y funcionamiento
La validación combina informes de la herramienta, comprobaciones sobre el contenido y pruebas con usuarios. Los recuentos ayudan a localizar diferencias, pero deben interpretarse. Versiones, elementos excluidos, tipos de objeto y errores conocidos pueden explicar variaciones. La aceptación debe basarse en el alcance acordado y en evidencias revisables. Las pruebas funcionales incluyen abrir y editar documentos, consultar versiones, utilizar vistas y filtros, acceder con distintos perfiles y completar procesos relevantes. Deben registrarse las incidencias con la ubicación, la identidad utilizada, el resultado esperado y el observado. Un aviso como «SharePoint no funciona» es insuficiente para diagnosticar el problema.
El responsable de cada sitio debe confirmar la parte que conoce. El equipo técnico comprueba la ejecución y las configuraciones; el propietario valida que la información permite continuar la actividad. Ambas perspectivas son necesarias. Una aceptación distribuida por servicios o repositorios permite cerrar lo que está correcto y mantener visibles las excepciones pendientes.
14. Preparar contingencia y cierre
La contingencia debe describirse antes del cambio y adaptarse al método. No todos los movimientos admiten volver al estado anterior de la misma forma. El plan necesita identificar qué datos podrían modificarse en destino, cómo se tratarían esas modificaciones y qué decisiones requieren aprobación del cliente. Una copia conservada no equivale automáticamente a una reversión operativa.
El cierre incluye inventario final, correspondencia de ubicaciones, decisiones de acceso, incidencias aceptadas y procedimientos que se hayan modificado. También debe revisar las conexiones y los permisos temporales del proyecto. La retirada del origen se realiza después de la aceptación y de comprobar las dependencias que continúen activas. El soporte posterior debe tener un ámbito definido. Conviene diferenciar incidencias derivadas del traslado, administración habitual y cambios nuevos solicitados por los usuarios. Esa claridad facilita la atención y permite evaluar el resultado de la migración sin convertir cualquier mejora futura de la plataforma en una incidencia del proyecto.
15. Qué condiciona el presupuesto y el plazo
El tamaño total de los documentos es solo una variable. También influyen el número de elementos, las versiones, los permisos únicos, la diversidad de sitios y las integraciones. Dos repositorios con el mismo volumen pueden exigir esfuerzos muy distintos. Un presupuesto fiable debe explicar sus supuestos y qué información falta por confirmar.
Conviene separar preparación, licencias o herramientas, ejecución, validación y tareas de adaptación. Si se incluyen formularios, flujos o reorganización documental, deben figurar como trabajos identificables. De ese modo el cliente entiende qué compra y puede decidir sobre ampliaciones de alcance sin confundirlas con la copia básica de archivos. El calendario debe revisarse después del piloto y coordinarse con la disponibilidad de los propietarios para validar. La velocidad de transferencia no garantiza por sí sola una fecha de cierre. La resolución de excepciones y la aprobación de los procesos pueden determinar la duración efectiva del proyecto tanto como el volumen de datos.
16. Preparar la adopción y la administración posterior
La experiencia de los usuarios debe formar parte del plan. Aunque los documentos se encuentren en el destino, pueden cambiar las rutas de acceso, los favoritos, las ubicaciones de sincronización y la forma de solicitar permisos. Conviene preparar instrucciones breves centradas en esas tareas y distribuirlas antes del cambio. Una comunicación demasiado técnica puede resultar precisa para TI y poco útil para quienes necesitan continuar su trabajo.
Las instrucciones pueden organizarse en cuatro situaciones: localizar el nuevo sitio, abrir un documento habitual, colaborar con otra persona y comunicar una incidencia. Cada situación debe explicar la acción y el resultado esperado. Si una funcionalidad va a cambiar o estará temporalmente fuera de servicio, es preferible indicarlo con claridad y proporcionar una alternativa acordada. No debe prometerse que el cambio será imperceptible cuando habrá tareas que el usuario tenga que realizar.
Los propietarios de sitios necesitan una preparación adicional. Deben conocer el modelo de grupos, el procedimiento de altas y bajas y las normas de compartición aprobadas. También conviene confirmar quién revisará las solicitudes de acceso y quién podrá crear nuevos espacios. Si estas responsabilidades quedan sin asignar, las incidencias del primer mes pueden convertirse en excepciones permanentes que deterioren el modelo de permisos.
La administración posterior debe disponer de una relación de automatizaciones y conexiones adaptadas, con sus responsables operativos. Esa relación no tiene que incluir contraseñas ni secretos, sino la información suficiente para localizar la configuración y comprender sus dependencias. El equipo receptor debe poder distinguir una incidencia de contenido de un fallo de identidad, un problema de permisos o una aplicación que todavía utiliza el origen.
Finalmente, conviene acordar una revisión tras el periodo inicial de uso. Su objetivo es comprobar que los procesos previstos funcionan y que las excepciones aceptadas tienen seguimiento. Puede incluir la revisión de accesos, las incidencias repetidas y las necesidades de formación. Esa reunión no sustituye la aceptación técnica, pero ayuda a convertir el traslado de información en una transición que el equipo pueda mantener con autonomía.
Preguntas frecuentes sobre migraciones de SharePoint
¿Copiar los documentos basta para migrar un sitio de SharePoint?
Depende del alcance, pero normalmente hay que revisar más elementos: permisos, propietarios, metadatos, versiones y dependencias de uso. El propietario debe confirmar qué necesita conservar y qué puede adaptarse. Las pruebas del destino deben reproducir los recorridos importantes, porque disponer de los archivos no demuestra que el sitio permita continuar el trabajo.
¿Se mantienen los flujos y aplicaciones conectados al sitio?
No debe asumirse que el traslado de contenido reconstruye automáticamente esas integraciones. Se inventarían las conexiones y los responsables, y se comprueba su compatibilidad y configuración en destino. Cada dependencia necesita una decisión y una prueba, incluyendo los permisos y las cuentas que utiliza para acceder a la información.
¿Cómo se decide si conservar todas las versiones de los documentos?
El responsable de la información debe indicar qué historial necesita y por qué. Después se verifica qué admite el método y cómo afecta al volumen y al tiempo del proyecto. La prueba revisa documentos representativos en destino para comprobar que las versiones incluidas son accesibles y corresponden al alcance acordado.
¿Qué debe revisar un colaborador externo durante el piloto?
Debe poder acceder con la identidad prevista al contenido autorizado y realizar las acciones que necesita, sin acceder a información ajena. También se prueban los enlaces y los recorridos con los que llegará al sitio. Los cambios de acceso o de referencia se documentan y se comunican antes de ampliar la migración.