Desacoplar un Sistema Crítico sin Detener la Operación: El Plan de Rollback que Nos Salvó

En los proyectos de modernización tecnológica hay una frase que todos quieren escuchar: "La transición fue transparente para el cliente."

Suena simple. Pero quienes hemos trabajado en proyectos donde se desacoplan sistemas críticos de una operación financiera sabemos que detrás de esa frase hay semanas —a veces meses— de planificación, pruebas, discusiones técnicas, validaciones funcionales, noches largas y decisiones difíciles.

Porque modernizar un sistema legacy que está integrado al core no es solamente reemplazar una aplicación. Es intervenir una pieza viva de la operación sin que el negocio deje de funcionar.

En uno de esos proyectos aprendimos una lección fundamental: el éxito de una modernización no depende únicamente del plan para avanzar. Depende también de la madurez del plan para regresar.

El proyecto: desacoplar un sistema crítico integrado al core

El objetivo era claro: desacoplar un sistema crítico de créditos que durante años había operado como parte del ecosistema legacy de una entidad financiera. Era una pieza que participaba en flujos sensibles del negocio: originación, consultas, validaciones, estados, saldos, integraciones y procesos posteriores relacionados con la operación crediticia.

Había que rediseñar el sistema, construir una nueva solución, integrar correctamente con los componentes necesarios, migrar información, validar consistencia y, finalmente, trasladar la operación hacia la nueva plataforma sin interrumpir el servicio.

Cuando desacoplar no significa simplemente apagar y encender

Una de las mayores complejidades de desacoplar un sistema legacy integrado al core es que la operación no se detiene para esperarnos. Los créditos siguen consultándose. Los procesos siguen ejecutándose. Los usuarios siguen trabajando. Los clientes siguen esperando respuestas.

El verdadero desafío está en que el nuevo sistema funcione bien dentro del ecosistema completo: validar integraciones, reglas de negocio, datos históricos, procesos de conciliación, reportes, permisos, roles, tiempos de respuesta y comportamientos operativos que muchas veces no están documentados, pero que el negocio conoce porque los vive todos los días.

El susto a mitad de camino

La migración operativa inició según lo planificado. Los primeros pasos fueron avanzando bien. Hasta que apareció una señal que no esperábamos: una diferencia pequeña, pero relevante, en uno de los procesos de validación y conciliación entre el nuevo sistema de créditos y la operación esperada.

En ese momento, el ambiente cambió. Porque en una modernización crítica, el problema técnico es solo una parte del problema. La otra parte es emocional. La presión sube. La tentación de "seguir un poco más" se vuelve fuerte, especialmente cuando ya se ha avanzado bastante.

El momento en que el rollback dejó de ser teoría

El plan de rollback no apareció como una reacción improvisada. Ya existía. Ya había sido conversado. Ya tenía pasos, responsables, condiciones y tiempos. El equipo había insistido en tener criterios claros: qué tipo de diferencia justificaba detener la transición, hasta qué punto se podía investigar sin aumentar el riesgo, qué datos debían preservarse, qué procesos debían congelarse temporalmente, quién tomaba la decisión final y cuánto tiempo real tenían para ejecutar el regreso sin afectar al negocio.

En lugar de entrar en pánico, el equipo ejecutó el protocolo. Se detuvo el avance, se validó el punto de control, se protegió la información generada, se restauraron los componentes necesarios y se regresó la operación al flujo anterior. La operación continuó. Los usuarios no tuvieron que vivir el problema. El negocio no se detuvo.

Y el equipo ganó algo más valioso que una transición exitosa en el primer intento: ganó confianza. La conversación cambió de "fallamos" a "el control funcionó". Ese matiz es enorme.

Un buen rollback no es señal de debilidad

En muchos proyectos de transformación digital, la narrativa suele enfocarse en avanzar rápido. Pero en sistemas críticos —como plataformas de créditos, pagos digitales, billeteras, ERPs o procesos transaccionales conectados al core— avanzar rápido sin capacidad de reversa puede ser una imprudencia.

Un buen plan de rollback no significa que el equipo no confía en su trabajo. Significa que entiende la responsabilidad del sistema que está tocando. Que respeta la operación. Que sabe que la tecnología no existe aislada, sino conectada al negocio, a los usuarios y a la continuidad del servicio.

Los tres componentes de un buen plan de modernización

Los mejores proyectos de desacoplamiento y modernización tienen tres componentes igual de importantes: (1) El plan para avanzar: la secuencia técnica, los pasos de transición, las ventanas, las dependencias, las integraciones y los responsables. (2) El plan para validar: los controles de datos, los indicadores operativos, las pruebas funcionales, los puntos de decisión y la observabilidad. (3) El plan para regresar: el rollback documentado, probado, con tiempos claros, responsables definidos y criterios objetivos de activación.

El tercer punto muchas veces se subestima. Hasta que se necesita.

La confianza también se diseña

A veces pensamos que la confianza en los equipos se construye solamente con liderazgo, comunicación o cultura. Pero en proyectos tecnológicos complejos, la confianza también se diseña desde la arquitectura, desde la metodología y desde la gestión del riesgo. Un equipo confía más cuando sabe que hay claridad, cuando los roles están definidos, cuando puede decir "paremos" sin que eso se interprete como fracaso.

En WAU, esta ha sido una de las lecciones más importantes en proyectos de modernización: la visión estratégica marca el rumbo, pero el detalle operativo protege el camino. Y cuando ambos niveles trabajan juntos, los proyectos no solo avanzan mejor, sino que construyen mayor confianza entre todos los involucrados.

La segunda ejecución

Después del análisis, se corrigió la causa raíz, se ajustaron validaciones adicionales y se fortaleció el proceso. La segunda ejecución fue distinta. No porque el proyecto fuera más sencillo, sino porque el equipo tenía una experiencia compartida: ya había enfrentado un momento difícil y el proceso había respondido.

Y esta vez, la transición avanzó correctamente. Sin detener la operación. Sin afectación visible para los usuarios. Sin épica innecesaria. Solo con preparación, disciplina y trabajo en equipo.

El rollback no es el enemigo del avance. Es una de las razones por las que podemos avanzar con confianza. Y en transformación digital, esa confianza es tan importante como la tecnología misma.

¿Qué experiencias han tenido ustedes desacoplando sistemas críticos? ¿Han vivido algún momento en el que un buen plan de contingencia cambió por completo el resultado de un proyecto?