Cómo validar una migración de COBOL o mainframe con IA

Validar una migración de COBOL o de otros sistemas legacy implica comprobar que el sistema migrado conserva el comportamiento del sistema original. Una estrategia para hacerlo es usar ese sistema original como especificación: capturar cómo se comporta, repetir las mismas ejecuciones en el sistema migrado y analizar cada diferencia.

En sistemas de millones de líneas, eso solo es viable si se divide el problema en partes más manejables y se arma un plan basado en riesgo. Usamos IA para poder trabajar a esta escala en el código legacy y validamos los resultados con las personas que conocen el negocio.

Es un desafío que va a ser cada vez más común, porque COBOL (así como otras plataformas legacy) sigue en el centro de muchos negocios. Según IBM, procesa el 95% de las transacciones en cajeros automáticos y es la base de más del 40% de los sistemas de banca en línea. Además, se estima que siguen en producción más de 220.000 millones de líneas de código COBOL. Incluso muchas fintechs con aplicaciones modernas en el front funcionan sobre un core en COBOL por detrás.

Hace más de 20 años que trabajo en testing y participé en migraciones legacy mucho antes de la IA generativa. En este artículo, comparto cómo abordamos hoy ese desafío en Abstracta, con ejemplos de un proyecto en curso: la migración a la nube del sistema core de una fintech de Latinoamérica, escrito en COBOL y con más de 8 millones de líneas de código.

Estos son seis enfoques que usamos para validar una migración de COBOL:

1. Usar el sistema COBOL original como especificación.
2. Entender el código sin documentación, con apoyo de agentes de IA.
3. Observar el sistema original en ejecución.
4. Probar a distintos niveles del sistema, por ejemplo, con validaciones específicas para la migración de datos.
5. Definir una estrategia distinta para cada componente según su riesgo.
6. Revisar a escala lo que genera la IA y validar con el negocio.

Presenté este enfoque en una Abstracta Tech Talk, con una demo sobre código RPG:

▶Play

El ejemplo: una migración de COBOL de 8 millones de líneas¶

La fintech necesitaba migrar su sistema core porque la versión de la plataforma que utiliza se acercaba al fin de su período de soporte. Para evitar operar sobre una tecnología sin respaldo ante futuros problemas, la empresa decidió llevar el sistema a la nube. El proyecto tiene una duración prevista de dos años y ya superó la mitad de su recorrido.

Por las limitaciones del lenguaje y la plataforma base, el sistema tiene poca modularización y acumula tres décadas de cambios y parches. La documentación es escasa o está desactualizada, y muchas de las personas que participaron en su desarrollo ya no forman parte del equipo, con lo cual es común encontrar porciones del código o módulos completos que nadie sabe cómo funciona su implementación.

A esto se suma que procesa movimientos de dinero en un entorno regulado, por lo que cualquier cambio requiere un alto nivel de control. Lo que está en riesgo es la continuidad del negocio, ya que todo opera sobre este sistema core.

Nuestro rol es acompañar el testing de la migración. El principal desafío no está en el desarrollo, sino en validar que el sistema migrado mantenga el mismo comportamiento que el actual y que los procesos críticos sigan funcionando correctamente.

¿Por qué el testing es el cuello de botella al migrar COBOL?¶

Con todo ese código en producción, la gran pregunta es cómo migrarlo sin poner en riesgo el negocio.

Con asistentes y agentes de IA, reescribir código COBOL en una nueva arquitectura requiere mucho menos esfuerzo que antes. El desafío se desplaza entonces al testing: validar que el sistema migrado conserve el comportamiento del original y produzca los mismos resultados.

En febrero de 2026, Anthropic publicó un artículo sobre modernización COBOL con Claude Code y una guía de modernización de código. Al leerla en detalle, me quedó la sensación de que plantea un escenario más simple del que encontramos en sistemas reales.

Contar con una licencia de Claude Code y seguir esa guía puede ser suficiente para un sistema de algunos miles de líneas. Pero los sistemas COBOL que llevan décadas en producción suelen concentrar conocimiento de negocio en enormes volúmenes de código. A esa escala, la migración ya no es solo un problema de reescritura, sino de ingeniería: cómo estructurar el proceso, cómo dividirlo en partes manejables y cómo reducir el riesgo.

