COBOL en mainframes IBM: legado crítico en la era de la IA

La relación entre COBOL, los mainframes de IBM y la nueva ola de IA generativa está viviendo uno de sus momentos más intensos en décadas. Un lenguaje creado a finales de los años cincuenta, ejecutándose sobre máquinas que muchos consideran “de otra era”, se ha colocado de golpe en el centro del debate tecnológico y bursátil por culpa de una palabra muy concreta: modernización.

En las últimas semanas, el anuncio de Anthropic sobre Claude Code y sus capacidades para traducir y analizar sistemas COBOL ha provocado una auténtica sacudida en el mercado, con caídas millonarias en la cotización de IBM y un renovado interés por entender qué papel juegan todavía estos sistemas legacy. Para cualquiera que trabaje en tecnología —desde fundadores de startups hasta responsables de TI en banca o administración pública—, lo que está pasando con COBOL en mainframes IBM es un caso de estudio sobre cómo se cruzan la historia de la informática, la infraestructura crítica y la disrupción de la IA.

De CODASYL a COBOL 2023: cómo un lenguaje “provisional” se volvió imprescindible

Cuando en 1959 se formó la Conferencia sobre Lenguajes de Sistemas de Datos (CODASYL), pocos imaginaban que el lenguaje que estaban impulsando seguiría en producción más de sesenta años después. Aquel grupo, compuesto por organismos gubernamentales y grandes empresas, perseguía un objetivo muy concreto: crear un lenguaje de programación común, centrado en la gestión de datos de negocio y portable entre distintos sistemas.

COBOL heredó ideas de FLOW-MATIC, el lenguaje desarrollado por la pionera Grace Hopper, y se enmarcó dentro de una iniciativa del Departamento de Defensa de Estados Unidos. La meta era clara: disponer de un lenguaje que pudiera ejecutarse sobre diferentes sistemas operativos y plataformas de hardware, algo que hoy nos puede sonar trivial, pero que en aquella época era casi ciencia ficción. La portabilidad entre entornos como Linux, Windows, Unix o, más tarde, z/OS, se convirtió en una de las bases de su adopción masiva.

La primera especificación oficial de COBOL vio la luz en 1960 y, en teoría, se concibió como una solución temporal mientras aparecían alternativas “más avanzadas”. Sin embargo, el Departamento de Defensa comprobó rápidamente su utilidad práctica para aplicaciones de negocio y dio un paso decisivo: exigir a los fabricantes de ordenadores que ofrecieran soporte para COBOL en sus máquinas. Ese movimiento político y técnico fue clave para que IBM y otros proveedores lo integraran en sus plataformas mainframe.

Con el paso de los años, el lenguaje se fue consolidando y en 1968 se produjo un hito clave: la estandarización oficial de COBOL. A partir de ese momento llegaron sucesivas revisiones y variantes —COBOL-61, COBOL-68, COBOL-74, COBOL-85— que refinaron la sintaxis, mejoraron la gestión de datos y adaptaron el lenguaje a nuevas necesidades de negocio, pero sin romper la compatibilidad con las enormes bases de código ya desplegadas en mainframes.

Ya en el siglo XXI, el estándar COBOL 2002 intentó dar un salto importante introduciendo capacidades orientadas a objetos y otros paradigmas modernos, con la idea de que las aplicaciones pudieran integrarse mejor en prácticas de desarrollo actuales. No obstante, esa versión se topó con un problema muy humano: falta de soporte real y escasa demanda por parte de los usuarios, que no vieron claro el beneficio de adoptar las nuevas características frente al coste de actualizar sistemas estables.

Las últimas revisiones del estándar han seguido empujando el lenguaje hacia la interoperabilidad moderna. COBOL 14 sustituyó los antiguos resultados aritméticos portables por tipos de datos basados en IEEE 754, alineándose con normas ampliamente aceptadas en la industria. Y el estándar más reciente, COBOL 2023, se centra en mejorar aún más la forma en que COBOL puede interactuar con otros sistemas, lenguajes y plataformas actuales, reforzando su papel en entornos donde conviven arquitecturas tradicionales y cloud.

COBOL en mainframes IBM: un lenguaje inmortal en el corazón de la economía

Por veterano que parezca, COBOL sigue siendo el “motor oculto” de gran parte de la infraestructura financiera y administrativa del planeta. Diversas estimaciones señalan que en Estados Unidos gestiona alrededor del 95% de las transacciones en cajeros automáticos, y se habla de cientos de miles de millones de líneas de código COBOL en producción, muchas de ellas ejecutándose sobre mainframes IBM.

