Una migración puede modificar millones de registros, alimentar procesos activos y generar efectos fuera de la base de datos. Si una transformación falla a mitad de camino, restaurar una copia completa no siempre es seguro ni aceptable: quizá se hayan escrito datos nuevos después de la copia, o el sistema no pueda detenerse durante el tiempo que exige la restauración.
Por eso, un plan de reversión para migraciones de datos no debe reducirse a un comando para volver atrás. Debe establecer cómo identificar el estado afectado, qué operaciones pueden deshacerse, cuáles requieren una compensación y cuándo conviene reparar o reanudar. La decisión se prepara antes de ejecutar la migración, con criterios que el equipo pueda comprobar bajo presión.
Por qué restaurar una copia no siempre es una reversión viable
Una copia de seguridad sirve para recuperar datos ante determinados incidentes, pero restaurarla puede eliminar cambios legítimos posteriores a su creación. También puede implicar indisponibilidad, reconstrucción de índices o pérdida de escrituras que llegaron a otros sistemas. Si hay replicación, colas, exportaciones o integraciones, recuperar una base de datos no revierte automáticamente esos efectos.
Conviene distinguir tres acciones. Restaurar recupera una copia o un punto temporal; revertir intenta deshacer los cambios de la migración; compensar aplica nuevas operaciones que corrigen sus efectos. No son equivalentes: una compensación puede dejar un historial diferente del original, aunque restablezca las reglas de negocio.
La elección depende del alcance del fallo, de las escrituras posteriores y de los objetivos de recuperación. Antes de empezar, determine qué pérdida de datos es tolerable, cuánto tiempo puede durar la interrupción y quién autoriza una recuperación. Si esos límites no están definidos, el equipo no tiene un criterio operativo para decidir.
Clasificar cada transformación por su posibilidad de recuperación
Describa cada paso de la migración y clasifíquelo según el modo de recuperación previsto:
- Reversible: existe una operación inversa fiable. Por ejemplo, se conserva el valor original antes de normalizar un campo y se puede restaurar sin sobrescribir cambios posteriores.
- Compensable: no es posible reconstruir exactamente el estado anterior, pero una operación nueva puede corregir el efecto según una regla de negocio. La compensación debe ser explícita, auditable e idempotente cuando sea posible.
- Irreversible: se descarta información o se produce un efecto que no puede deshacerse con garantías. Requiere una decisión expresa sobre aceptación del riesgo, conservación de datos de origen y validaciones adicionales.
La etiqueta no debe asignarse solo por el tipo de sentencia SQL. Una actualización masiva puede ser reversible si se guarda el valor previo y se controla la concurrencia; puede no serlo si durante la ejecución otros procesos modifican las mismas filas. Considere también efectos secundarios como notificaciones, llamadas a APIs, cobros o mensajes en colas. A menudo es preferible separar esas acciones de la transformación de datos.
Fijar el estado inicial y las invariantes
Antes de ejecutar, registre el alcance de la migración: entidades incluidas, filtros, versión de la aplicación y reglas aplicadas. Defina una línea base con recuentos relevantes y, cuando aporte valor, agregados o huellas de conjuntos estables. Registre el momento de referencia y la fuente de esos datos. Una cifra sin alcance ni contexto no permite verificar una recuperación.
Las invariantes son condiciones que deben seguir siendo ciertas tanto durante como después de la migración. Pueden incluir relaciones entre tablas, unicidad, estados permitidos, importes que deben conservarse o correspondencia entre registros de la base de datos y sistemas conectados. Añada a cada una una consulta o procedimiento reproducible y un umbral de aceptación. Si el dato cambia legítimamente durante la ejecución, defina cómo distinguir esa actividad del efecto de la migración.
En una aplicación PHP, las transformaciones pueden implementarse en comandos de consola o procesos de trabajo, en vez de depender de una petición web extensa. La elección no elimina los riesgos de concurrencia ni los límites transaccionales: determine qué unidad puede ejecutarse atómicamente y qué hacer si el proceso termina entre dos operaciones.
Diseñar lotes, puntos de control y ejecución reanudable
Divida el trabajo en lotes con límites explícitos, por ejemplo mediante una clave estable y ordenada. Evite paginar por desplazamiento si las filas pueden cambiar o desaparecer durante el proceso; una marca de continuación basada en una clave suele ser más predecible. El tamaño del lote debe equilibrar duración de transacciones, carga sobre la base de datos y facilidad para detectar fallos.
Después de cada lote, guarde un punto de control con el identificador del trabajo, el rango procesado, el estado, la hora y los resultados de validación. Actualizar los datos y avanzar el punto de control deben coordinarse para evitar declarar procesado un lote que no se confirmó. Si ambas operaciones no pueden formar una transacción, diseñe una reconciliación que detecte el caso intermedio.
Una migración reanudable no vuelve a aplicar cambios de forma ciega. Cada operación debe tolerar reintentos o comprobar si el efecto ya existe. En PHP, eso puede apoyarse en transacciones, restricciones únicas y operaciones idempotentes, según el motor y el modelo de datos. Pruebe también interrupciones deliberadas: un despliegue, una excepción o una pérdida de conexión no deberían dejar el trabajo sin una forma conocida de continuar.
Registrar los cambios para localizar efectos y auditar decisiones
Asigne un identificador único a cada ejecución y registre, como mínimo, la transformación, el alcance, los lotes, las filas afectadas, los errores y las decisiones de recuperación. Para cambios que puedan compensarse, conserve los datos previos necesarios o una referencia segura a ellos. No registre indiscriminadamente información sensible en logs; limite el acceso, el plazo de conservación y el contenido a lo que sea necesario para recuperar y auditar.
El registro debe permitir responder preguntas concretas: qué filas se intentaron procesar, cuáles se confirmaron, cuáles fallaron y qué operación posterior las modificó. Combine logs técnicos con un historial de cambios de negocio cuando sea necesario. No confunda la trazabilidad con una copia de seguridad: el registro debe tener suficiente detalle para su propósito y también necesita protección frente a pérdida o alteración.
Elegir entre reanudar, compensar o restaurar
Defina de antemano señales y respuestas, en lugar de decidir únicamente por intuición cuando aparezca un error:
- Reanudar: si el fallo es transitorio, las invariantes se mantienen y los lotes confirmados están identificados. Reintente de forma limitada y observe errores y carga.
- Compensar: si los cambios aplicados se conocen y existe una operación correctiva probada. Detenga primero nuevas escrituras incompatibles y confirme que la compensación no sobrescribirá modificaciones válidas.
- Restaurar: si la corrupción es amplia, la recuperación desde copia está validada y el impacto de perder o reconstruir cambios posteriores es aceptable. Coordine la recuperación con réplicas e integraciones.
- Detener y escalar: si el estado no se puede determinar, los recuentos divergen sin explicación o la compensación puede causar más daño. Preserve evidencias antes de intervenir.
Establezca umbrales para pausar el trabajo, como una tasa de errores superior a la permitida, una invariante incumplida o una desviación de recuentos. Defina quién puede autorizar la reanudación y quién decide una restauración. En ocasiones, la opción más segura es aislar el flujo afectado y mantener el sistema en un estado controlado mientras se investiga.
Validar y cerrar la migración con una lista de comprobación
La finalización del proceso no demuestra que los datos sean correctos. Compare recuentos antes y después con el alcance esperado, ejecute reglas de negocio y revise relaciones y valores extremos. Use muestreos para inspeccionar casos concretos, pero no como sustituto de verificaciones completas cuando sea posible realizar estas últimas. Si existen consumidores externos, compruebe también sus estados y acuerde cómo reconciliar diferencias.
Antes de ejecutar: clasifique transformaciones, confirme copia y recuperación, pruebe lotes y reintentos con datos representativos, defina invariantes, límites de parada, responsables y ventana operativa. Asegure que el equipo puede consultar el registro de cambios y que los procedimientos de compensación o restauración están probados.
Después de ejecutar: valide recuentos y reglas, revise errores y efectos externos, conserve el registro de la ejecución y documente cualquier excepción. Mantenga disponible la información de recuperación durante el periodo acordado y retírela de forma segura cuando deje de ser necesaria. La migración solo está cerrada cuando los resultados son verificables y existe una decisión explícita sobre las desviaciones pendientes.
