La migración de COBOL que compiló a la perfección y aun así corrompió el libro mayor

El código era perfecto. Ese era todo el problema.

Un programa de transferencias bancarias se había traducido de COBOL a Java. Compilaba. Las pruebas unitarias pasaban. Superaba todas las barreras que habíamos construido para atrapar errores. Entonces, en las pruebas de aceptación de usuario, la primera transacción activó la comprobación de consistencia de la base de datos y todo se vino abajo.

La autopsia llevó más tiempo del que debería, porque nada en el Java parecía estar mal. El culpable era una variable llamada TRN-LIMIT. La herramienta de traducción la había leído como un número corriente y le había dado un tipo entero estándar. Pero TRN-LIMIT nunca estaba definida donde la herramienta buscaba. Se declaraba en un copybook —un archivo de encabezado compartido— incorporado miles de líneas antes en la cadena de ejecución, y ese copybook llevaba una cláusula REDEFINES: una construcción de COBOL que permite que el mismo espacio de memoria se lea como dos tipos de datos completamente distintos según un indicador establecido en algún otro lugar por completo. En el mainframe, esa dirección contenía un decimal empaquetado. El nuevo código Java escribió binario corrupto en la columna de la base de datos, y la integridad referencial del libro mayor cedió.

El código era sintácticamente impecable. El fallo era contextual. La herramienta había pasado por alto una dependencia que vivía fuera de su campo de visión, y en la modernización de COBOL heredado, así es casi siempre como desaparece el dinero.

Los proyectos de modernización no suelen morir por el código que puedes ver. Mueren por el código que la herramienta no pudo ver.

Esta es la historia de por qué dejé de creer que una mejor traducción era la respuesta, y qué construimos en Veriprajna en su lugar.

¿Por qué "Pega COBOL, Obtén Java" siempre queda bien en la demo?

Si has estado en cualquier reunión de modernización de mainframe en los últimos dos años, has oído el argumento de venta: pega tu COBOL, recibe Java. Es seductor porque la demo siempre funciona. Alguien introduce un programa ordenado de 200 líneas, el modelo devuelve Java limpio e idiomático, y todos en la sala respiran aliviados. Por fin.

Yo también lo creí, durante un tiempo. Cuando mi equipo abordó esto por primera vez, hicimos lo obvio: intentamos hacer la traducción mejor. Alimentamos a los modelos con más contexto, los ajustamos para las peculiaridades de COBOL, medimos la calidad de la salida. Existe incluso un modelo abierto afinado llamado XMainframe, creado específicamente para esto, que puntúa alrededor de un 30 % más alto que los modelos de código de propósito general en tareas de COBOL. Las traducciones se volvieron más limpias. El Java se volvió más legible.

Y aun así se rompió en las pruebas de aceptación. Una y otra vez, exactamente en el tipo de dependencia oculta que hundió aquel programa de transferencias. Ese fue el mes en que me di cuenta de que estábamos puliendo lo que no era. La calidad de la traducción nunca fue el cuello de botella. El código que compila es la parte fácil. La parte difícil es el código que la herramienta no puede ver.

Las cifras en torno a esto son brutales y consistentes: entre el 70 y el 80 % de los proyectos de modernización de mainframe no logran cumplir sus objetivos. No es que el 70 % se retrase: el 70 % fracasa. El diagnóstico habitual culpa a las pruebas subestimadas o a una migración de datos desordenada, y esas son reales. Pero debajo de casi todos ellos está la misma causa raíz que acababa de ver en directo: las herramientas tratan una base de código como texto que hay que convertir, cuando en realidad es una topología que hay que comprender.

Lo que "Pega COBOL, Obtén Java" no puede ver

Una vez que empiezas a buscar la ceguera contextual, la ves por todas partes. Tres patrones nos rompieron con más frecuencia, y ninguno de ellos es visible en el archivo fuente que un traductor está mirando fijamente.

Empieza por el problema del copybook que ya describí. Un solo programa COBOL puede referenciar más de cuarenta copybooks, y esos copybooks incluyen otros copybooks, de modo que la definición real de una variable puede estar varios niveles de profundidad en la cadena de inclusión. Una herramienta basada en texto lee la instrucción que tiene delante e infiere un tipo. No tiene manera de saber que, en un campo decimal empaquetado, esa inferencia es silenciosamente errónea.

