SharePoint tras una migración: probar permisos y enlaces por rol

Defina qué se debe conservar y qué debe cambiar

Antes de comparar origen y destino, acuerde el modelo de acceso aprobado. Una migración puede conservar el acceso existente o acompañar una reorganización. Si el negocio ha decidido retirar una excepción antigua, reproducirla perfectamente sería un fallo de diseño. El propietario debe confirmar quién puede leer, editar, compartir y administrar cada ámbito.

Documente también el método de migración. La función nativa entre tenants de SharePoint tiene requisitos de participación y licencias específicos: actualmente el programa y sus licencias de datos compartidos están disponibles para clientes Enterprise Agreement. No se debe presentar como una función incluida automáticamente en cualquier plan Microsoft 365. Tampoco permite pasadas incrementales o delta.

Para otros orígenes, revise el comportamiento de la herramienta utilizada. Los ajustes de permisos de Migration Manager para proyectos cloud distinguen permisos de carpetas y archivos. La transferencia de permisos de archivos debe habilitarse cuando corresponda; en una sincronización delta, su actualización depende de que se transfiera el archivo asociado. Esa condición no describe todos los métodos de migración.

Convierta el modelo de acceso en resultados observables

Empiece por una decisión del propietario: qué contenido es público dentro del equipo, qué biblioteca necesita un grupo reducido y qué colaboración externa sigue vigente. Para cada ámbito escriba operaciones, no sólo nombres de grupos. Leer, modificar, crear, compartir y administrar son acciones distintas. Una lista de miembros idéntica al origen no demuestra que el destino aplique el mismo resultado, especialmente cuando cambia la estructura de sitios o se consolidan carpetas.

Separe los permisos que se quieren conservar de las excepciones que deben retirarse. Añada una justificación a cualquier diferencia aprobada. La comparación debe utilizar ese diseño como referencia, no copiar indiscriminadamente el origen. Obtenga una versión fechada del modelo antes del ensayo para que un cambio de criterio durante las pruebas no convierta un fallo en éxito sin revisión. Si el proyecto incluye reorganización, trate cada permiso modificado como una decisión explícita.

Construya una muestra con riesgos distintos

No seleccione únicamente las bibliotecas más sencillas. Incluya un sitio de colaboración, uno de comunicación y los ámbitos con excepciones que existan en su proyecto. Añada documentos con acceso específico, una carpeta de trabajo compartida y un recurso reservado a un grupo concreto. Utilice datos de prueba apropiados; no necesita exponer contenido sensible para comprobar una denegación.

La documentación de permisos en la experiencia moderna de SharePoint explica la relación con grupos Microsoft 365 y Teams. Los sitios de canales privados o compartidos tienen su propia relación con el canal; no conviene tratarlos como bibliotecas corrientes del sitio principal.

La muestra debe reflejar el uso real. Un usuario que lee documentos en el navegador no representa necesariamente a quien edita desde una aplicación o llega mediante un enlace de Teams. Si esos recorridos son relevantes, conviértalos en casos separados y anote el cliente utilizado.

Seleccione profundidad según el riesgo

Prepare un inventario de sitios, bibliotecas, carpetas y documentos con acceso excepcional. Marque el responsable y la función de negocio. Elija una muestra que cubra ámbitos sensibles, invitados, permisos específicos y rutas utilizadas con frecuencia. Registre también lo que no se ensaya. Una muestra orientada al riesgo permite priorizar; no convierte un subconjunto en una garantía de acceso correcto para todos los elementos.

En sitios conectados con Teams, compruebe el tipo de canal antes de aplicar una corrección. Microsoft documenta que los permisos de sitios de canales privados y compartidos se gestionan en Teams. Distinga esos casos de un sitio de comunicación y de la biblioteca del equipo principal. La selección debe incluir identidades que pertenezcan al equipo pero no al canal cuando esa diferencia sea relevante al modelo aprobado.

Para cada recurso conserve un identificador de prueba y un destino inequívoco. Utilice una copia o contenido controlado para operaciones de escritura. Acuerde si se probarán descarga, sincronización o aplicación de escritorio; un ensayo sólo de navegador no acredita esos recorridos. Evite introducir contenido nuevo en un destino cuya herramienta de migración exija que no exista antes del movimiento.

Pruebe identidades reales del destino

Seleccione cuentas autorizadas para el ensayo: propietario, editor, lector, invitado y usuario sin acceso. Evite ejecutar toda la muestra con una cuenta privilegiada. Compruebe qué identidad está activa, especialmente cuando la misma persona conserva sesiones en los dos tenants o utiliza varios perfiles del navegador.