El éxito de esta combinación no es casual. COBOL fue diseñado específicamente para el procesamiento de datos de negocio, priorizando la legibilidad de las instrucciones y el manejo de grandes volúmenes de transacciones. Justo el tipo de carga que encaja a la perfección con los mainframes IBM Z, concebidos para procesar millones de operaciones por segundo con niveles de fiabilidad extremos.

En sectores como la banca, los seguros, las aerolíneas o los gobiernos, esta dupla COBOL + mainframe IBM lleva décadas demostrando su robustez. Se calcula que los mainframes de IBM llegan a procesar aproximadamente el 87% de las transacciones de tarjetas de crédito a nivel global y gestionan del orden de 8 billones de dólares en pagos diarios. No estamos hablando de sistemas marginales, sino de la auténtica columna vertebral de la economía digital.

El problema, sin embargo, no está en que COBOL falle técnicamente. Al contrario: funciona y lo hace muy bien. La gran preocupación es de tipo generacional. La mayoría de las personas que desarrollaron y mantuvieron estos sistemas durante décadas se ha jubilado o está a punto de hacerlo, y las universidades hace mucho que no forman de manera sistemática en este lenguaje. Como reconocía la propia Anthropic, cada año hay menos profesionales capaces de leer y entender estos programas con solvencia.

Ese desfase entre dependencia tecnológica y disponibilidad de talento ha disparado los costes de mantenimiento. La escasez de desarrolladores COBOL experimentados convierte cualquier proyecto de evolución o cambio en un esfuerzo largo y caro, alimentando una “deuda técnica” que ya no es solo un tema de ingeniería, sino un riesgo estratégico para la estabilidad de sistemas financieros y de administración pública.

IBM es muy consciente de esta situación y, lejos de vivir del inmovilismo, ha ido ampliando el ecosistema de sus compiladores y herramientas COBOL. Hoy en día, los compiladores IBM COBOL son compatibles no solo con z/OS, sino también con AIX y Linux, lo que permite ejecutar y desarrollar aplicaciones en entornos más variados sin renunciar al legado. Además, la compañía ha impulsado programas de formación y rutas de aprendizaje que pueden superar las 250 horas e incluyen COBOL, Java, Python, CICS, IMS, DevOps, analítica y desarrollo web, entre otros contenidos, precisamente para suavizar el relevo generacional.

De la traducción a la transformación: por qué la modernización COBOL es mucho más que pasar a Java

El anuncio de Anthropic sobre Claude Code y su capacidad para “modernizar” COBOL ha destapado un malentendido recurrente: la idea de que basta con traducir el código de un lenguaje a otro para dar por modernizado un sistema crítico. Esa simplificación, repetida en titulares y foros, ha sido uno de los factores que han contribuido a la brusca reacción del mercado contra IBM.

Lo que prometen herramientas como Claude Code es muy concreto: leer bases de código COBOL enormes, mapear puntos de entrada, rutas de ejecución, flujos de datos y dependencias, y a partir de ahí generar documentación y proponer traducciones a lenguajes modernos como Java o Python. Es una ayuda enorme para derribar la “caja negra” que muchas organizaciones tienen en sus sistemas legacy, pero no es ni de lejos la solución completa.

Los sistemas mainframe que ejecutan COBOL no son solo millones de líneas de código antiguas. Son el resultado de décadas de ajustes, parches, integraciones con otros sistemas, optimizaciones muy pegadas al hardware y procesos de negocio que han ido mutando al mismo ritmo que lo hacía la regulación. Traducir las instrucciones de un lenguaje a otro no resuelve, por sí solo, esa complejidad arquitectónica.

Un primer reto es la arquitectura monolítica sobre la que suelen construirse estas aplicaciones. La mayoría de los programas COBOL fueron diseñados para un mundo de procesos batch y transacciones centralizadas, muy lejos de conceptos como microservicios, arquitecturas cloud-native o despliegues continuos. Pretender que una traducción automática línea a línea genere un sistema “moderno” es ignorar que la arquitectura y el modelo de datos siguen siendo los mismos.

Otro obstáculo serio son las dependencias ocultas y no documentadas. A lo largo de décadas, muchos sistemas se han ido adaptando a las prisas, integrando ficheros, colas, jobs y servicios de otras áreas sin una documentación exhaustiva. Una herramienta de traducción puede convertir instrucciones COBOL en Java, pero no necesariamente descubrir qué otras aplicaciones dependen de ese módulo o qué acuerdos de nivel de servicio exige cada proceso.