Luego está la aritmética. El decimal empaquetado COMP-3 de COBOL no tiene equivalente nativo en Java. Recurre a un double y acabas de introducir redondeo de coma flotante en un sistema que mueve dinero. Incluso BigDecimal, la herramienta correcta, no coincide con COBOL por defecto: tienes que fijar explícitamente su modo de redondeo a HALF_EVEN para reflejar la cláusula ROUNDED de COBOL. Hazlo mal y te desviarás un céntimo por transacción. Ese céntimo se acumula a lo largo de millones de transacciones hasta que, semanas después, un informe de conciliación señala una discrepancia que nadie puede explicar.

El patrón que casi todos olvidan es el que de verdad tumba la producción: tu COBOL no se ejecuta por sí solo. Un planificador —CA-7 o TWS— orquesta entre dos mil y cinco mil trabajos por lotes, con cadenas de dependencias entretejidas a través de ellos. El Trabajo A escribe un conjunto de datos a la 1 de la madrugada que el Trabajo B lee a las 2. Puedes migrar cada línea de COBOL sin fallo alguno y aun así tumbar el banco a medianoche, porque nadie mapeó la red de trabajos. El grafo de producción nunca estuvo en el código fuente. Estaba en el JCL.

El trabajo que rompe la producción a las 2 de la madrugada nunca es el que estabas mirando.

Esto es lo que quiero decir con topología. El artefacto que en realidad hace funcionar tu negocio es una red de relaciones —programas, copybooks, conjuntos de datos, trabajos planificados, tablas DB2, transacciones CICS— y el código fuente COBOL es solo una hebra de ella.

Por qué dejé de confiar en el traductor y empecé a dibujar el mapa

El punto de inflexión para nosotros fue decidir que el mapa es el producto.

Antes de traducir una sola línea, construimos un grafo de conocimiento de toda la base de código —cada programa, cada arista de copybook, cada dependencia de JCL, cada traspaso de conjunto de datos, cada punto de contacto con DB2— y resolvemos las relaciones transitivas que los archivos fuente ocultan. Cuando puedes ver que un programa tiene más de cuarenta aristas de copybook y que una de ellas lleva un REDEFINES a dos módulos de distancia, el desastre de TRN-LIMIT simplemente no ocurre, porque sabías que el campo era decimal empaquetado antes de teclear un solo carácter de Java.

Quiero ser preciso sobre por qué esto es distinto de lo que vende el resto del sector, porque el sector está saturado y la mayor parte de él es genuinamente buena en la parte que resuelve.

watsonx Code Assistant for Z de IBM es el actor establecido más serio —un sistema agéntico, con agentes de orquestación, arquitectura y código, que gestiona COBOL a Java e incluso PL/I e IMS, y analiza el consumo de CPU hasta llegar a los copybooks—. También es un compromiso de más de 2 millones de dólares que se ejecuta sobre z/OS y se apoya en el instrumental ADDI de IBM, lo que discretamente te ata al mainframe durante la migración destinada a liberarte de él. No hace pruebas de equivalencia de comportamiento, y no mapea tu red de trabajos JCL.

Luego está el momento que reconfiguró todo el mercado. En febrero de 2026, Anthropic publicó una guía de modernización de COBOL para Claude Code; la acción de IBM cayó un 13,2 % el día del anuncio, y en marzo le siguió una red de socios de 100 millones de dólares. Claude Code es excelente para el descubrimiento, la documentación y la lectura de código desconocido —genuinamente útil en las fases tempranas—. Pero es una herramienta de propósito general. No tiene un grafo de conocimiento integrado para resolver dependencias transitivas, y no pretende resolver la planificación de JCL, la equivalencia de comportamiento ni los rastros de auditoría que un banco regulado tiene que producir.

La fábrica de migración de Azure de Microsoft apunta a Java Quarkus y ata tu plataforma de destino a Azure. Los grandes integradores de sistemas —DXC con su motor de conversión patentado, TCS con MasterCraft, Infosys con Cobalt, Accenture— llevan a cabo contratos de entre 500.000 y más de 5 millones de dólares e implementan herramientas de proveedores en lugar de construir inteligencia sobre tu sistema; Accenture lideró la migración del núcleo del Commonwealth Bank of Australia, que costó aproximadamente 749,9 millones de dólares y llevó cinco años. Y Visual COBOL de Micro Focus, a menudo presentado como punto de partida, no es modernización en absoluto: es realojamiento (rehosting). Tu COBOL sigue siendo COBOL, solo que sobre un nuevo entorno de ejecución. La deuda técnica y el problema de la mano de obra están exactamente donde los dejaste.