Las FAQ de migración nativa entre tenants vinculan la continuidad de permisos al mapeo de identidades. También describen la preparación de invitados y el comportamiento de redirección de enlaces. Un destino accesible requiere la autorización adecuada, aunque el enlace redirija correctamente.

El registro del ensayo puede utilizar identificadores internos o referencias controladas, evitando publicar nombres y direcciones personales. Conserve la evidencia en un repositorio accesible al equipo que debe resolver las incidencias, con la retención que establezca el proyecto.

Identidad, pertenencia y sesión

Compruebe que la cuenta de prueba pertenece al tenant de destino y que representa al perfil acordado. En el procedimiento nativo entre tenants, Microsoft requiere preparar y mapear identidades. Para un invitado, confirme además qué identidad externa participa y cuál es su objeto en el destino. No presuponga equivalencia por coincidir el nombre visible o por utilizar una dirección parecida.

Registre el grupo o mecanismo que debe otorgar acceso. Una cuenta puede recibirlo por más de una vía: grupo, permiso directo o enlace específico. Si retira una vía durante una prueba y la cuenta sigue entrando, investigue las otras antes de concluir que la revocación falló. Use sesiones de navegador separadas para los perfiles de prueba y confirme la identidad mostrada antes de cada operación.

Una cuenta administrativa sirve para inspeccionar configuración, pero no sustituye al lector o al invitado. Mantenga separados los pasos de diagnóstico y los ensayos de usuario. Si necesita una elevación administrativa para investigar, registre su finalidad y finalización; no mantenga un privilegio extra en la cuenta de ensayo porque distorsiona el resultado esperado.

Una matriz mínima de aceptación

La matriz es una propuesta de prueba, no una descripción universal de los permisos de su tenant. Registre la operación exacta y el resultado aprobado para cada caso. Si el propietario no sabe qué debe ocurrir, el caso está pendiente de definición; todavía no puede marcarse como superado.

Plantilla de evidencia que otro equipo pueda repetir

Añada al caso un identificador, sitio, recurso, identidad o referencia controlada, operación, resultado esperado y criterio de éxito. Después registre cliente, fecha, resultado observado, mensaje de error y enlace a la evidencia protegida. Una captura que muestra un archivo abierto no explica por sí sola qué cuenta lo abrió, si era el destino correcto o si la escritura estaba permitida.

Para el lector, pruebe lectura y edición por separado. Para el editor, compruebe que el cambio se guarda en el destino y puede verificarse después. En la prueba negativa utilice la misma ruta y recurso con una identidad excluida. No considere una petición de acceso equivalente a permiso concedido; registre la pantalla observada y confirme que el contenido no quedó expuesto.

Si el resultado depende de una configuración adicional, anótela. Una política de dispositivo o sesión puede influir en una descarga aun cuando la lectura esté permitida. El caso necesita explicar esa condición para que una segunda ejecución sea comparable. Marque un ensayo no realizado como pendiente, y un ensayo ambiguo como inconcluso; ninguno es un éxito por ausencia de una queja.

Separe el enlace del permiso

Pruebe el acceso directo al destino y el recorrido desde el enlace antiguo. Si uno funciona y el otro falla, tiene una pista sobre la ruta, no una conclusión automática sobre permisos. Registre la URL final, la cuenta utilizada y el mensaje observado. No difunda vínculos que otorguen acceso a contenido real en un informe público.

Revise también favoritos, enlaces insertados en páginas y referencias de procesos. Que una biblioteca migre no demuestra que una automatización o una página que la utiliza esté validada. El ensayo debe incluir esos componentes sólo cuando estén en el alcance, con un responsable que conozca su funcionamiento.

Pruebe tipos de enlace con expectativas distintas

La documentación de SharePoint distingue enlaces Anyone, People in your organization y Specific people. Los primeros pueden abrir sin autenticación; los de organización no funcionan para invitados; los específicos limitan el uso a las personas indicadas. El tipo elegido cambia la prueba. No use un vínculo de acceso anónimo para demostrar que la pertenencia a un grupo se ha conservado.

Registre si prueba un enlace antiguo, un enlace nuevo o la URL directa. En la migración nativa entre tenants, la redirección documentada no equivale a una autorización universal. Conserve el resultado de la ruta y el de la identidad en campos separados. Para otros productos, revise qué enlaces transfieren o reconstruyen; no extienda la promesa del método nativo a una herramienta diferente.

