Un piloto que permita decidir, no una reescritura a ciegas
Para una empresa de Zaragoza con una aplicación COBOL, empezar por convertir todos los programas suele ser una mala forma de descubrir las dependencias. Proponemos seleccionar una operación que se pueda ejecutar de manera aislada: una liquidación, una consulta o la generación de un fichero. El módulo elegido debe ser suficientemente representativo para revelar dificultades, pero no tan amplio que impida interpretar los resultados.
El diagnóstico incluye el compilador, los datos que necesita el programa y las llamadas que realiza. También preguntamos quién utiliza la salida, qué ocurre cuando faltan registros y cómo se corrige una ejecución fallida. Ese recorrido conecta el código con el trabajo de las personas que dependen de él.
De COBOL a .NET: qué se conserva y qué se rediseña
En una migración a C# sobre .NET distinguimos la regla de negocio de su forma de ejecución. Un cálculo puede mantenerse mientras cambian la lectura del fichero, la autenticación o la entrega del resultado. Separar esas decisiones evita atribuir a la traducción del lenguaje problemas que pertenecen a la arquitectura.
No damos por equivalentes dos programas porque ambos compilen. Definimos ejemplos de entrada, salidas esperadas y diferencias permitidas. Si el sistema original descarta decimales o acepta un campo vacío de una manera particular, esa conducta debe quedar documentada antes de decidir si se reproduce o se corrige.
Dónde encajan Claude, Anthropic y OpenAI
Podemos plantear el análisis con Claude, de Anthropic, o con herramientas de OpenAI, según el entorno autorizado por el cliente. En el piloto, la IA ayuda a proponer una descripción de las dependencias, preparar borradores de pruebas y plantear una implementación. Cada propuesta se contrasta con el programa y con ejecuciones controladas.
La elección de la herramienta no decide por sí sola el destino técnico. Antes de proporcionar código se acuerda qué información puede salir del entorno de la empresa. Una credencial, un fichero real de clientes o un acceso de producción no debe convertirse en material de prueba por comodidad.
Mantenimiento mientras se prepara el cambio
La modernización no obliga a congelar todas las mejoras del sistema actual. Podemos separar una línea de mantenimiento COBOL y otra de migración, dejando identificado qué correcciones deben trasladarse a ambas. Esto resulta especialmente útil cuando el piloto convive con peticiones de los usuarios.
El entregable de esta fase puede contener el inventario del módulo, una versión de destino, las pruebas comparativas y las decisiones pendientes. Con esa información se estima la siguiente parte del trabajo. No se presupone que el esfuerzo del primer programa se repetirá de forma idéntica en todos los demás.
Un ejemplo de alcance razonable
Imaginemos un proceso que recibe un fichero de pedidos y produce un resumen de importes. El piloto podría conservar el formato de entrada, sustituir únicamente el cálculo y mantener temporalmente la salida que consume otro programa. Compararíamos pedidos anulados, importes negativos y referencias desconocidas, además de los ejemplos habituales.
Se trata de una situación ilustrativa, no de un proyecto realizado para un cliente local. Sirve para concretar qué preguntar en la primera reunión y para evitar una propuesta que diga simplemente «pasar todo a .NET» sin explicar cómo se demostrará que funciona.