A eso se suma que gran parte de la lógica de negocio está incrustada de formas muy específicas en el código. Reglas fiscales, particularidades de productos bancarios, excepciones regulatorias… Todo eso vive en sentencias COBOL que, a veces, solo entienden quienes las escribieron en su día. Modernizar sin perder ni un matiz de esa lógica implica interpretar y validar lo que hace cada módulo, algo que, por ahora, sigue necesitando supervisión humana experta.

Finalmente, está la cuestión del rendimiento y la optimización propias de los mainframes. Estas máquinas están preparadas para soportar volúmenes de transacciones gigantescos con latencias mínimas y altísima fiabilidad. Replicar ese comportamiento en infraestructura basada en servidores x86 o en la nube no es tan sencillo como “mover” el código; suele requerir rediseñar el sistema completo, ajustar bases de datos, colas de mensajería, mecanismos de recuperación ante desastres y un largo etcétera.

El coste real de modernizar: ROI, riesgos y el pánico bursátil alrededor de IBM

La reacción del mercado a las noticias sobre Claude Code ha sido tan llamativa como ilustrativa. Las acciones de IBM llegaron a caer en torno a un 13% en un solo día, su peor sesión desde el año 2000, y el valor de mercado se redujo en aproximadamente 30-40 mil millones de dólares en cuestión de horas. En el acumulado de febrero, los títulos llegaron a registrar un descenso cercano al 27%, apuntando al peor mes en décadas.

Ese desplome no puede entenderse solo como un movimiento técnico. Los inversores están revisando sus modelos sobre cómo la inteligencia artificial puede alterar negocios consolidados, especialmente aquellos basados en servicios intensivos en mano de obra, como la consultoría de modernización de sistemas legacy. En la narrativa más simplista, si la IA puede traducir COBOL “rápido y barato”, entonces una parte significativa de los ingresos de IBM asociados a mainframes y servicios podría estar en riesgo.

Sin embargo, cuando se analizan los números y la estructura del negocio, la foto es más matizada. En un año reciente, IBM reportó ingresos totales en el entorno de los 67.500 millones de dólares. De esa cifra, aproximadamente un 45% procede de software y el resto se reparte entre consultoría e infraestructura. Dentro de esta última se encuentra el negocio de los mainframes IBM Z, muy vinculado a aplicaciones COBOL. Diversos análisis estiman que alrededor del 20% de los ingresos de IBM, probablemente con un peso aún mayor en beneficios, depende de mainframes y entornos asociados a COBOL.

A la hora de la verdad, las decisiones de modernización no se toman solo por capacidad técnica, sino por retorno de inversión (ROI). Migrar un sistema crítico escrito en COBOL implica desembolsos directos importantes: traducción o reescritura del código, pruebas extensivas, formación de equipos en nuevas tecnologías, despliegue de nueva infraestructura y posibles licencias adicionales. Y eso sin contar los costes de oportunidad y riesgo: tiempo que se deja de dedicar a nuevas funcionalidades, interrupciones de servicio, bugs introducidos en sistemas que hoy funcionan sin incidentes graves y pérdida de conocimiento institucional en plena transición.

En sectores fuertemente regulados como la banca, los seguros o la administración pública, muchas organizaciones llegan a la conclusión de que seguir operando y optimizando los sistemas COBOL actuales, apoyándose en mainframes IBM, ofrece un ROI más predecible que una migración completa. Las herramientas de IA pueden cambiar la ecuación de costes, pero no eliminan la necesidad de evaluar cuidadosamente el impacto sobre la operación diaria.

En paralelo, el mercado vive lo que algunos han bautizado como “SaaSpocalypse”: una oleada de correcciones bursátiles en empresas de software como servicio (Salesforce, SAP, Microsoft, Adobe, Intuit, Atlassian, entre otras), alimentada por el miedo a que la IA pueda canibalizar modelos de negocio que parecían intocables. Lo ocurrido con IBM y COBOL es un capítulo más de esa misma historia: el temor de que la IA automatice tareas que antes justificaban contratos de alto margen.

Claude Code, IBM y el nuevo ecosistema de modernización asistida por IA

Dentro de este contexto de nerviosismo, resulta clave comprender qué hace exactamente Claude Code y cómo encaja en el panorama de herramientas de modernización. Anthropic ha presentado su solución como un sistema capaz de leer proyectos COBOL completos, identificar puntos de entrada, trazar rutas de ejecución y detectar acoplamientos implícitos en estructuras de datos y operaciones de archivo que muchas herramientas de análisis estático tradicionales pasan por alto.

Una vez realizado ese mapeo, Claude Code puede generar documentación detallada de flujos de trabajo que solo existían “codificados” en el propio programa, además de ofrecer una evaluación de riesgos que diferencia módulos relativamente fáciles de migrar de otros más delicados. La promesa comercial es contundente: reducir proyectos que antes duraban años a escalas de trimestres, al menos en lo que respecta a análisis, documentación y parte del refactoring.