Cada uno de estos hace algo real. Lo que ninguno de ellos hace es construir la topología completa de dependencias —JCL, CICS, DB2, copybooks y todo lo demás— primero, independiente de cualquier plataforma de destino, y tratar ese mapa como el cimiento sobre el que se sostiene todo lo demás.

La mayoría de los proveedores te venden un mejor traductor. La traducción nunca fue la parte que fallaba.

El reloj que nadie puede detener

Aquí está la parte que convierte esto de un problema de ingeniería en una emergencia.

Las personas que entienden estos sistemas se están yendo. El desarrollador de COBOL promedio en Estados Unidos ronda los 55 años. Aproximadamente el 10 % de esa mano de obra se jubila cada año, y el 85 % de las universidades eliminaron COBOL del plan de estudios allá por la década de 1990, así que casi nadie los está reemplazando. El sesenta por ciento de las organizaciones dice ahora que encontrar desarrolladores COBOL cualificados es su mayor desafío de modernización, y el 58 % de los desarrolladores que aún conocen estas pilas dicen que están planteándose dejarlo por su causa.

He estado ante la versión de esto que me persigue: la fiesta de jubilación de la única persona que de verdad entendía la ventana de procesamiento por lotes. Todos sonríen, hay una tarta, y en algún rincón de mi cabeza una voz dice ese conocimiento acaba de salir por la puerta y no está escrito en ninguna parte. Un grafo de conocimiento es, entre otras cosas, una manera de capturar lo que hay en la cabeza de esa persona antes de la fiesta: hacer que el mapa de dependencias sobreviva a las personas que lo memorizaron.

Y lo que está en juego no es pequeño ni abstracto. Alrededor de 220.000 millones de líneas de COBOL siguen en producción activa. Ejecuta el 95 % de las transacciones de cajeros automáticos y liquida aproximadamente 3 billones de dólares al día. El cuarenta y tres por ciento de los sistemas bancarios se construyen sobre él. La deuda técnica de Estados Unidos se sitúa en unos 1,52 billones de dólares estimados, y la empresa promedio quema alrededor de 370 millones de dólares al año en ineficiencia heredada, con las firmas de servicios financieros gastando entre el 70 y el 75 % de sus presupuestos de TI solo en mantener con vida los sistemas antiguos. Los equipos que aciertan con la migración reportan retornos del 114 al 225 % y alrededor de 25 millones de dólares al año en ahorros, pero ese beneficio solo existe al otro lado de una migración que no fracasó. Esta es la rara modernización en la que no hacer nada es la opción cara.

¿No resolverán esto sin más las nuevas herramientas de IA?

Esta es la pregunta que más me hacen, y es justa, especialmente después de que el anuncio de Anthropic hiciera parecer que el problema acababa de darse por resuelto.

Mi respuesta honesta: las nuevas herramientas hicieron la fase de descubrimiento drásticamente más rápida, y eso es un progreso real —yo las uso—. Pero que la IA agéntica se vuelva buena leyendo COBOL no cambia lo que de verdad mata los proyectos. Gartner espera que el 40 % de las aplicaciones empresariales incluyan agentes de IA para tareas específicas para 2026; más agentes traduciendo código más rápido no ayuda si todos son ciegos a la misma dependencia de JCL. La velocidad en el problema equivocado no es más que una forma más rápida de llegar a las pruebas de aceptación y fracasar allí.

La otra pregunta que me hacen es sobre la regulación, y es la que los bancos de nivel medio subestiman. La Ley de Resiliencia Operativa Digital de la UE —DORA— entró en vigor en enero de 2025 y exige pruebas de resiliencia operativa y de penetración dirigidas por amenazas que los sistemas heredados sencillamente nunca fueron diseñados para superar. Los examinadores estadounidenses de la FFIEC y la OCC tratan la infraestructura envejecida como una brecha de cumplimiento activa, y los sistemas de más de diez años conllevan aproximadamente el triple de probabilidad de sufrir una filtración. Una migración que no puede producir un rastro de auditoría que demuestre que el nuevo sistema se comporta de forma idéntica al viejo no es una modernización: es una nueva responsabilidad legal con mejor sintaxis.

