Modernización de Mainframe Heredado
Entre el 70 y el 80 % de los proyectos de modernización de mainframe fracasan. No porque la tecnología sea incorrecta, sino porque las herramientas tratan el código como texto en lugar de topología. Construimos el mapa de su base de código antes de tocar una sola línea, para que su migración tenga éxito allí donde otros han quemado millones y no han entregado nada.
1,52 billones de USD
Deuda Técnica de EE. UU.
Pragmatic Coders, 2025
10 %/año
Pérdida de Personal COBOL
IEEE Spectrum, 2025
70-80 %
Tasa de Fracaso de la Modernización
Metaanálisis del Sector, 2025
Las herramientas que prometen «pegue COBOL, obtenga Java» producen código que compila. Esa es la parte fácil. La parte difícil es el código que no pueden ver.
Considere un programa de procesamiento de transferencias electrónicas. Contiene una sentencia COMPUTE que utiliza una variable llamada TRN-LIMIT. Un asistente de codificación con IA traduce la sentencia a una operación BigDecimal de Java. El código compila. Las pruebas unitarias pasan.
En las pruebas de aceptación de usuario (UAT), la primera transacción hace fallar la verificación de coherencia de la base de datos.
La autopsia: TRN-LIMIT no estaba definida en el archivo fuente que la IA tradujo. Estaba definida en un copybook incluido miles de líneas antes en la cadena de ejecución. Ese copybook contenía una cláusula REDEFINES , una construcción de COBOL que permite que la misma dirección de memoria se interprete como dos tipos de datos diferentes según un indicador establecido en un módulo completamente distinto.
La IA vio TRN-LIMIT como un simple campo numérico y asumió un tipo entero estándar. En el mainframe, esa dirección de memoria contenía un decimal empaquetado (COMP-3). La aplicación Java escribió datos binarios corruptos en la columna de la base de datos, provocando un fallo de integridad referencial.
El código era sintácticamente perfecto. El fallo fue ceguera contextual. La IA pasó por alto una dependencia que existía fuera de su campo de visión.
Un único programa COBOL puede referenciar más de 40 copybooks. Cada copybook puede hacer COPY de otros copybooks. Las definiciones de variables pueden estar 5 niveles de profundidad en la cadena de inclusión. Las herramientas de IA basadas en texto no ven nada de esto.
Su COBOL no se ejecuta de forma autónoma. CA-7 o TWS programan entre 2000 y 5000 trabajos JCL con cadenas de dependencias. El Trabajo A escribe un conjunto de datos que el Trabajo B lee a las 2 de la madrugada. Migre el COBOL pero pase por alto el JCL, y la producción se romperá a medianoche.
El decimal empaquetado COMP-3 de COBOL no tiene equivalente en Java. Un double de Java introduce errores de redondeo de coma flotante. Incluso BigDecimal requiere la configuración explícita del modo de redondeo (HALF_EVEN) para coincidir con la cláusula ROUNDED de COBOL. Un céntimo erróneo se acumula a lo largo de millones de transacciones.
Todos los principales proveedores de tecnología venden ahora modernización de mainframe. Esto es lo que cada uno realmente entrega, y dónde permanecen las carencias.
| Proveedor / Enfoque | Qué Hace | Coste Típico | Qué Pasa por Alto |
|---|---|---|---|
| IBM Watsonx Code Assistant for Z | Traducción agéntica de COBOL a Java con análisis de dependencias ADDI. Arquitectura multiagente (agentes Orchestrate, Architect, Code). Admite PL/I e IMS. | Más de 2 M USD (licencias empresariales + requisito de z/OS) | ADDI se ejecuta en z/OS, creando dependencia del proveedor durante la migración. El analizador tiene dificultades con las construcciones de COBOL anteriores al 85 (sentencias ALTER). Sin pruebas de equivalencia de comportamiento. Sin mapeo de dependencias JCL. |
| Anthropic Claude Code | Análisis de código, documentación y mapeo de dependencias con IA. Sólido en las fases de descubrimiento y exploración. Admite migración incremental y encapsulado de API. | Precios de API basados en uso | IA de propósito general. Sin grafo de conocimiento integrado para la resolución de dependencias transitivas. No aborda la programación JCL, las pruebas de equivalencia de comportamiento ni los registros de auditoría regulatoria. |
| Microsoft Azure Migration Factory | Agentes agénticos modulares mediante Semantic Kernel. Agentes COBOL Expert + Java Expert. Apunta a Java Quarkus. Agente de migración Azure Copilot en versión preliminar. | Consumo de Azure + consultoría | Dependencia de Azure para la plataforma de destino. Los agentes de código abierto son implementaciones de referencia, no listas para producción en entornos regulados. Soporte limitado de CICS/IMS. |
| DXC Technology | Conversión automática de código patentada (COBOL/RPG/JCL a Java). Décadas de experiencia en mainframe. Modelos de nube híbrida + mainframe como servicio. | 1 M-10 M USD o más | Herramientas propietarias, transparencia limitada sobre la lógica de conversión. Enfoque en grandes empresas. Son habituales plazos de compromiso de 18 a 36 meses. |
| TCS / Infosys / Accenture | Prácticas de grandes integradores de sistemas con marcos propietarios (MasterCraft, Cobalt). Equipos de entrega masivos. Gestión de programas de extremo a extremo. | 500 K-5 M USD o más | Enfoque centrado en la plataforma. Implementan herramientas de proveedores, no construyen inteligencia personalizada. Sobrecarga del modelo de compromiso de un gran integrador de sistemas. Un integrador dirigió una migración bancaria de 1000 M AUD que tardó 5 años y duplicó su presupuesto. |
| Micro Focus (OpenText) Visual COBOL | Ejecute COBOL de forma nativa en .NET/JVM. Punto de partida pragmático de tipo «strangler fig». Líder del mercado de compiladores COBOL. | 200 K-500 K USD en licencias | No es modernización, es realojamiento. La lógica COBOL sigue siendo COBOL. La deuda técnica persiste. No resuelve el problema de la fuerza laboral. |
| DIY con IA de código abierto | LLM XMainframe (7B/10,5B parámetros, 30 % mejor que DeepSeek en COBOL). Análisis con Tree-sitter. Canalizaciones personalizadas. | Tiempo de ingeniería + infraestructura | Requiere profunda experiencia en COBOL + ingeniería de grafos. Ningún analizador COBOL de grado de producción cubre todas las construcciones de IBM Enterprise COBOL v6.x. Alto riesgo de incorporar carencias del analizador a los cimientos. |
Cinco capacidades, cada una abordando una carencia específica en la cadena de herramientas de modernización. Somos neutrales respecto al proveedor: el grafo de conocimiento funciona independientemente de si su destino es AWS, Azure, GCP o Java en las instalaciones.
Ingerimos su código fuente COBOL, copybooks, bibliotecas JCL, exportaciones del catálogo DB2, definiciones de transacciones CICS y jerarquías de segmentos IMS en una base de datos de grafos unificada. Cada variable, cada cadena PERFORM, cada cláusula REDEFINES, cada dependencia por lotes se convierte en una arista explícita del grafo. Recurrimos a Neo4j cuando las consultas complejas de cierre transitivo dominan el caso de uso, y a Memgraph cuando la velocidad de recorrido en tiempo real importa para la exploración interactiva.
El grafo procesa aproximadamente entre 200 K y 300 K líneas por día durante la ingesta. Para una base de código de 2 M de LOC, espere de 8 a 12 semanas desde la primera ingesta hasta un grafo validado y consultable. El resultado es un activo permanente: su base de código como topología consultable, no como archivos de texto opacos.
Antes de que comience cualquier traducción de código, ejecutamos un análisis de grafos en cuatro dimensiones: puntuación de acoplamiento (cuántos otros módulos dependen de este), densidad de REDEFINES/COMP-3 (cuántas trampas de tipo de datos existen), porcentaje de código muerto (normalmente entre el 20 y el 30 % de la base de código) y criticidad de la programación por lotes (qué trabajos JCL tocan este módulo y cuándo).
El resultado es una secuencia de extracción jerarquizada para la migración «strangler fig». Los módulos con el menor acoplamiento y los tipos de datos más simples se extraen primero. Los «programas dios» llamados por más de 50 otros módulos se extraen al final. Esta secuenciación es la diferencia entre un despliegue controlado y un fallo en cascada.
Nuestros agentes de traducción consultan el grafo de conocimiento antes de generar cada módulo Java, extrayendo el cierre transitivo completo de las dependencias. El agente ve la cláusula REDEFINES en el copybook situado tres directorios más allá. Ve la definición de decimal empaquetado que determina el comportamiento de redondeo. Genera Java con paso explícito de parámetros (inyección de dependencias) en lugar del estado global implícito de COBOL. Luego compila en un entorno aislado, ejecuta pruebas de equivalencia de comportamiento y se autocorrige.
Utilizamos el modelo fundacional que mejor se adapte a la complejidad del módulo. Para conversiones sencillas de PERFORM a método, un modelo más pequeño funciona bien. Para módulos con REDEFINES anidados, espagueti de GOTO que requiere aplanamiento del flujo de control o lógica de transacciones EXEC CICS integrada, incorporamos el modelo más capaz disponible y lo aumentamos con el contexto completo del grafo.
La parte que la mayoría de los proveedores omiten y en la que fracasan la mayoría de las migraciones. Construimos un sistema de validación de tres capas: pruebas unitarias simbólicas generadas a partir de rutas de flujo de control derivadas del grafo, repetición de conjuntos de datos de referencia (golden dataset) utilizando transacciones de producción capturadas, comparadas campo por campo con precisión perfecta al céntimo, y ejecuciones de producción en paralelo donde ambos sistemas procesan transacciones en vivo durante 30 a 90 días antes de desmantelar el módulo del mainframe.
Los cálculos financieros requieren BigDecimal con el modo de redondeo HALF_EVEN para coincidir con la cláusula ROUNDED de COBOL. Los cálculos de fechas requieren manejar el formato de fecha de 6 dígitos de COBOL (AAMMDD) con lógica de ventanas de siglo. Incorporamos estas reglas de conversión al arnés de pruebas, no a parches improvisados descubiertos durante el control de calidad.
Analizamos sus redes de trabajos JCL, las cadenas de dependencias CA-7/TWS/Control-M y las secuencias de procesamiento por lotes para incorporarlas al grafo de conocimiento. Cada trabajo JCL se convierte en un nodo con aristas hacia los programas COBOL que ejecuta, los conjuntos de datos que lee y escribe, y las condiciones de programación de las que depende (disparadores temporales, disponibilidad de conjuntos de datos, finalización del predecesor).
Cuando un módulo COBOL migra a Java, simultáneamente construimos la programación equivalente en su plataforma de orquestación de destino (Apache Airflow, AWS Step Functions, Azure Data Factory o Control-M en entorno distribuido). La cadena de dependencias se preserva y verifica frente a la definición CA-7/TWS original. Un banco típico de nivel medio tiene entre 2000 y 5000 trabajos JCL. Los hemos visto todos.
Un recorrido paso a paso de cómo la resolución de dependencias basada en grafos previene el patrón de fracaso de migración más común.
El analizador procesa PROG-WIRE-01.cbl, encuentra COPY CB-ACCT-LIMITSy sigue la cadena de inclusión. Construye nodos AST para cada declaración de variable, incluidas las que están en copybooks anidados a 3 niveles de profundidad.
El motor de grafos crea aristas: PROG-WIRE-01 → IMPORTS → CB-ACCT-LIMITS. TRN-LIMIT → REDEFINES → TRN-LIMIT-ALPHA. LIMIT-TYPE-FLAG → CONTROLS_TYPE_OF → TRN-LIMIT. Esto captura el hecho de que el tipo de datos de TRN-LIMIT depende de un indicador en tiempo de ejecución en un campo diferente.
El grafo recorre hacia afuera: ¿qué otros programas también hacen COPY de CB-ACCT-LIMITS? ¿Qué programas establecen LIMIT-TYPE-FLAG? ¿Qué trabajos JCL ejecutan esos programas, y en qué secuencia? El resultado es una cadena de impacto completa. Cambiar cómo se traduce TRN-LIMIT afecta a todos los programas de esta cadena.
Cuando el agente de traducción procesa PROG-WIRE-01, GraphRAG recupera no solo el archivo fuente, sino también la definición del copybook, la relación REDEFINES, el campo del indicador y todos los programas que establecen el indicador. El agente genera una clase Java con un patrón de unión con seguridad de tipos: un objeto TransactionLimit que comprueba el indicador antes de interpretar los bytes subyacentes como un BigDecimal (modo decimal empaquetado) o una String (modo alfanumérico).
Sin el grafo: la IA asume que TRN-LIMIT es un simple campo numérico, genera un long en Java, y la primera transferencia electrónica corrompe la base de datos. Con el grafo: la IA ve la cadena de dependencias completa y genera código con seguridad de tipos que maneja ambas interpretaciones correctamente. Esta es la diferencia entre una migración que funciona en UAT y una que funciona en producción.
Cuatro fases, cada una con entregables claros. No cotizamos un plazo de 3 años y desaparecemos. Cada fase produce artefactos que usted posee y puede utilizar de forma independiente.
Entregable: Informe de Evaluación + prototipo preliminar del grafo de conocimiento
Entregable: Grafo de conocimiento consultable + secuencia de extracción jerarquizada + herramienta de análisis de impacto
Entregable: Módulos Java migrados en producción + grafo de conocimiento actualizado + equivalentes de programación
Entregable: Despliegue en producción validado + paquete de documentación regulatoria + grafo actualizado
Responda siete preguntas sobre su entorno. La evaluación identifica su nivel de preparación y los obstáculos específicos que debe abordar antes de iniciar un compromiso de migración, con o sin Veriprajna.
Para una base de código de 2 M de LOC con complejidad típica (IBM Enterprise COBOL v6.x, SQL embebido de DB2, más de 500 copybooks), la construcción del grafo lleva de 8 a 12 semanas. Las primeras 3 semanas son de configuración y validación del analizador. Los dialectos de COBOL varían lo suficiente como para que necesitemos verificar que el analizador maneja su uso específico de REDEFINES, OCCURS DEPENDING ON y bloques EXEC CICS/SQL antes de ingerir la base de código completa.
De la semana 4 a la 8 se realiza la ingesta automatizada, la extracción de entidades y el mapeo de relaciones. El analizador procesa aproximadamente entre 200 K y 300 K líneas por día, pero el cuello de botella es la resolución de entidades, específicamente determinar que ACCT-NUM en el Programa A y ACCT-NUM en el Copybook CB-ACCT-01 son la misma variable.
De la semana 9 a la 12 se realiza el cálculo del cierre transitivo y la validación. Ejecutamos comprobaciones de completitud del grafo: cada objetivo PERFORM debe resolverse en un párrafo, cada sentencia COPY debe resolverse en un copybook, cada referencia a una tabla DB2 debe mapearse a una definición de esquema. Las lagunas se marcan para revisión manual. El resultado es un grafo de conocimiento consultable donde puede hacer preguntas como «¿Qué ocurre si cambio INTEREST-RATE en CB-GLOBAL-01?» y obtener una cadena de impacto completa a través de cada programa que lo referencia, directa o transitivamente.
Sí, y lo recomendamos encarecidamente. El patrón «strangler fig» es el único enfoque con un historial probado para la migración de mainframe. Las reescrituras completas fracasan entre el 70 y el 80 % de las veces porque intentan reemplazar todo simultáneamente, creando un único punto de fallo masivo.
Con el enfoque «strangler fig», el grafo de conocimiento identifica qué módulos tienen las puntuaciones de acoplamiento más bajas, es decir, menos dependencias entrantes de otros módulos. Estos son sus candidatos para la extracción. Normalmente empezamos con módulos de informes por lotes o rutinas de cálculo independientes que leen de DB2 pero no actualizan el estado compartido. El nuevo servicio Java se ejecuta junto al mainframe. El tráfico de producción se redirige al nuevo servicio para esa función específica mientras el mainframe sigue gestionando todo lo demás. Usted valida la equivalencia de comportamiento con datos de producción reales antes de desmantelar el módulo COBOL.
La mayoría de las organizaciones extraen entre 15 y 20 módulos en el primer año, reduciendo el consumo de MIPS entre un 20 y un 30 % y generando suficiente ahorro de costes para financiar la siguiente fase. El grafo de conocimiento hace que esto sea seguro porque le muestra el radio de impacto de cada extracción. Si el Módulo A es llamado por otros 47 programas, ese no es su primer candidato para la extracción. Si el Módulo B es llamado por 2 programas y lee de 1 tabla DB2, empiece por ahí.
Esta es la capa donde la mayoría de los proyectos de modernización sufren fallos inesperados a los 6 o 12 meses. Sus programas COBOL no se ejecutan de forma aislada. Están orquestados por flujos de trabajos JCL gestionados por CA-7, TWS (Tivoli Workload Scheduler) o Control-M. Un banco típico de nivel medio tiene entre 2000 y 5000 trabajos JCL con cadenas de dependencias complejas: el Trabajo A debe completarse antes de que comience el Trabajo B, el Trabajo C se ejecuta solo el último día hábil del mes, el Trabajo D dispara una transacción CICS que actualiza un archivo VSAM leído por el Trabajo E.
Analizamos el JCL junto con el COBOL en el mismo grafo de conocimiento. Cada trabajo JCL se convierte en un nodo con aristas hacia los programas COBOL que ejecuta, los conjuntos de datos que lee y escribe, y las condiciones de programación de las que depende. Cuando migramos un módulo COBOL a Java, simultáneamente construimos la programación equivalente en su plataforma de destino, ya sea Apache Airflow, AWS Step Functions o Azure Data Factory. La cadena de dependencias se preserva y verifica frente a la original.
Hemos visto proyectos donde la migración del código tuvo un éxito perfecto pero la producción se rompió porque nadie mapeó el trabajo CA-7 que ejecutaba un paso de preprocesamiento cada noche a las 2 de la madrugada.
IBM Watsonx Code Assistant for Z (actualmente v2.8.20, con Project Bob llegando más adelante en 2026) es un producto sólido con una profunda integración con el mainframe. Requiere IBM ADDI (Application Discovery and Delivery Intelligence) para construir su análisis de dependencias, y ADDI se ejecuta en z/OS. Esto significa que sus herramientas de análisis de dependencias residen en el mismo mainframe del que está intentando migrar. También significa que IBM controla la capa de análisis, lo que crea dependencia del proveedor durante la fase más crítica de la migración.
Nuestro grafo de conocimiento se ejecuta fuera del mainframe. Ingerimos exportaciones de código fuente, bibliotecas JCL, exportaciones del catálogo DB2 y repositorios de copybooks. El grafo reside en su entorno de nube o infraestructura en las instalaciones, independiente de las licencias de IBM. En segundo lugar, Watsonx se centra en la traducción de COBOL a Java. Nosotros nos centramos primero en la comprensión, y en segundo lugar en la traducción. El grafo de conocimiento es un activo permanente que sirve para el análisis de impacto, la generación de documentación y la gobernanza arquitectónica mucho después de que la migración haya finalizado.
En tercer lugar, el analizador COBOL de ADDI tiene limitaciones documentadas con las construcciones de COBOL anteriores al 85, en particular las sentencias ALTER y ciertos patrones REDEFINES anidados. Nosotros construimos extensiones personalizadas del analizador para el dialecto de cada cliente.
Por último, los precios de IBM están dirigidos a grandes empresas. Nuestro modelo de compromiso funciona para instituciones de nivel medio donde un compromiso con IBM de más de 2 M USD no está en el presupuesto.
La equivalencia de comportamiento es donde se desmoronan la mayoría de las migraciones asistidas por IA. El código que compila y pasa las pruebas unitarias puede aun así producir resultados erróneos debido a diferencias de redondeo de decimal empaquetado, discrepancias de codificación de EBCDIC a ASCII o semánticas de superposición de memoria de REDEFINES que no se traducen a objetos Java.
Construimos un arnés de validación de tres capas. La Capa 1 es la equivalencia simbólica: generamos pruebas unitarias a partir del grafo de conocimiento que cubren cada rama del flujo de control COBOL original, incluidos casos límite como importes negativos, protecciones contra división por cero y cálculos de fechas de años bisiestos. La Capa 2 es la repetición del conjunto de datos de referencia (golden dataset): capturamos un conjunto representativo de transacciones de producción del mainframe (registros de entrada, lecturas de DB2, interacciones CICS) y las repetimos a través del nuevo servicio Java. Las salidas se comparan campo por campo. Para los cálculos financieros, verificamos la precisión perfecta al céntimo utilizando BigDecimal con redondeo HALF_EVEN para coincidir con el comportamiento de la cláusula ROUNDED de COBOL.
La Capa 3 es la ejecución de producción en paralelo: ambos sistemas procesan las mismas transacciones en vivo simultáneamente durante 30 a 90 días. Las discrepancias se registran, investigan y corrigen antes de desmantelar el módulo del mainframe. Esta es la fase más larga, pero también es la fase que detecta los casos límite acumulados durante 30 años de producción que ninguna suite de pruebas puede anticipar por completo.
DORA (Ley de Resiliencia Operativa Digital) está plenamente en vigor desde el 17 de enero de 2025, y afecta directamente a cualquier entidad financiera regulada por la UE que opere sistemas de mainframe. El Artículo 11 exige marcos de gestión de riesgos de TIC que incluyan pruebas de resiliencia periódicas y pruebas de penetración basadas en amenazas según escenarios de ataque del mundo real. La mayoría de los entornos de mainframe no fueron diseñados para este tipo de pruebas. No puede levantar fácilmente un entorno z/OS replicado para ejecutar pruebas de penetración sin costes significativos de licencias e infraestructura.
DORA también exige inventarios detallados de activos de TIC, notificación de incidentes dentro de plazos específicos y gestión de riesgos de terceros para los proveedores críticos de servicios de TIC, lo que incluye a su proveedor de mainframe. La modernización ayuda de dos maneras. En primer lugar, el propio grafo de conocimiento sirve como el inventario de activos de TIC que DORA exige. Mapea cada programa, cada flujo de datos, cada dependencia externa. Los reguladores pueden consultarlo directamente.
En segundo lugar, los componentes migrados que se ejecutan en infraestructura de nube son intrínsecamente más fáciles de someter a pruebas de resiliencia. Puede levantar entornos de prueba bajo demanda, ejecutar escenarios de ingeniería del caos y validar procedimientos de recuperación sin afectar a la producción. Hemos visto instituciones utilizar el grafo de conocimiento como evidencia en exámenes regulatorios para demostrar que comprenden su patrimonio tecnológico, incluso antes de que la migración esté completa.
La metodología detrás de esta página de solución se fundamenta en nuestra investigación publicada sobre modernización de sistemas heredados y arquitecturas de grafos de conocimiento.
Cómo los grafos de conocimiento conscientes del repositorio y GraphRAG superan el síndrome «Lost in the Middle» que provoca que la traducción de código con IA falle en los sistemas COBOL empresariales.
Una reducción del 20-30 % de MIPS en el Año 1 normalmente ahorra entre 500 K y 2 M USD anuales para una institución de nivel medio.
La evaluación del grafo de conocimiento lleva de 4 a 6 semanas. Obtiene un mapa de dependencias completo de su base de código, un informe de código muerto y una secuencia de extracción jerarquizada, tanto si procede con la migración como si no. La evaluación en sí misma es un activo permanente.