Un cambio pequeño puede tener consumidores invisibles
Modificar la longitud de un campo en un copybook puede afectar a programas que no estaban incluidos en la petición inicial. Antes de editarlo, identificamos qué componentes lo utilizan y cómo se construyen. El objetivo es conocer el alcance real del cambio, no limitarse al archivo que menciona la incidencia.
Para empresas alavesas con varias aplicaciones relacionadas, proponemos una relación de dependencias que se pueda mantener. No tiene que convertirse en un documento enorme: debe permitir responder quién consume una definición y qué pruebas se necesitan cuando se modifica.
Reconstruir el vínculo entre fuente y ejecutable
Un repositorio útil no es solo un lugar donde guardar programas. Necesita explicar qué versión genera cada entrega y con qué opciones se compila. Revisamos también los archivos de configuración y los elementos que se distribuyen fuera del propio código.
Si no existe una correspondencia fiable con el ejecutable en uso, lo señalamos como un riesgo previo a la migración. Convertir una versión que ya no representa producción puede dar una falsa sensación de avance. La primera tarea puede ser recuperar y verificar esa correspondencia.
Mantenimiento y migración sin ramas que se olvidan
Durante una transición a C# y .NET, el sistema COBOL puede seguir recibiendo correcciones. Definimos cómo registrar cada cambio y evaluar si también afecta al destino. La respuesta no debería depender de que alguien recuerde un correo varias semanas después.
Una prueba asociada a la corrección ayuda a trasladar el conocimiento entre versiones. También distinguimos las adaptaciones necesarias para el nuevo entorno de los cambios que alteran el negocio. Mantener esa diferencia facilita la revisión y la posterior aceptación del usuario.
Revisar propuestas de IA como cambios de código
El uso de OpenAI o de Claude, de Anthropic, no elimina la revisión del repositorio. Una propuesta generada se presenta con su propósito, los archivos afectados y las comprobaciones realizadas. Evitamos aceptar modificaciones amplias que mezclen una reparación concreta con una reestructuración difícil de evaluar.
Las instrucciones dadas a la herramienta pueden incorporar convenciones del proyecto y archivos que no debe tocar. Aun así, se comprueba el resultado. La restricción escrita en una instrucción no sustituye una revisión de diferencias ni los permisos de acceso adecuados.
Qué aporta una primera intervención
El alcance inicial puede centrarse en un conjunto de programas compartidos: identificar fuentes, documentar construcción y añadir pruebas para una modificación prevista. Ese trabajo ya mejora el mantenimiento, aunque después se decida conservar COBOL.
Como situación orientativa, una empresa podría necesitar ampliar un identificador usado por varios procesos. El proyecto revisaría productores, consumidores y compatibilidad durante el cambio. No presentamos ese ejemplo como una instalación existente en Álava, sino como una forma concreta de explicar el servicio.