Más del 90% del proyecto fue testing¶

Hace más de diez años, participé en uno de mis primeros grandes proyectos de migración. Una cadena de supermercados de Latinoamérica, que había empezado como una pequeña tienda 25 años antes, tenía 10 locales y quería abrir el número 11. Pero su sistema RPG utilizaba un identificador de tienda de un solo dígito. Cambiar ese dato impactaba en la estructura de la base de datos y, a partir de ahí, en procesos como el manejo de stock, los movimientos de dinero y los saldos de cuenta.

La empresa no tenía documentación, casos de prueba ni una práctica de testing establecida, y quienes habían desarrollado el sistema se habían jubilado, se habían ido o habían fallecido. Solo quedaban el código y los usuarios. Durante un año y medio entrevistamos a los usuarios clave para documentar cómo funcionaba el sistema y qué comportamiento esperaban de él, reconstruimos las especificaciones y escribimos pruebas. El cambio de código llevó apenas un mes y medio. Más del 90% del proyecto fue testing.

El proyecto salió bien, pero esa proporción explica por qué migraciones como esa eran poco comunes. Hoy, con la IA reduciendo todavía más el esfuerzo necesario para modificar o reescribir código, es probable que muchos proyectos de migración sigan ese mismo patrón: menos tiempo dedicado al desarrollo y mucho más esfuerzo destinado a validar que el sistema siga funcionando como debe.

Deuda técnica y deuda cognitiva¶

La deuda técnica aparece cuando resolvemos algo de una forma que después dificulta mantener o modificar el sistema: falta de documentación, pruebas automatizadas, modularización u otras decisiones que generan costos a futuro.

La deuda cognitiva, un concepto que plantea la investigadora Margaret-Anne Storey, es una deuda de conocimiento: no entender cómo funciona una parte del código ni por qué fue construida de esa manera. La vi muchas veces en equipos que dicen: "ese código no se toca porque nadie sabe por qué funciona". En esos casos, incluso puede haberse perdido la regla de negocio que originalmente llevó a escribirlo así.

En una migración COBOL, ambas deudas conviven. El desafío no es solo transformar código antiguo, sino reconstruir suficiente conocimiento sobre el sistema para poder validar que el nuevo se comporte igual. En un sistema de 30 años, la deuda cognitiva suele pesar más que la técnica, y ahí es donde la IA más aporta: más que escribir código nuevo, ayuda a generar comprensión sobre el código viejo.

Enfoque 1: usar el sistema COBOL original como especificación¶

En una migración COBOL, el objetivo del testing es comprobar equivalencia: que el sistema migrado se comporte igual que el original. En un desarrollo nuevo buscamos que el software sea correcto según lo que espera el negocio. En una migración, el sistema legacy ya sostiene un negocio que funciona, así que su comportamiento actual pasa a ser la especificación y el oráculo de las pruebas.

Cuando hablo de código legacy me gusta volver a un libro de referencia de 2004, Working Effectively with Legacy Code, de Michael Feathers. Feathers define el código legacy como código sin pruebas: si algo cambia, no hay forma de validar que el comportamiento siga siendo el que el negocio necesita. Para esos casos, propone el enfoque de characterization testing.

Aplicado a una migración COBOL, funciona así:

1. Ejecutar pruebas funcionales y automatizadas que cubran la mayor cantidad posible de caminos del sistema original.
2. Guardar el output de esas ejecuciones.
3. Reproducir las mismas ejecuciones en el sistema migrado y guardar su output.
4. Comparar ambos outputs y analizar cada diferencia, porque ahí puede haber un error de la migración.

En este enfoque no importa si el output original es correcto. Lo que importa es detectar dónde el sistema nuevo se comporta distinto. Para mí, es el enfoque a seguir en cualquier modernización de este tipo.

No hay magia en esto: lo que hacemos es escalar con IA un patrón que Feathers describió hace más de 20 años. Me gusta resumirlo así: la IA hace el checking, y las personas hacen el testing potenciadas con la información que pueden obtener gracias al uso de IA.