Es importante destacar que la propia Anthropic reconoce la necesidad de supervisión humana experta. La IA puede automatizar mucha parte del trabajo tedioso, pero en sistemas críticos —especialmente financieros— no se puede prescindir de responsables que validen cada cambio. El papel de Claude sería, en ese sentido, el de un asistente muy capaz, no el de un sustituto total del equipo de modernización.

Anthropic no llega sola a este terreno. El mercado de herramientas de migración y modernización lleva años moviéndose. AWS Mainframe Modernization ofrece opciones tanto de refactorización como de replatforming; Microsoft Azure Mainframe Migration incluye utilidades para análisis y migración automatizada; y compañías como Micro Focus permiten ejecutar COBOL en entornos modernos sin traducción total del código, extendiendo la vida útil de las aplicaciones legacy.

La gran diferencia es que los modelos de lenguaje (LLM) como Claude permiten una comprensión más profunda y contextual del código, generando documentación, pruebas automatizadas y sugerencias de diseño a una velocidad que antes era inimaginable. Además de la traducción, empiezan a proliferar herramientas de documentación automática, análisis de dependencias, testing de regresión generado por IA y asistentes de arquitectura que ayudan a decidir qué migrar, cuándo y cómo.

Paradójicamente, IBM no es ajena a este movimiento. Hace ya varios años que la compañía presentó su propio enfoque para reescribir COBOL a Java usando IA, con productos como watsonx Code Assistant for Z. De hecho, el CEO de IBM había destacado en resultados recientes que parte del buen desempeño de la división de mainframes se debía precisamente a herramientas de conversión de código y a la demanda de modernización controlada en clientes grandes.

Además, IBM y Anthropic anunciaron en su momento una alianza estratégica para integrar modelos Claude en el ecosistema empresarial de IBM, incluyendo entornos de desarrollo asistidos por IA que reportaban aumentos de productividad de hasta un 45% en usuarios iniciales. Lo que se planteó inicialmente como sinergia ahora se reinterpreta, al menos desde el prisma bursátil, como una posible competencia directa en ciertas capas del negocio de servicios.

En cualquier caso, la clave es entender que ninguna IA, por sí sola, resuelve todos los frentes de una migración COBOL: siguen siendo necesarios proyectos que afronten el movimiento masivo de datos históricos, la sustitución de middleware, la reingeniería de integraciones, la reconstrucción de procesos de recuperación ante desastres y la adaptación de procedimientos operativos. Ahí es donde IBM sigue teniendo un peso enorme gracias a su experiencia, a su oferta de soporte empresarial y a su posición en sectores regulados.

Por qué IBM sigue siendo un actor estratégico pese al castigo en bolsa

Las fuertes caídas de la acción han llevado a muchos a preguntarse si la era del mainframe IBM está llegando a su fin. Sin embargo, si se mira más allá del ruido de corto plazo, hay varios factores que explican por qué el gigante azul mantiene una posición difícil de replicar, incluso en un mundo dominado por la IA.

En primer lugar, está la relevancia de su infraestructura mainframe en la economía real. Que una buena parte de las transacciones con tarjeta de crédito y pagos masivos diarios pasen por plataformas IBM Z no es un detalle menor. Las organizaciones que manejan ese tipo de operaciones valoran por encima de casi todo la fiabilidad, la seguridad, la capacidad de procesamiento y el soporte con acuerdos de nivel de servicio muy estrictos. No basta con una promesa de traducción de código: hace falta garantizar continuidad operativa, auditoría y cumplimiento regulatorio.

En segundo lugar, IBM ofrece contratos de soporte y garantías empresariales que resultan críticos para bancos, aseguradoras y organismos públicos. Si algo falla en un sistema que mueve miles de millones de euros al día, alguien debe asumir responsabilidad y actuar con rapidez. La combinación de hardware, software y servicios especializados de IBM constituye un paquete difícil de igualar para proveedores nuevos, por muy avanzadas que sean sus herramientas de IA.

También hay que considerar el ecosistema de herramientas construidas alrededor del mainframe a lo largo de décadas: soluciones de monitorización, seguridad, optimización de rendimiento, gestión de cambios, integración con otros entornos… Todo ello forma un “moat” que no se desmonta simplemente gracias a la aparición de una buena herramienta de análisis de código.