Por eso las pruebas de equivalencia de comportamiento importan tanto como el mapa. La técnica es sencilla de describir y difícil de hacer bien: capturar entradas y salidas reales del sistema heredado —un conjunto de datos dorado— y reproducirlas contra el nuevo hasta que el comportamiento coincida, caso límite por caso límite. Esos casos límite, acumulados a lo largo de décadas, a menudo codifican lógica regulatoria que no existe en ninguna otra parte: ni en una especificación, ni en la cabeza de una persona, solo en el código en ejecución. He visto esto morder a una aseguradora con más fuerza que a un banco: la regla de tarificación que solo se dispara para un anexo de póliza de 1998, el cálculo de reserva de siniestros cuyo redondeo nadie vivo puede explicar pero del que depende cada auditoría. Piérdelos en silencio y descubrirás cuáles importaban el día en que un regulador pregunte.

¿Qué ladrillo sacas primero?

Una vez que tienes el mapa, te dice algo que ningún traductor puede: dónde es seguro empezar.

La estrategia dominante ahora —con buena razón— es la de la higuera estranguladora: en lugar de una reescritura de golpe, extraes una capacidad a la vez, ejecutas lo viejo y lo nuevo en paralelo, y mantienes el sistema heredado como respaldo en vivo hasta que la nueva pieza se haya ganado la confianza. Pero cada proveedor que recomienda la higuera estranguladora omite la pregunta más difícil: ¿qué módulo estrangulas primero? Elige uno fuertemente acoplado y habrás recreado el riesgo del cambio de golpe con pasos adicionales.

El grafo de conocimiento lo responde directamente. Hace aflorar los módulos de menor acoplamiento —los que tienen menos dependencias entrantes— para que puedas extraer una pieza real del sistema, demostrar el enfoque y construir confianza organizativa antes de tocar el núcleo peligroso. El mapa no es solo un seguro contra el fallo de TRN-LIMIT. Es el plan de secuenciación.

Construimos todo esto —el grafo de conocimiento de dependencias, la secuenciación de la higuera estranguladora, el arnés de equivalencia de comportamiento, deliberadamente independiente de cualquier plataforma de destino— dentro de la práctica de modernización de COBOL heredado de Veriprajna, dirigida directamente a los bancos y aseguradoras de nivel medio que los actores establecidos con un umbral de 2 millones de dólares y los integradores de sistemas de siete cifras consideran demasiado pequeños para molestarse.

En qué soy honesto

No fingiré que la tecnología lo resuelve todo, porque los fracasos más caros que he visto no eran técnicos en absoluto.

Ninguna herramienta —la nuestra incluida— arregla el respaldo de la organización, limpia años de datos malos ni gana la batalla política de convencer a doscientos desarrolladores de que cambien su forma de trabajar. Se proyecta que el mercado crezca desde unos 9.000 millones de dólares en 2026 hasta el doble para el final de la década precisamente porque gran parte del gasto se destina a la capa humana y organizativa, no al compilador. Y ningún analizador sintáctico sobre la tierra, de código abierto o comercial, cubre a la perfección cada construcción de IBM Enterprise COBOL: las sentencias ALTER anteriores a 1985, los REDEFINES más profundos. Cualquiera que te diga lo contrario te está vendiendo la brecha. La tecnología es necesaria. Nunca ha sido suficiente.

Pero la parte que la tecnología sí puede poseer, debe poseerla por completo. La razón por la que las migraciones consumen millones y no entregan nada rara vez es que alguien escribiera mal el Java. Es que tradujeron un sistema que en realidad nunca habían mapeado, convirtiendo hebras de una red mientras la red misma permanecía invisible hasta la noche en que se desgarró.

Dibuja el mapa primero. Un sistema que ha sobrevivido a las personas que lo escribieron no perdona una dependencia pasada por alto, y no existe ninguna versión de este trabajo que sea segura antes de que puedas ver qué se conecta con qué. Lo aprendimos de un libro mayor deshecho por un solo campo decimal empaquetado que nadie sabía que estaba ahí. Encuentra esos campos antes de que ellos te encuentren a ti.