Para generar esa cobertura, trabajamos con dos vías complementarias, funcional y automatización, con dos miradas: una estática, sobre el código, y otra dinámica, sobre el sistema en ejecución. Los enfoques 2 y 3 explican cada mirada.

Enfoque 2: entender el código COBOL sin documentación¶

Cuando un sistema COBOL no tiene documentación actualizada, la fuente más confiable pasa a ser el propio código. Un amigo de la facultad solía decir que la mejor documentación para describir cómo funciona un sistema está en el propio código fuente, porque es la única que siempre está al día. En estas migraciones queda claro que tenía razón. La dificultad está en encontrar lo que se necesita dentro de millones de líneas, y eso es justamente lo que los agentes de IA vuelven viable.

Un agente que analiza todo el repositorio permite ir de lo general a lo particular y generar distintos artefactos según lo que haga falta entender:

• Diagramas de arquitectura y de componentes, para tener una primera foto del sistema.
• Pseudocódigo o diagramas de secuencia, para entender un flujo de punta a punta.
• Máquinas de estado, para seguir el ciclo de vida de una entidad de negocio.
• Diagramas de flujo, para entender la lógica y detectar casos borde.
• Documentación, casos de prueba y datos de prueba derivados del propio código.

De todos modos, considero que lo más valioso no son los diagramas, sino contar con una base de conocimiento que el equipo de testing puede consultar en lenguaje natural, con preguntas de negocio tales como "¿cómo se calculan los intereses de un préstamo vencido?".

Para el testing automatizado, el mismo análisis estático genera mapas de dependencias y grafos de llamadas, a partir de los cuales se derivan pruebas unitarias, de API, de interfaz y de performance. La performance merece atención propia, porque es otro de los riesgos importantes en este tipo de migraciones.

Una forma simple de verlo: el enfoque estático te da el mapa, y el dinámico, que veremos en el enfoque 3, confirma que el sistema sigue recorriéndolo.

Cómo lo hacemos con Tero¶

En Abstracta, usamos Tero, nuestro agent harness open source para crear agentes de IA especializados que operan con contexto y gobernanza a escala.

En la última Abstracta Tech Talk, mostré un agente conectado a un repositorio open source escrito en RPG, un código que yo no conocía de un sistema de manejo de empleados y clientes. Primero le pedí un diagrama de la arquitectura, después que me explicara qué hace la aplicación y cuál es la estructura de su base de datos, incluidos los tipos de datos de cada atributo. Luego le pregunté cómo se da de alta un empleado: me devolvió las reglas de negocio, los archivos involucrados y el pseudocódigo de esa lógica. Como el pseudocódigo me resultó complejo, le pedí que lo representara como un diagrama de flujo.

Tero puede ser desplegado en la nube privada de cada organización o en su propia infraestructura on-prem, y funciona con el LLM que esa organización elija: modelos de OpenAI o de Anthropic, o incluso un modelo open source instalado localmente, como ya ocurre con uno de nuestros clientes. Así, la información del sistema se mantiene en un entorno controlado.

A través de MCP o por API disponibles en Tero, los agentes se conectan con las herramientas que el equipo ya usa: el repositorio de código, los gestores de tareas y documentación como Jira, Confluence, Linear o Redmine, gestores de pruebas como PractiTest o Zephyr, las fuentes de observabilidad (métricas, logs y trazas) y las bases de datos. Para sistemas legacy armamos además un MCP que se conecta a un AS400.

Enfoque 3: observar el sistema COBOL en ejecución¶

Se habla mucho del contexto que necesita un agente de IA para hacer bien su trabajo. Las personas que hacen las pruebas también lo necesitan, y la observabilidad es una de las mejores formas de dárselo: permite ver qué hace el sistema original por detrás de cada acción, algo que el código por sí solo no muestra y mucho menos la pantalla a través de la cual se interactúa con el sistema.

En testing funcional, la idea es que quien testea explore el sistema original acompañado por un copiloto que le cuenta, en lenguaje natural, qué está haciendo el backend:

• Qué endpoints se llamaron y qué registros se modificaron.
• Qué jobs quedaron encolados y cuál es la traza de cada uno.
• Qué cambios de estado ocurrieron.
• Qué errores internos se produjeron, aunque no se muestren al usuario.

