Una migración debe detenerse cuando no puede garantizarse la continuidad de las funciones críticas o falta un procedimiento viable de recuperación. Los criterios de parada se definen antes de lanzar. Si se improvisan durante una incidencia, la presión por publicar puede convertir un problema detectable en una pérdida de servicio.

Decide qué no puede fallar

Una web corporativa y una tienda tienen riesgos distintos. Identifica las tareas que el negocio necesita mantener: recibir consultas, consultar fichas, comprar o acceder a documentación. Después traduce cada tarea a una prueba.

«La web funciona» es demasiado amplio. «Un mensaje de prueba llega al buzón acordado y el usuario ve confirmación» permite aceptar o detener una entrega con evidencia.

Escribe un registro de condiciones de parada

Para cada riesgo, documenta condición, prueba, responsable y acción. Algunas condiciones pertinentes pueden ser:

  • No hay copia comprobada ni procedimiento de reversión.
  • El formulario falla o la entrega no se ha verificado.
  • Faltan destinos para URLs comerciales relevantes.
  • Una restricción de pruebas permanece en producción.
  • Los pagos, el stock o una integración crítica no funcionan.

No todas las incidencias justifican detener todo el proyecto. Un enlace secundario puede tener una corrección programada. Una función crítica requiere una decisión explícita sobre su impacto.

Acuerda quién tiene autoridad para parar

Ejemplo hipotético: marketing aprueba el diseño, pero operaciones descubre que el catálogo muestra documentos antiguos. Si nadie ha definido quién decide, el equipo puede publicar porque el calendario lo exige.

El plan debe identificar una persona responsable de la autorización final y especialistas que aportan evidencias. La aprobación visual no reemplaza la validación funcional. Tampoco un build correcto demuestra entrega de correo o sincronización de datos.

Prepara una reversión que pueda ejecutarse

Documenta qué se restaura, cómo se recuperan configuraciones y qué ocurre con mensajes o pedidos generados durante el cambio. Volver a una copia antigua puede perder datos nuevos si no hay un procedimiento específico.

Ensaya en un entorno separado cuando sea posible. Registra dependencias de dominio, hosting y terceros. No consideres disponible una reversión que exige accesos que nadie tiene.

Antes del lanzamiento, reúne resultados y pendientes. Cualquier excepción debe explicar riesgo, responsable y corrección. La ausencia de evidencia es un pendiente, no una prueba favorable.

Clasifica incidencias antes del día de cambio

Define tres tratamientos: detener, corregir antes de la apertura o aceptar temporalmente con responsable. El último solo tiene sentido si el efecto es conocido y la corrección está acordada.

Un fallo de contacto, una restricción de indexación o un pago incorrecto requieren analizar continuidad. Una diferencia visual secundaria puede tener otra prioridad. No utilices la misma etiqueta para ambos.

Reúne el registro en la autorización final. Debe mostrar evidencia, pendientes y decisión, sin interpretar el silencio del equipo como aceptación. Si cambian las condiciones después de aprobar, vuelve a revisar el criterio afectado antes de lanzar.

El calendario necesita criterios de aceptación

Parar a tiempo permite resolver un bloqueo con alcance claro. Un rediseño sin perder SEO debería incluir decisiones de continuidad, además de imágenes y nuevas páginas. Define esas decisiones antes de anunciar la fecha pública.