Cómo aceptar una migración Microsoft 365 con evidencias

Empiece por definir qué se está aceptando

Separe tres hitos: finalización de la transferencia, validación técnica y autorización para pasar a operación. Una oleada puede haber terminado de copiar y seguir pendiente de una delegación de calendario. También puede aceptarse con una incidencia menor documentada, si el propietario del servicio lo autoriza y existe una solución acordada.

Prepare una fila por población o servicio: buzones, archivos personales, bibliotecas compartidas y colaboración. Identifique origen y destino, usuarios incluidos, exclusiones, momento de corte y evidencia esperada. Si los criterios cambian después de ejecutar, registre el cambio; no reinterprete silenciosamente el alcance para que coincida con el resultado.

La guía de qué se puede migrar entre tenants ayuda a delimitar workloads. El acta debe recoger las condiciones de su proyecto concreto, incluidas las funciones que se recrean en lugar de transferirse.

Un criterio verificable necesita contexto

«El correo funciona» no permite repetir una prueba. Un criterio útil identifica población, operación, resultado esperado y condición de cierre. Por ejemplo: una cuenta del departamento financiero envía desde un buzón compartido a una cuenta externa controlada, el mensaje llega con el remitente previsto y la copia aparece donde se ha acordado. Esta formulación permite asignar una persona responsable y comprobar exactamente el comportamiento.

Defina también quién puede aceptar el resultado. El administrador acredita una configuración, el propietario del proceso confirma que sirve para trabajar y el responsable del proyecto registra la decisión. Una firma del proveedor no sustituye la validación del cliente. Para oleadas, conserve una versión del acta por lote y un resumen general que muestre dependencias todavía abiertas.

Una matriz de pruebas que permite decidir

Esta matriz es una recomendación de gestión de MSAdvance, no un requisito universal de Microsoft. Adapte los casos a su criticidad. Un departamento con documentación regulada necesita una muestra distinta de un equipo con archivos temporales; las pruebas deben reflejar procesos reales.

Cómo elegir una muestra defendible

No seleccione únicamente a los usuarios que tienen más disponibilidad. Agrupe la población por características que pueden cambiar el resultado: plataforma de origen, tamaño, delegaciones, acceso externo, restricciones de seguridad y clientes utilizados. Incluya casos conocidos como difíciles y al menos un proceso relevante de cada grupo. Registre el tamaño de la población y el número de casos revisados.

El muestreo funcional y la reconciliación completa de informes cumplen funciones diferentes. Puede revisar el estado de todos los objetos inventariados y probar manualmente una muestra de experiencias. Si descubre un patrón de fallo, amplíe la comprobación a la población afectada. Evite declarar un porcentaje de éxito global mezclando usuarios, archivos y pruebas: esas unidades no son equivalentes.

Reconciliar datos sin exigir una igualdad engañosa

Conserve el inventario previo al corte y compárelo con los informes del mismo ámbito. No mezcle archivos escaneados con archivos elegibles, ni elementos filtrados con fallos. En migraciones de recursos compartidos, Migration Manager distingue esos conceptos en sus informes. Identifique también la fecha de generación y guarde los informes necesarios antes de que dejen de estar disponibles.

Una diferencia de totales exige explicación, pero no demuestra por sí sola pérdida. Puede responder a exclusiones aprobadas, versiones fuera del alcance o transformaciones del método. Clasifique cada diferencia como esperada, pendiente de investigar o defecto confirmado. La explicación debe poder comprobarse en un informe o en una prueba, no quedar únicamente en una conversación.

La muestra funcional complementa los totales: elija documentos grandes, nombres especiales, carpetas profundas y permisos particulares según el inventario. Compruebe apertura y edición desde los clientes utilizados por el negocio. No presente una muestra como verificación del cien por cien; registre su cobertura y lo que sigue sin comprobarse.

Construya un registro de diferencias

Para cada tarea, guarde identificador, ubicación origen, destino, ejecución, filtros y momento del último cambio. Compare el inventario con la última ejecución que corresponda al corte. Un informe de la precarga no acredita las modificaciones posteriores. Si hay sincronizaciones incrementales, documente cuál fue la última y qué cambios pudo procesar el método.