Revise referencias en páginas, Teams y documentación de procesos que estén dentro del alcance. Seleccione rutas reales con el propietario y evite una búsqueda indiscriminada que no pueda cerrarse. Un enlace que llega al archivo correcto pero ofrece edición cuando sólo se aprobó lectura también falla. La prueba debe comparar destino, identidad y capacidad, no únicamente ausencia de error.

Clasifique el fallo antes de ampliar acceso

Un error puede deberse a identidad, grupo, permiso directo, tipo de enlace, configuración de colaboración o una referencia que apunta al entorno anterior. Documente la causa confirmada y la corrección propuesta. Evite conceder acceso amplio para hacer desaparecer el síntoma: podría ocultar el problema y crear una exposición nueva.

Tras corregir, repita el caso positivo y el negativo relacionado. Una reparación sólo está cerrada cuando permite la operación necesaria y mantiene la restricción aprobada. Anote qué muestra se ha repetido y qué queda fuera de ella.

Ejemplo: el invitado abre el destino, pero falla desde el enlace antiguo

Imagine un sitio de proyecto con un invitado autorizado a leer una carpeta. La URL nueva permite la lectura y deniega la edición. El vínculo antiguo enviado en una conversación conduce a otra ubicación o muestra un error. Es un caso hipotético: primero conserve ambos resultados y confirme que se utilizó la misma identidad. El ensayo apunta a una diferencia de ruta; todavía no demuestra la causa.

Revise el tipo de vínculo, la referencia de origen y el comportamiento previsto de la herramienta. Si la corrección consiste en sustituir una referencia, obtenga aprobación del propietario y actualice sólo los elementos afectados. No añada al invitado como miembro de todo el sitio para hacer funcionar un enlace aislado. Repita la apertura desde la conversación y la prueba negativa de edición tras corregir.

Si el acceso directo también falla, cambie la hipótesis y revise identidad, pertenencia, permiso y restricciones de colaboración. Mantenga una incidencia por causa confirmada, con los casos afectados relacionados. Cuando modifique una configuración compartida por varios sitios o perfiles, amplíe la regresión a una muestra de esos ámbitos antes de cerrar el cambio.

Cierre con excepciones visibles

El acta debe identificar sitios y roles ensayados, casos aprobados, fallos abiertos, propietario de cada excepción y condición de aceptación. No declare validado todo SharePoint a partir de una muestra pequeña sin explicar su alcance.

El propietario del sitio debe revisar ese registro con el equipo de migración. Por ejemplo, un caso de invitado pendiente podría aceptarse temporalmente si existe una alternativa aprobada y un responsable. Es una excepción documentada, no una prueba superada. Un fallo que afecte a un proceso esencial podría impedir la aceptación. La decisión debe seguir los criterios acordados.

La guía de MSAdvance sobre qué se puede migrar desde Google Workspace ayuda a separar los componentes del proyecto. Para preparar una validación de permisos y enlaces, consulte el servicio de migración Microsoft 365 de MSAdvance y describa el origen, los sitios y los perfiles que deben probarse.

Aceptación, excepción y transferencia a operación

Clasifique los resultados como superado, fallido, pendiente o inconcluso. Defina qué fallos bloquean la aceptación y quién puede aprobar una excepción. Un acceso indebido a contenido restringido necesita tratamiento específico; una referencia informativa rota puede tener otra prioridad. La clasificación debe depender del impacto acordado y la evidencia, sin diluir todos los hallazgos en una lista de tareas menores.

Para una excepción incluya responsable, alternativa, vencimiento y condición de cierre. Entregue a operación el modelo aprobado, el inventario de casos, las correcciones y las incidencias que siguen abiertas. Indique dónde consultar evidencia y quién mantiene grupos, sitios y enlaces. El objetivo es que el siguiente cambio de miembros pueda gestionarse con el modelo de destino y no con una configuración de origen ya retirada.

Una validación especializada resulta útil cuando hay muchas identidades externas, permisos excepcionales o varias herramientas con comportamientos diferentes. El alcance debe especificar sitios, perfiles, recorridos y entregables antes de comenzar. Pida un registro de resultados y decisiones que permita repetir los casos; un informe que sólo confirma que terminó la copia deja sin resolver la aceptación del acceso.

Documentación oficial y alcance

• Microsoft: Modern SharePoint sharing and permissions
• Microsoft: Native cross-tenant migration
• Microsoft: Cross-tenant migration FAQ
• Microsoft: Migration Manager permissions
• Microsoft: Migration Manager delta sync

La matriz, los criterios de cierre y el ejemplo son propuestas de MSAdvance. Adapte la muestra al modelo aprobado y compruebe la documentación del método utilizado.