Así, el tester ve logs, trazas y consultas sin salir de la prueba, y deja de adivinar qué está pasando por detrás. Junto con un partner desarrollamos un copiloto de este tipo para un sistema de e-banking, y después aplicamos la misma idea en otros entornos. Por detrás se conecta con los logs y las herramientas de observabilidad que ya existían; lo nuevo es que ahora se puede consultar todo en lenguaje natural, lo cual le da más facilidad de acceso a un público más amplio (por ejemplo, testers, analistas o PMs sin experiencia en programación).

En testing automatizado, la observabilidad cumple otro rol: muestra qué cobertura están logrando las pruebas y permite seguir mejorándolas.

¿Se puede tener observabilidad en un mainframe?¶

Sí, y no es algo nuevo. Hace unos 15 años conocí CA Wily (hoy llamada DX APM, de Broadcom), una de las primeras herramientas de observabilidad moderna que conocí, que ya se conectaba con mainframes. Su fundador después creó New Relic (de esto me enteré porque él mismo me lo contó cuando lo conocí en un evento en 2016). Recuerdo conversaciones y sesiones de trabajo con administradores de un AS400 y desarrolladores RPG o COBOL que me mostraban cómo lograban tener trazabilidad completa, desde la acción del usuario hasta el registro que se modificaba en la base de datos.

Las plataformas más modernas, como Datadog, pusieron el foco en arquitecturas Cloud y Kubernetes, y no siempre son tan compatibles con plataformas legacy. Aun así, de una forma u otra se puede reconstruir la trazabilidad entre la acción de un usuario y el dato que terminó modificando en la base.

Enfoque 4: probar a distintos niveles del sistema¶

Al inicio del proyecto actual con la fintech que mencionaba antes, el primer enfoque parecía simple: leer el código, generar pruebas unitarias con 100% de cobertura, ejecutarlas y dar el trabajo por terminado. Pero no fue tan fácil.

Analizamos el árbol de llamadas para probar desde las hojas hacia arriba y simular las dependencias que ya estaban probadas. Enseguida aparecieron varias limitantes. Ejecutar la prueba de un solo archivo lleva alrededor de un minuto, así que un set básico para más de 9.000 archivos llevaría unos 9.000 minutos, y esas pruebas se ejecutan muchas veces a lo largo del proyecto.

Las herramientas para pruebas unitarias y medición de cobertura en COBOL suelen estar restringidas por licencias o por limitaciones del compilador, y cada nuevo inicio requiere restaurar una base de datos, algo que lleva unas 5 horas. Además, las pruebas unitarias necesitan unidades bien definidas, y en un monolito como este eso obliga a encontrar primero sus puntos de corte (vuelvo sobre esto en el enfoque 5).

El segundo enfoque: probar desde los puntos de entrada¶

Por eso cambiamos de estrategia y llevamos la automatización al nivel de los scripts DCL, que automatizan workflows del sistema, y de los wrappers de las APIs, que son los puntos de entrada más cercanos a la integración y al usuario. Así pasamos de más de 9.000 archivos a más de 750 puntos de entrada. Sigue siendo un volumen importante, así que priorizamos según los logs de uso y las entrevistas con usuarios clave. Uno de los primeros hallazgos fue que un porcentaje alto de archivos no se usaba desde hacía más de un año o tenía comportamiento duplicado.

Tampoco trabajamos directamente sobre el código COBOL. A partir del análisis del código generamos un formato intermedio en markdown que explica cada funcionalidad: inputs, outputs, variables, caminos posibles y casos borde. Ese formato sirve para dos cosas: el LLM lo usa para generar las pruebas automatizadas, y el equipo de testing lo usa para validar el comportamiento con los responsables del negocio. Las pruebas generadas pasan por un proceso de code review que combina revisión automatizada y la de una o dos personas.

Este enfoque también tiene sus costos. Perdemos algo de control sobre la cobertura de código, pero ganamos correlación con las prioridades del negocio. Y hay que tener en cuenta que los bugs que ya existen en producción van a aparecer en las pruebas de characterization testing, porque el sistema original es la referencia. Conviene decidir de antemano qué hacer con ellos. Por último, un recordatorio que vale para cualquier migración: no hay que olvidar ni subestimar la performance.