Imagine, como ejemplo hipotético, una biblioteca con 10.000 archivos inventariados, 9.950 elegibles, 9.930 transferidos y 20 errores. Los 50 excluidos necesitan una justificación de alcance y los 20 fallidos una investigación. La cifra de 9.930 no debe presentarse como cobertura completa. Tampoco basta con sumar ejecuciones: un mismo archivo puede aparecer en varios informes y duplicar el total aparente.

Correo y calendarios: probar la jornada de trabajo

Pruebe las rutas de correo relevantes con cuentas controladas y contenido de prueba. Registre remitente, destinatario, hora y resultado. Añada calendarios, buzones compartidos y delegación cuando estén incluidos. Evite recopilar mensajes reales confidenciales para demostrar una prueba que puede hacerse con datos sintéticos.

La migración nativa de buzones entre tenants tiene condiciones específicas: requiere el complemento de licencia de migración correspondiente, además de las suscripciones adecuadas. Los permisos de buzón y calendario entre tenants no están soportados; la planificación de usuarios relacionados importa. Un movimiento de buzón tampoco acredita que todas las funciones de Teams estén listas en el destino.

Por eso, incluya como casos separados «puede iniciar sesión», «puede enviar correo» y «puede gestionar la agenda delegada». Una prueba de conectividad realizada antes del movimiento es útil para preparar el proyecto, pero no demuestra la experiencia posterior del usuario.

Separe las comprobaciones del servicio y del cliente

Si una prueba falla en Outlook, repítala en Outlook en la web para acotar el problema. Un fallo exclusivo del equipo puede deberse a la sesión, perfil o configuración local. Un fallo también reproducible en la web requiere investigar identidad, permisos y servicio. Registre ambas observaciones antes de rehacer perfiles o repetir una migración.

Pruebe por separado Full Access, Send As y Send on Behalf cuando formen parte del alcance. Poder abrir un buzón no demuestra que se pueda enviar con la identidad requerida. En calendarios, compruebe visualización, creación y modificación según la delegación pactada. Si hay dispositivos móviles, pruebe su configuración destino y deje constancia de cuáles se han incluido. No extienda el resultado de un equipo Windows a todas las plataformas.

OneDrive y SharePoint: acceso, enlaces y clientes

Compruebe identidad y permisos en el navegador antes de atribuir un fallo al cliente de sincronización. Después pruebe los dispositivos que estén en alcance. En la fase posterior a la migración nativa de OneDrive, Microsoft indica el inicio de sesión con la nueva identidad y la resincronización del cliente. Incluya esos pasos en la comunicación al usuario.

No dé por válidos todos los enlaces por comprobar uno. Seleccione enlaces usados en procesos reales y perfiles distintos. La migración nativa entre tenants de OneDrive utiliza redirecciones y mapeo de identidades, con condiciones de acceso y limitaciones propias; no es una copia incremental genérica. No extrapole ese comportamiento a cualquier herramienta o migración de SharePoint.

La prueba negativa es especialmente útil: una identidad que no debería acceder debe recibir la denegación prevista. Un archivo disponible para todos puede parecer una migración exitosa y esconder un error de permisos. Documente el resultado sin incluir secretos ni enlaces de acceso sensible en un acta distribuida ampliamente.

Una prueba de archivo debe incluir su uso

Seleccione un documento y compruebe su ubicación, apertura y, para un editor autorizado, modificación y guardado. Añada versiones o metadatos si están contratados. Después repita el acceso con una identidad de lectura y otra excluida. Así diferencia integridad, capacidad de uso y confidencialidad. Documente las identidades por rol, sin distribuir información personal innecesaria.

Distinga URL del sitio, enlace directo al archivo y enlace de uso compartido. Que uno redirija no implica que los otros se comporten igual. Pruebe accesos desde favoritos, Teams y procesos automatizados cuando estén en alcance. Antes de retirar el origen, identifique qué dependencias siguen utilizando sus direcciones. La retirada de una redirección puede cambiar un resultado que antes parecía correcto.

Ejemplo de excepción que no debe desaparecer del cierre

