Tener una copia no demuestra que el proceso pueda continuar
Una aplicación necesita datos, programas y configuración compatibles entre sí. Si se recupera una parte sin conocer el estado de las demás, puede resultar difícil determinar qué operaciones habían terminado. La consultoría examina esa relación antes de proponer un procedimiento.
Para un proyecto en Zamora identificamos los puntos en los que el proceso deja un estado comprobable. Distinguimos una copia disponible de una recuperación ensayada. No afirmamos que el sistema sea recuperable hasta conocer qué se ha probado realmente.
Entender qué ocurrió antes del corte
El diagnóstico revisa registros de ejecución, archivos de salida y marcas de procesamiento. Debe permitir decidir si una operación no empezó, quedó incompleta o terminó sin que se recibiera su confirmación. Esas situaciones no se resuelven siempre repitiendo el mismo programa.
Cuando faltan señales, podemos proponer mejoras en COBOL para registrar avance y resultados. Se revisa que esas marcas se actualicen de forma coherente con los datos del negocio, evitando que indiquen éxito antes de completar el trabajo.
Migrar sin empeorar la recuperación
Al trasladar funciones a .NET se define cómo se preserva el estado y quién controla los reintentos. Separar un proceso en varios componentes puede cambiar la forma de fallar. La arquitectura de destino debe explicar qué ocurre cuando uno termina y otro no está disponible.
La prueba compara también las condiciones de interrupción, no solo la ejecución normal. Se ensaya con datos de prueba y se documenta el procedimiento para restaurar ese entorno, sin experimentar sobre producción sin autorización.
Uso de IA para revisar caminos de error
Claude de Anthropic o herramientas de OpenAI pueden ayudar a localizar tratamiento de errores y proponer escenarios de interrupción. El equipo revisa que esos escenarios correspondan a situaciones posibles del programa. Una respuesta generada no demuestra que exista un punto de reinicio seguro.
Las instrucciones de recuperación se validan contra el entorno disponible. No se sustituyen nombres de archivos o comandos por suposiciones para completar un documento que parezca acabado.
Entregar un procedimiento ensayado y sus límites
La entrega describe las condiciones de la prueba, los pasos seguidos y las comprobaciones posteriores. También señala qué variantes no se han ensayado. Esto permite al responsable saber cuándo puede aplicar el procedimiento y cuándo debe pedir una revisión.
Como ejemplo hipotético, un proceso que genera movimientos y un resumen podría requerir comprobar ambos antes de repetirlo. El estudio determinaría la secuencia correcta. No se atribuye este caso a una organización zamorana ni se promete una recuperación instantánea.