Characterization testing también en la capa de datos¶

Como verificación adicional, el enfoque suma la capa de datos. El código de la fintech tiene más de 40.000 sentencias SQL embebidas, y la idea es contar con pruebas automatizadas que ejecuten esas consultas sobre la base original y comparen los resultados con los de la base migrada. Para eso se usa una copia de producción. La comparación incluye tanto los datos como los tiempos de respuesta.

Todo esto forma parte de un enfoque iterativo. El objetivo es mejorar la herramienta de migración en etapas tempranas: ejecutar pruebas pequeñas sobre su salida, detectar lo que no funciona y corregirlo. La migración final va a incluir la ejecución completa de las pruebas, y la idea es llegar a ese momento con menos sorpresas.

Enfoque 5: definir una estrategia distinta para cada componente según su riesgo¶

Un sistema COBOL grande no se puede migrar ni testear como una sola unidad. Hay que dividirlo en partes y definir una estrategia para cada una según su riesgo. A esas partes las llamamos slices: pueden ser unidades verticales de negocio o capas técnicas, y cada una tiene su propio diagnóstico, sus propios controles y su propia evidencia.

Qué no suele funcionar¶

En muchas migraciones veo dos problemas que se repiten. El primero es que el diagnóstico es descriptivo en lugar de operacional: "legacy" se usa como sinónimo de "viejo", una etiqueta que no mide nada. El riesgo se estima por intuición, y las decisiones sobre alcance y velocidad se toman por percepción y no con evidencia. El segundo es que la ejecución no tiene gates basados en evidencia: las migraciones se planifican como un big bang, no hay mediciones claras de cobertura de pruebas y faltan procedimientos de rollback.

Una metodología en seis fases¶

Para ordenar ese trabajo usamos una metodología de seis fases sobre cada slice:

1. Discovery y baseline: construir una descripción verificable del sistema tal como está hoy.
2. Estrategia de migración: decidir qué cambia, cómo y en qué orden.
3. Control del comportamiento: construir la red de seguridad antes de cambiar nada.
4. Implementación: hacer el cambio de forma gradual, mejorar el script de migración con pruebas tempranas y ejecutar las pruebas finales antes de pasar a producción.
5. Puesta en marcha y despliegue: ampliar el tráfico a medida que hay evidencia, con el rollback listo.
6. Estabilización y entrega: cerrar el ciclo con el equipo de operaciones.

En la fase de estrategia se toman tres decisiones por slice: cómo particionar y en qué orden avanzar, qué cambia (infraestructura, runtime, arquitectura, datos, proveedor o integraciones) y con qué modo de transición, como coexistencia, strangler, branch by abstraction o expand-contract. Profundizamos en esta metodología en el artículo sobre modernización legacy con IA.

Cómo medir el riesgo de cada slice¶

El diagnóstico de cada slice se basa en ocho dimensiones que indican qué capacidad tiene esa parte del sistema de producir evidencia verificable:

Cada dimensión se evalúa en una escala de madurez de 0 a 4: inexistente, inicial o aislada, definida, gestionada y optimizada. Con esa evaluación, cada slice queda en una clase de riesgo:

• Crítico: una o más dimensiones en nivel 0. No hay red de seguridad para empezar a migrar.
• Alto: dimensiones críticas en nivel 1, o dos dimensiones de soporte en nivel 0. Hace falta mucha preparación.
• Medio: dimensiones críticas en nivel 2 y ninguna de soporte en nivel 0. La migración es viable con refuerzos puntuales.
• Bajo: dimensiones críticas en nivel 3 o más. La migración avanza con gates incrementales.

Así se ve en un ejemplo de un sistema ficticio que estamos planificando migrar, con los puntajes de las tres dimensiones críticas (Dimensiones 1, 3 y 7):

Es el mismo sistema, con cuatro slices con perfiles de riesgo distintos y una estrategia para cada uno. A partir de ahí se puede definir la estrategia de despliegue y el roadmap.

La paradoja del monolito¶