Suponga una oleada donde un equipo puede abrir sus documentos, pero falla un enlace usado en el proceso de compras. No escriba «archivos correctos» y cierre el proyecto. Registre el enlace o identificador en un repositorio restringido, su proceso afectado, el método de reproducción, el responsable y la decisión: corregir antes de aceptar o aceptar con una alternativa aprobada.

El ejemplo es hipotético y no representa un caso de cliente. Su utilidad está en distinguir la integridad del archivo de la continuidad del proceso. El acta debe decir qué funciona y qué riesgo permanece, con suficiente detalle para que soporte pueda actuar.

Registre impacto y condición de resolución

Una excepción necesita más que una prioridad. Añada usuarios afectados, proceso, frecuencia, alternativa disponible, riesgo de acceso y evidencia que permitirá cerrarla. «Pendiente de revisar» no asigna trabajo. «El propietario de compras validará el enlace sustituto antes de la siguiente revisión» describe una responsabilidad y una comprobación concreta.

Cuando una incidencia se corrige, repita la prueba original y compruebe que no se ha ampliado el acceso para resolverla. Conserve el resultado anterior junto al nuevo para mostrar la evolución. Una aceptación condicionada debe indicar qué condiciones permanecen y quién ha aceptado su impacto. No convierta una excepción conocida en una exclusión nueva sin una decisión expresa sobre el alcance.

Cuándo aceptar, aceptar con condiciones o detener

• Aceptar: criterios cumplidos, evidencias disponibles y operación preparada.
• Aceptar con condiciones: excepciones conocidas y autorizadas, impacto delimitado, responsable y próxima revisión.
• Detener el cierre: pérdida sin explicar, acceso indebido, procesos críticos bloqueados o evidencia insuficiente.

Las decisiones de conservación, obligaciones legales y retirada del origen requieren sus responsables correspondientes. No elimine un entorno, una retención o una cuenta únicamente para hacer desaparecer una incidencia de migración. El plan de recuperación depende del método utilizado y debe haberse acordado antes del cambio.

La criticidad decide el cierre

Acuerde antes del cutover qué resultados bloquean la aceptación. Un proceso esencial detenido o un acceso indebido requieren una decisión distinta de una incidencia de presentación con alternativa validada. La clasificación debe atender al impacto empresarial y de seguridad, además del número de personas afectadas. Una única cuenta puede sostener un proceso crítico.

Si falta evidencia, identifique qué prueba permite obtenerla y quién la realizará. No trate lo no comprobado como aprobado. La aceptación del destino, la resolución de incidencias y la retirada del origen son decisiones relacionadas pero separadas. El plan debe conservar opciones de recuperación compatibles con el método elegido y con las obligaciones de conservación de la organización.

Qué entregar al equipo que operará el destino

Entregue alcance aceptado, pruebas y fechas, excepciones abiertas, responsables, configuración relevante y canales de soporte. Separe el repositorio técnico restringido del resumen para dirección. No guarde credenciales en el acta. Establezca quién revisará las excepciones y qué evidencia permitirá cerrarlas.

Modelo práctico de acta de aceptación

El acta puede ser breve si enlaza a evidencias suficientes. Incluya identificación del proyecto y lote, versión del alcance, momento de corte, criterios, resultados, excepciones, responsables y decisión. Añada fecha de revisión para condiciones abiertas y una relación de tareas que pasan a operación. Indique qué queda fuera de la cobertura del acta para evitar interpretaciones posteriores.

• Inventario y último informe asociados al mismo ámbito y corte.
• Pruebas de acceso y procesos críticos con resultado y responsable.
• Excepciones autorizadas y tareas de resolución identificadas.
• Soporte informado y documentación técnica accesible.
• Decisión del cliente registrada sin incluir credenciales.

Fuentes oficiales y ámbito

• Microsoft: Cross-tenant mailbox migration — licenciamiento, preparación del destino y condiciones de delegación.
• Migration Manager: File share reports — elementos escaneados, elegibles y migrados.
• Migration Manager: Cloud reports — informes específicos para orígenes cloud.
• Microsoft: OneDrive post-migration — identidad, sincronización y enlaces compartidos.

El marco de aceptación, el muestreo y el modelo de acta son recomendaciones de MSAdvance. No constituyen un estándar universal de aceptación de Microsoft.