Aunque la falta de talento COBOL es un problema real, IBM ha invertido en programas de capacitación y en herramientas que hacen más accesible el entorno mainframe a nuevas generaciones. Rutas de aprendizaje que combinan COBOL con Java, Python, prácticas ágiles, DevOps y analítica de datos buscan evitar que los sistemas legacy queden aislados del resto del stack tecnológico.

Finalmente, muchos analistas señalan un aspecto casi irónico: si COBOL termina siendo reemplazado de forma masiva, IBM podría ganar todavía más dinero ayudando a ejecutar y orquestar esa transición, ya sea en sus propios mainframes, en nubes híbridas o en combinaciones de ambas. Es decir, el negocio podría desplazarse desde el mantenimiento puro del legacy hacia servicios de modernización y migración con alto valor añadido, un terreno donde la compañía ya tiene una presencia muy sólida.

Modernización inteligente para founders y líderes técnicos: estrategias y aprendizajes

Todo este ruido alrededor de COBOL, IBM y la IA deja varias enseñanzas útiles para fundadores de startups y responsables de producto o tecnología que se enfrentan a dilemas de modernización —aunque no tengan un mainframe en su vida.

Para empezar, conviene distinguir claramente entre mejora incremental y transformación total. Herramientas de IA como Claude Code, watsonx Code Assistant u otras pueden aportar un valor enorme en tareas como refactoring, documentación, análisis de dependencias o generación de pruebas. Eso no es lo mismo que reescribir por completo una plataforma y cambiar la arquitectura subyacente. Antes de embarcarse en un gran proyecto, es clave definir si el objetivo es mejorar la mantenibilidad, bajar costes de infraestructura o habilitar capacidades completamente nuevas.

Otro punto crítico es el cálculo del coste de oportunidad. Horas invertidas en migrar un sistema que funciona aceptablemente son horas que no se dedican a lanzar nuevos productos, mejorar la experiencia de usuario o explorar mercados. Preguntas como “¿esta migración desbloquea ingresos adicionales?”, “¿los ahorros justifican los riesgos?” o “¿existe un peligro real de obsolescencia que pueda hundir el negocio?” deberían estar encima de la mesa antes de dejarse llevar por la moda.

Además, conviene explorar estrategias híbridas en lugar de enfoques de “todo o nada”. Muchas organizaciones con éxito han optado por el llamado strangler pattern, en el que se va sustituyendo funcionalidad poco a poco mientras el sistema legacy sigue en marcha. Otros han preferido envolver sistemas antiguos detrás de APIs modernas, de forma que el núcleo COBOL se mantenga estable mientras el front-end y los servicios asociados se renuevan. También es habitual la modernización selectiva, concentrando esfuerzos en los módulos que aportan más valor o concentran más riesgo.

Por último, hay un factor que suele infravalorarse: el conocimiento de dominio incrustado en el código legacy. En muchos casos, las líneas de COBOL recogen reglas de negocio, excepciones y casuísticas que ya no se encuentran en ningún documento formal. Preservar y entender ese conocimiento es tan importante como la tecnología que lo ejecuta. La IA puede ayudar a extraerlo y ordenarlo, pero es necesario que haya personas que sepan validar y contextualizar lo que se obtiene.

La evolución reciente demuestra que la IA será una aliada formidable en la modernización de sistemas críticos, acelerando el análisis de grandes bases de código, mejorando la documentación, generando baterías de pruebas y ofreciendo modelos de impacto para cambios arquitectónicos. Sin embargo, sigue estando lejos de encargarse por sí sola de procesos complejos como migrar datos históricos, rediseñar integraciones, cumplir requisitos regulatorios estrictos o redefinir operaciones de negocio completas.

Lo ocurrido con IBM, COBOL y Claude Code sirve como recordatorio de que la estabilidad en tecnología es siempre relativa. Un anuncio bien planteado puede borrar decenas de miles de millones en capitalización en un día si el mercado interpreta que se ha resuelto un problema que llevaba décadas sin solución. Al mismo tiempo, la realidad técnica y operativa suele ser más tozuda: la infraestructura crítica cambia despacio, y quienes mejor entienden sus detalles son los que están en mejor posición para liderar la transición.

Toda esta situación deja clara una idea de fondo: los sistemas legacy no siguen vivos por inercia o pereza, sino porque han demostrado ser una forma extremadamente fiable de resolver problemas muy complejos. El debate no debería centrarse en si hay que traducir o no el código COBOL, sino en cuándo compensa modernizar, qué partes tiene sentido transformar y cómo combinar lo que ya funciona con las capacidades nuevas que trae la IA. En ese equilibrio, mainframes IBM, COBOL y las nuevas herramientas de inteligencia artificial seguirán conviviendo durante muchos años.