En un monolito con mucha interdependencia aparece una paradoja: ¿se puede refactorizar con confianza, sin pruebas, para que el sistema sea testeable? Para aislar un componente y migrarlo primero hay que modificar el monolito, y para modificarlo sin perder comportamiento hacen falta pruebas que todavía no existen. La clave está en encontrar las grietas del monolito, los puntos donde se puede separar una parte y avanzar de a poco.

Siento que esta planificación por riesgo es una de las partes que queda fuera cuando la migración se plantea de forma extremadamente simplificada como darle el código a un LLM, generar las pruebas y ejecutarlas.

Enfoque 6: revisar a escala lo que genera la IA y validar con el negocio¶

Todo lo que genera la IA en una migración COBOL, desde un diagrama o un pseudocódigo hasta una prueba automatizada, necesita un esquema de verificación diseñado por el equipo. Los modelos están cada vez mejor, pero siguen alucinando.

Dos equipos, dos niveles¶

En la fintech aplicamos characterization testing en dos niveles, y cada uno tiene su propio equipo:

• Equipo funcional (end to end): documenta el comportamiento del sistema, entrevista a los usuarios, valida y actualiza la documentación y diseña casos de prueba basados en riesgo. Lo que obtenemos al consultar el código con un LLM no se toma como verdad: funciona como punto de partida para conversar con quienes conocen el negocio, que son quienes confirman si tiene sentido.
• Equipo técnico: analiza el código y los logs, entiende las limitaciones del stack (qué frameworks de automatización existen, cómo medir cobertura, qué observabilidad hay), trabaja con mapas de dependencias, árboles de ejecución, acceso a datos e integraciones, y genera y valida las pruebas automatizadas, priorizadas según el uso real del sistema.

Revisar miles de pruebas generadas¶

Entre las pruebas que genera la IA aparecen algunas sin assertions o con assertions muy débiles, otras que agregan mocks justo sobre la parte que se quiere probar y otras con datos hardcodeados. Con miles de pruebas, revisarlas una por una deja de ser humanamente posible.

Creo que ahí tenemos que pararnos un nivel más arriba: además de diseñar pruebas, diseñar un esquema escalable que nos dé tranquilidad sobre la cobertura y la calidad de las pruebas que hacemos. Para eso vuelvo a los fundamentos, como las heurísticas. Una pregunta tan simple como "¿todas estas pruebas tienen al menos una assertion?" ya permite detectar algunas de las que debemos corregir, y a partir de ahí hay que profundizar en qué hace buena a una prueba en cada sistema. Es un desafío que todavía estamos descubriendo.

Probar también a los agentes¶

Un agente es una pieza de software, así que también necesita pruebas. En Tero, las automatizamos con un enfoque de LLM como 'juez'. De esa forma, si aparece un modelo más rápido o más barato, se puede hacer el cambio y verificar que el agente sigue funcionando como se espera.

¿Dónde no te salva la IA en una migración de COBOL?¶

La IA reduce tiempos y costos en muchas partes de una migración de COBOL, pero hay desafíos que siguen dependiendo de la gestión y del criterio de las personas. Conviene tenerlos en el plan desde el primer día:

Si una IA te dice que tu migración está "completamente probada", ¿de verdad vas a apretar el botón de deploy? No creo que hoy estemos preparados para eso. La decisión de apagar el sistema viejo y encender el nuevo sigue siendo humana, y cuanto más visibles sean los riesgos y sus mitigaciones para quien la toma, más consciente será el riesgo que asume la organización.

El riesgo de una migración está determinado por tu capacidad de verificar. Si no puedes validar el comportamiento en el nuevo entorno, no puedes gobernar la migración.

Por eso, para mí, el problema de fondo de muchas migraciones es epistemológico: dónde reside el conocimiento del sistema y de dónde lo obtenemos.

Sobre el autor¶

Federico Toledo es cofundador y Chief Quality Officer de Abstracta, doctor en testing de software y trabaja en la industria del testing desde hace más de 20 años.

Es autor del primer libro de testing escrito originalmente en español, disponible de forma gratuita hoy tanto en español como en inglés, y es un impulsor de comunidades: formó parte durante muchos años de la organización de Testing Uy, creó el podcast Quality Sense y la Quality Sense Conf, y participa en espacios como TAPIA (Taller de Pruebas e Inteligencia Artificial) y WOPR (Workshop on Performance and Reliability).