Modernizar sin pausar: el problema de tocar un sistema que no se puede apagar

La mayoría de los proyectos de modernización de software tienen un lujo que casi nadie valora hasta que lo pierde: la posibilidad de romper algo. Un ambiente de staging, una ventana de mantenimiento, un margen para que algo falle mientras se corrige. Ese lujo desaparece por completo cuando el sistema que hay que modernizar es una plataforma de evaluación de riesgo crediticio, con bancos usándola activamente para tomar decisiones sobre créditos reales, todos los días.

Trabajamos hace poco con una fintech que estaba en exactamente esa situación. Su plataforma cruzaba datos transaccionales de distintos bancos con una matriz de riesgo para evaluar el perfil crediticio de cada entidad. El proceso funcionaba, pero dependía enteramente de trabajo manual: crear un assessment, dar de alta un banco, cerrar la evaluación, sacar los reportes — todo copiando y pegando datos entre sistemas, sin ningún proceso automatizado detrás. Y cuando aparecía una inconsistencia en un cálculo de riesgo, nadie la detectaba hasta que ya había afectado algo.

El desafío no era decidir qué automatizar. Eso era relativamente obvio. El desafío era cómo automatizarlo sin apagar nada en el camino.

Detectar antes de que sea una decisión

Hay una diferencia enorme entre corregir un error después de que causó un problema, y evitar que ese error llegue a convertirse en una decisión. En un sistema de evaluación de riesgo, esa diferencia no es un matiz técnico — es la diferencia entre un dato que un banco usa para decidir a quién prestarle dinero, y un dato que nunca debería haber llegado tan lejos.

Buena parte del trabajo se concentró exactamente ahí: mover la validación de los datos de un lugar reactivo a uno proactivo. En vez de esperar a que una inconsistencia apareciera en un reporte de negocio, el sistema empezó a verificarla antes, con consultas de control que corren antes y después de cada cambio. No es una automatización espectacular. Es, literalmente, adelantar el momento en el que se detecta un problema.

Modernizar de a partes, no de una vez

La otra decisión importante fue arquitectónica: en lugar de reemplazar el sistema de una vez, se construyó una arquitectura orientada a eventos que fue absorbiendo, un proceso a la vez, lo que antes era manual. Cada operación crítica —dar de alta un assessment, cerrarlo, crear un cliente— pasó a dispararse por un mensaje, no por una persona ejecutando pasos a mano. Eso permitió ir migrando el sistema pieza por pieza, sin necesitar un corte total ni una ventana de downtime para el cambio completo.

Es un patrón que vale más allá de este proyecto puntual: cuando no podés pausar un sistema, la modernización no puede ser un evento único. Tiene que ser una serie de reemplazos pequeños, cada uno reversible, cada uno verificable, que en conjunto terminan siendo una transformación completa sin que nadie afuera note el momento exacto en el que cambió.

¿Tu empresa tiene un sistema crítico que no se puede apagar para modernizarlo? Ese no es un motivo para no modernizarlo — es una razón para hacerlo distinto.