Una migración que se interrumpe no siempre está simplemente «a medias». Puede haberse detenido antes de guardar una unidad, después de confirmar algunos cambios o cuando el destino respondió de forma ambigua. También puede haber terminado su proceso y, aun así, haber dejado discrepancias. Para decidir cómo continuar, el equipo debe reconstruir qué ocurrió con evidencias verificables, no confiar únicamente en el código de salida o en el último identificador registrado.
La pregunta práctica no es solo cómo reanudar una migración de datos fallida en PHP, sino qué puede afirmarse sobre el estado de cada unidad y qué comprobaciones hacen falta antes de repetir una operación. Esa distinción reduce el riesgo de duplicados, relaciones rotas y correcciones manuales difíciles de auditar.
Primero, distingue una ejecución detenida de una migración discrepante
Una ejecución detenida es aquella cuyo proceso dejó de avanzar: por ejemplo, por una excepción, una pérdida de conexión o una intervención operativa. Una migración discrepante, en cambio, es aquella cuyo resultado no satisface las condiciones esperadas, aunque el proceso haya finalizado sin errores. Puede haber filas omitidas, claves transformadas de forma incorrecta o relaciones incompletas.
Por eso, un estado global como completada o fallida es insuficiente. Conviene diferenciar al menos entre ejecución en curso, detenida, completada y completada con discrepancias. El estado global resume el trabajo, pero no sustituye el registro por unidad ni la validación del resultado.
Antes de relanzar el comando, conserva los registros disponibles y determina qué sistema es la fuente de verdad en esta fase. Si hay escrituras posteriores a la migración, cambios manuales o procesos concurrentes, identifica cómo afectan a la comparación. Continuar sin esa información puede convertir una discrepancia investigable en una pérdida de trazabilidad.
Define unidades de trabajo y puntos de control verificables
Elige una unidad de trabajo que tenga sentido para los datos y para la recuperación: puede ser una entidad, un grupo de registros relacionado o una partición estable. Evita que el punto de control sea simplemente «el último ID procesado». Ese ID demuestra, como mucho, que el programa llegó a cierta posición; no prueba que todos los registros anteriores se guardaran correctamente ni que el destino sea coherente.
Para cada unidad, conserva una clave de origen estable, la versión o identificador de la ejecución, el estado y un resultado comprobable. El punto de control debe poder contrastarse con el destino: por ejemplo, mediante una clave de destino, una huella calculada sobre campos relevantes o una consulta de verificación. Si los datos pueden cambiar durante el proceso, registra también el criterio de selección o el instante de corte aplicado.
El diseño depende del entorno. Si origen y destino comparten una transacción, esta puede aportar evidencia de confirmación conjunta; si son sistemas distintos, no supongas atomicidad entre ambos. En una integración mediante API, una respuesta perdida puede dejar incierto si el servidor aplicó la operación. La estrategia debe reflejar esa incertidumbre y ofrecer una comprobación posterior, no etiquetar automáticamente la unidad como fallida o confirmada.
Registra por unidad qué se intentó y qué se confirmó
Un registro útil para soporte permite responder quién ejecutó la migración, qué unidad trató, cuándo cambió su estado y con qué evidencia. Distingue entre procesado —el código realizó pasos— y confirmado —hay una señal fiable de que el resultado esperado existe en el destino—. Añade el número de intento, una categoría de error y un identificador de correlación para enlazar eventos del proceso con llamadas externas.
Los estados deben describir situaciones operativas, no solo etapas del algoritmo. Por ejemplo: pendiente, en curso, confirmación incierta, confirmado y requiere revisión. Si el proceso muere mientras una unidad figura como en curso, al reiniciar debe tratarse como incierta hasta verificar el destino. No la marques como fallida sin comprobar si llegó a producir efectos.
Registra información suficiente para investigar, pero no vuelques credenciales, secretos ni datos personales innecesarios en logs. Los errores deben permitir identificar la unidad y la operación, sin hacer que la trazabilidad amplíe la exposición de datos. Define también quién puede consultar y conservar esos registros.
Compara invariantes antes de decidir cómo continuar
Las invariantes son condiciones que deben cumplirse independientemente de cómo se implemente la migración. Los recuentos por tipo o partición ayudan a localizar diferencias, pero no bastan: dos conjuntos pueden tener el mismo tamaño y contener registros distintos. Compara claves de negocio, presencia de registros, relaciones y reglas relevantes, como estados permitidos o importes recalculados.
Elige comprobaciones proporcionales al impacto y al volumen. Una muestra puede servir como diagnóstico, pero no demuestra por sí sola que el conjunto completo sea correcto. Para una validación exhaustiva, compara claves o huellas por bloques y registra cuáles se revisaron. Si la transformación cambia campos deliberadamente, documenta qué diferencias son esperadas y cuáles indican un error.
Si el origen sigue recibiendo cambios, separa las discrepancias debidas a la concurrencia de las causadas por la migración. Puede ser necesario fijar una ventana de corte, capturar cambios posteriores o repetir una fase de sincronización. Sin una regla clara para los cambios concurrentes, la comparación entre sistemas puede generar falsos positivos o pasar por alto datos nuevos.
Reanuda solo con evidencia y trata los resultados inciertos
Una reanudación segura carga las unidades pendientes y las confirmadas, pero no da por válidas las que quedaron en estado incierto. Para estas últimas, consulta el destino con una clave estable y compara el resultado con la transformación esperada. Si coincide, registra la confirmación sin repetir el efecto; si no existe, puede ser apropiado volver a intentarlo. Si existe con contenido distinto, detén esa unidad para investigar.
Cuando repetir una operación pueda crear duplicados o efectos externos —como enviar una notificación—, utiliza una operación idempotente o una clave de idempotencia si el sistema implicado la admite. Si no es posible, diseña una comprobación previa y una ruta de reconciliación. No presupongas que una excepción significa que nada se escribió: el fallo pudo producirse después de confirmar el cambio y antes de recibir la respuesta.
Antes de reanudar, valida que se ejecuta el mismo mapeo, la misma política de claves y la versión correcta del código o configuración. Un punto de control generado por una transformación distinta puede ser engañoso. En PHP, el comando de migración debería aceptar una ejecución identificable y emitir estados estructurados; así, una persona puede contrastar el registro con los datos en lugar de depender de mensajes genéricos en consola.
Establece condiciones de parada y cierra con un informe
Detén la continuación cuando haya conflictos de claves, datos inválidos que requieran una regla de negocio, relaciones huérfanas, resultados inciertos que no puedan verificarse o diferencias que superen los límites aceptados. También para si la evidencia disponible no permite saber qué ocurrió. En esos casos, escalar y preservar el estado suele ser más seguro que reintentar a ciegas.
Al finalizar, ejecuta las comprobaciones globales: unidades confirmadas frente a unidades esperadas, recuentos y claves, relaciones y reglas de negocio definidas para la migración. Genera un informe que indique qué se migró, qué se verificó, qué se reintentó y qué discrepancias siguen pendientes, con referencias que permitan investigarlas. No declares el trabajo cerrado solo porque el proceso terminó con código cero.
El criterio para reanudar es sencillo de expresar, aunque requiera disciplina técnica: cada unidad debe quedar confirmada, verificada como no aplicada, o apartada para revisión. Ese estado explícito, junto con invariantes comparables y registros útiles, permite continuar una migración PHP sin confundir avance con éxito ni incertidumbre con autorización para repetir.
