Sistemas legacy en banca: cuándo migrar, cuándo encapsular y cuándo no tocar nada

Cuando un CIO de un banco tradicional dice que tiene un "problema de legacy", casi siempre está describiendo tres problemas distintos mezclados en uno. El primero es el riesgo operativo: sistemas que nadie entiende del todo, que ningún proveedor soporta, y cuyo único custodio es alguien que se jubila en dos años. El segundo es el costo de oportunidad: la imposibilidad de integrar capacidades nuevas —Open Finance, detección de fraude con IA, onboarding digital— porque la arquitectura no lo permite sin cirugía mayor. El tercero es la deuda técnica acumulada: parches sobre parches que hacen que cualquier cambio, por pequeño que sea, requiera semanas de testing y coordinación entre equipos.

El error más frecuente es tratar los tres problemas como si fueran el mismo. De ese error nace la decisión equivocada: o se congela todo porque "no es el momento de migrar", o se lanza una modernización masiva que termina paralizando el negocio durante meses. Entre esos dos extremos existe una tercera vía, y para encontrarla hay que empezar por hacer la pregunta correcta: ¿qué problema concreto estoy tratando de resolver?

Hay básicamente tres formas de manejar un sistema legacy. Cada una tiene condiciones de aplicación distintas, y ninguna es universalmente mejor que las otras.

Reemplazar significa construir o adquirir un sistema nuevo y migrar la funcionalidad del viejo. Es la opción con mayor retorno potencial y mayor riesgo de ejecución. Tiene sentido cuando el sistema actual bloquea capacidades de negocio estratégicamente críticas, cuando el costo de mantenimiento supera el costo proyectado de migración, o cuando el talento para sostenerlo está desapareciendo. Lo que no tiene sentido es reemplazar por razones estéticas —"el código es viejo y feo"— o porque un vendor tiene un producto nuevo que parece atractivo.

Encapsular significa construir una capa de abstracción alrededor del sistema existente —típicamente una API— sin tocar el núcleo. El sistema legacy sigue corriendo, pero el resto de la arquitectura interactúa con él a través de una interfaz moderna. Esta estrategia es la correcta cuando el sistema hace bien lo que tiene que hacer pero necesita exponerse a canales o integraciones nuevas, o cuando el riesgo de un reemplazo es demasiado alto en el corto plazo.

No tocar nada es una decisión legítima, no una evasión. Tiene sentido cuando el sistema funciona correctamente dentro de su dominio y cuando el costo y el riesgo de cualquier intervención superan el beneficio. El error no es decidir no tocar: el error es no decidirlo explícitamente. La inercia no es una estrategia; la estabilidad deliberada sí lo es.

La unidad de decisión no es "el sistema legacy", sino cada componente de ese sistema evaluado por separado.

En una migración que hicimos para una startup de servicios fiscales en LATAM —con un volumen de operaciones que no toleraba ni una hora de interrupción— la decisión no fue reemplazar todo de una vez. Fue reemplazar por capas, en un orden dictado por el riesgo: primero los componentes de menor criticidad operativa, luego los de mayor complejidad de integración, y finalmente el núcleo transaccional. El resultado fue una plataforma serverless en AWS con cero downtime durante la migración, una reducción del 90% en costos operativos, y más de 25.000 usuarios activos hoy.

Lo que esa experiencia confirmó es algo que parece obvio pero que pocas veces se aplica con disciplina: tratar al sistema como un bloque monolítico —para bien o para mal— es casi siempre el error más caro. Un core bancario puede tener módulos que merecen reemplazo inmediato, módulos que conviene encapsular por ahora, y módulos que no vale la pena tocar en dos años.

La razón por la que muchas instituciones financieras no avanzan no es falta de voluntad ni de presupuesto. Es falta de claridad sobre dónde está exactamente el problema. Antes de decidir qué estrategia aplicar, hay que saber qué sistemas existen, cuál es el estado real de cada uno, dónde están los cuellos de botella, y qué dependencias existen entre ellos. Sin ese mapa, cualquier decisión —migrar, encapsular, o no tocar— se toma a ciegas.

Ese diagnóstico no tiene que durar meses. Un assessment bien estructurado puede dar claridad suficiente para priorizar en pocas semanas, y cambia completamente la conversación que después se tiene con el directorio.

¿No sabés en qué estadio está tu infraestructura? Hacemos el diagnóstico.

‍