Es una paradoja que sorprende a quien recién entra a trabajar con sistemas bancarios: el software que procesa las transacciones más críticas de un banco —cuentas, préstamos, movimientos— con frecuencia no está escrito en el lenguaje de moda del momento, sino en RPG o COBOL, corriendo sobre un AS/400 (hoy IBM i) que lleva décadas en producción. Y con frecuencia, funciona mejor de lo que el prejuicio contra "lo viejo" sugiere.
Por qué siguen ahí
No es inercia, o no solo. Estos sistemas llevan décadas procesando transacciones reales, lo que significa décadas de errores encontrados y corregidos en el camino. RPG y COBOL fueron diseñados para exactamente este tipo de carga: procesamiento transaccional de alto volumen, con requisitos estrictos de integridad. Reescribir ese comportamiento desde cero no es solo un ejercicio de traducción de sintaxis; es reconstruir décadas de reglas de negocio que muchas veces no están documentadas en ningún otro lugar más que en el propio código.
El verdadero riesgo no es el lenguaje, es el conocimiento
El riesgo real de estos sistemas no es técnico, es humano: hay cada vez menos profesionales jóvenes que aprenden RPG o COBOL, y quienes conocen a fondo esos sistemas se van acercando al retiro. Un sistema bien escrito en un lenguaje "viejo" pero bien entendido es menos riesgoso que un sistema moderno que nadie en el equipo comprende del todo. Por eso, en mi experiencia, la prioridad de modernización no siempre es reemplazar el lenguaje —es documentar, transferir conocimiento, y construir una capa de pruebas alrededor del comportamiento actual antes de tocar nada.
Modernizar sin apagar el motor
El enfoque que mejor me ha funcionado no es la reescritura total, sino el patrón conocido como "strangler fig": envolver el sistema core con una capa de APIs que expone sus funciones de forma moderna, mientras el núcleo sigue corriendo intacto. Los nuevos canales —banca móvil, integraciones con terceros, analítica— se construyen contra esa capa, no contra el sistema legado directamente. Con el tiempo, se puede ir migrando funcionalidad específica hacia arquitecturas más nuevas, módulo por módulo, sin apostar la operación completa del banco a una migración de una sola vez.
La pregunta correcta casi nunca es "¿cuándo reemplazamos COBOL?". Es "¿qué tan bien entendemos lo que este sistema realmente hace, y qué tan preparados estamos para tocarlo con seguridad?".