Cuando el problema es la conexión, no el lenguaje
Una aplicación puede seguir resolviendo bien los cálculos y, sin embargo, resultar difícil de conectar con una web, un gestor documental o un sistema de pedidos. Para una empresa de Teruel en esa situación, reescribir todo COBOL puede añadir un riesgo innecesario. Empezamos por describir qué información necesita entrar o salir y cuándo debe hacerlo.
Después distinguimos las consultas de las operaciones que modifican datos. Leer un saldo no plantea el mismo compromiso que registrar un cobro. Una integración debe respetar esa diferencia y evitar que un fallo de comunicación deje al usuario sin saber si la operación se ha realizado.
Diseñar el punto de entrada al sistema
Podemos plantear un adaptador que reciba solicitudes, valide los campos y se comunique con el componente existente. La tecnología concreta depende de lo que permita la plataforma: no damos por supuesto que todos los entornos COBOL admiten el mismo mecanismo de conexión.
El contrato de la interfaz describe los datos aceptados y los errores que puede recibir el consumidor. También define cómo identificar una solicitud repetida. Ese acuerdo evita que dos aplicaciones interpreten de forma distinta una fecha vacía, un código desconocido o un tiempo de espera agotado.
Qué parte puede pasar a C# y .NET
Una alternativa es trasladar a .NET la capa de acceso o una función delimitada, conservando temporalmente el resto. La separación debe hacerse por responsabilidades comprensibles: validación de entrada, cálculo, almacenamiento o presentación. No por un número arbitrario de líneas de código.
Para decidir qué extraer revisamos las dependencias compartidas. Si el módulo toca numerosas tablas y estados globales, quizá convenga preparar primero una frontera más clara. El resultado del análisis puede ser mantener ese módulo y modernizar otro; no forzamos una migración solo porque sea posible generar código nuevo.
La IA como apoyo al mapa de dependencias
En proyectos autorizados podemos utilizar OpenAI o Claude de Anthropic para revisar llamadas y proponer una explicación de un flujo. Esa explicación se considera una hipótesis de trabajo hasta contrastarla con el código, las pruebas y el conocimiento de los usuarios.
Una interfaz generada con IA tampoco se publica directamente. Revisamos validaciones, permisos y tratamiento de errores, además de la correspondencia con la operación COBOL. El acuerdo sobre qué código puede analizar una herramienta se establece antes de compartir repositorios.
Ensayar la convivencia antes de abrir el acceso
La prueba debe incluir algo más que una solicitud correcta. Simulamos respuestas lentas, referencias inexistentes y cortes entre la recepción y la confirmación. Documentamos lo que verá la aplicación nueva y la acción que deberá realizar el operador.
Por ejemplo, una consulta externa de disponibilidad puede empezar como acceso de solo lectura mientras el alta de pedidos continúa en el sistema actual. Este ejemplo orienta el alcance; no describe un despliegue realizado en Teruel. La puesta en marcha se acuerda cuando las comprobaciones permitan entender también los fallos.