32 años de COBOL y el momento en que todo cambió
El detonador fue DORA. La guía del Banco de España sobre continuidad operativa exigía acreditar la capacidad de recuperación ante un fallo catastrófico en menos de 4 horas. El banco no podía acreditarlo. Su sistema de crédito promotor — préstamos a promotores inmobiliarios, financiación de suelo, certificaciones de obra — llevaba corriendo en un mainframe IBM z/OS desde 1994.
2,1 millones de líneas de COBOL. 847 programas. Documentación funcional que cubría menos del 15% del código. Cuatro generaciones de programadores ya jubilados. El soporte IBM representaba el 31% del presupuesto total de TI. Y ya lo habían intentado antes: proyecto de migración manual, 30 meses de alcance, cancelado a los 18 meses porque los analistas no lograban capturar la lógica de negocio oculta en el COBOL.
La arqueología regulatoria: lo que nadie esperaba encontrar
En la Fase 0, un agente de análisis con Claude en Bedrock procesó todo el repositorio COBOL en AWS CodeCommit. Para cada programa generó: descripción funcional en lenguaje natural, mapa de dependencias, inventario de tablas DB2 y casos de prueba. Luego ejecutó esos casos de prueba contra el programa COBOL real para verificar que sus predicciones eran correctas.
En 6 semanas, el primer mapa funcional completo del sistema en 32 años.
Pero lo más valioso no fue la velocidad. Fue lo que encontró: 23 bloques de código con reglas de negocio no documentadas que habrían sido omitidos en cualquier migración manual. Uno de ellos aplicaba una corrección especial a las provisiones de préstamos a promotores en situación concursal con garantía hipotecaria sobre vivienda protegida. Nadie en el banco sabía que esa lógica existía. Si hubiera sido omitida, el banco habría incumplido la circular de provisiones del Banco de España sin saberlo. Ahora llaman a este proceso "arqueología regulatoria".
Kiro: por qué el spec-driven development cambia el mainframe modernization
El cuello de botella histórico en los proyectos de Mainframe Modernization no es escribir el código nuevo. Es entender qué hace el código viejo. Con el análisis agéntico resuelto, el equipo tiene por primera vez un contexto completo para trabajar. Ahí es donde entra Kiro.
El flujo: el arquitecto define el componente a modernizar → Kiro genera tres documentos estructurados (requisitos con criterios de aceptación, diseño con arquitectura y modelo de datos, plan de tareas ordenado) usando el steering file que contiene el análisis COBOL completo y las 23 reglas críticas → el equipo valida las specs → Kiro propone implementación en Python/FastAPI → validación contra los casos de prueba generados del COBOL original.
La diferencia con GitHub Copilot o Cursor: Kiro no genera código directamente desde el prompt. Primero genera las especificaciones. En proyectos de modernización, esas specs son la documentación funcional que el proyecto nunca consiguió producir manualmente. Velocidad medida: 3,5x superior al desarrollo tradicional en los módulos completados.
El problema del decimal que casi arruina la migración
Detectamos divergencias entre mainframe y sistema nuevo en el 0,3% de las transacciones — ~15 diarias. El origen: diferencias de precisión decimal entre COBOL y PostgreSQL.
COBOL usa aritmética COMP-3 (packed decimal) que representa los números exactamente. Python y Java usan IEEE 754 (punto flotante binario): 0.1 + 0.2 = 0.30000000000000004. En cálculos de intereses y certificaciones de obra, los errores se acumulan. Solución: tipo NUMERIC en Aurora PostgreSQL para todos los campos financieros, que usa aritmética decimal exacta equivalente al COMP-3 de COBOL. Suena trivial. En producción, ignorarlo habría generado discrepancias contables reales.
El CISO bloqueó el flujo: cómo lo resolvimos
El código fuente COBOL contenía referencias a datos de clientes. El equipo de seguridad preguntó: ¿los datos que pasan por Claude en Bedrock salen de nuestro entorno? La respuesta de AWS (no salen de la cuenta del cliente, no se usan para entrenamiento) fue condición necesaria pero no suficiente.
Implementamos adicionalmente: análisis estático del COBOL para identificar y enmascarar referencias a datos personales antes de enviarlo al modelo, VPC endpoint privado para todas las llamadas a Bedrock (el tráfico nunca sale a internet), y logging completo de todos los prompts y respuestas para auditoría del CISO. Eso fue lo que desbloqueó la aprobación.
Estado actual y lo que viene
4 de los 14 dominios funcionales ya están en producción en paralelo con el mainframe. Cero incidencias críticas en 7 meses. El 94% del sistema está documentado por primera vez en 32 años. El equipo comercial de crédito promotor está usando esa documentación para identificar mejoras de negocio que quieren incorporar en el sistema nuevo — algo que nunca habría ocurrido sin el análisis agéntico.
Fecha estimada de apagado del mainframe: Q2 2027. Ahorro anual en licencias y soporte IBM: 2,8M€.
La lección central para arquitectos y CTOs
Los proyectos de Mainframe Modernization no fallan porque sea difícil escribir código moderno. Fallan porque es imposible documentar 30 años de lógica de negocio oculta en COBOL con analistas humanos a tiempo y presupuesto razonables. Los agentes de análisis resuelven exactamente ese problema. Kiro multiplica la velocidad del equipo que trabaja con esa documentación. El resultado es un proyecto que avanza 3,5x más rápido con la misma certeza que antes era inalcanzable.