Cómo modernizar un sistema legacy sin detener la operación

La forma de modernizar un sistema legacy sin detener la operación es no reemplazarlo de una vez: se audita el sistema, se prioriza por riesgo y retorno, y se reemplaza por partes usando el patrón strangler fig, midiendo resultados concretos en cada sprint. El rewrite big-bang — apagar el sistema viejo un viernes y prender el nuevo un lunes — es la estrategia que más fracasa, y suele fracasar caro. Este artículo explica por qué, y qué hacer en su lugar, en términos de negocio y no solo de ingeniería.

Está escrito para gerentes de TI y gerentes generales que conviven con un sistema que sostiene la operación, que nadie quiere tocar, y cuyo autor original probablemente ya no está en la empresa.

¿Por qué falla el rewrite big-bang?

Reescribir todo desde cero suena limpio y definitivo. En la práctica concentra tres problemas que hemos visto repetirse durante más de 10 años haciéndonos cargo de sistemas construidos por otros:

• Riesgo concentrado en un solo día. Meses (o años) de inversión se apuestan a una migración única. Todo lo que pueda salir mal, sale mal el mismo día, con la operación completa arriba. No hay plan B intermedio: o funciona todo, o se revierte todo.
• Doble mantención. Mientras se construye el sistema nuevo, el viejo sigue vivo y sigue cambiando, porque el negocio no se detiene a esperar. Cada regla nueva se implementa dos veces — o el sistema nuevo nace desactualizado el día del estreno.
• La trampa de la paridad de funcionalidades. "El nuevo tiene que hacer todo lo que hace el viejo." Suena razonable, pero el viejo acumula 10 o 15 años de reglas, muchas que ya nadie usa y algunas que nadie sabe explicar. Perseguir paridad total convierte el proyecto en una meta móvil que nunca se alcanza — y mientras tanto, el sistema nuevo no genera un peso de valor hasta el final.

La consecuencia típica no es técnica sino financiera: proyectos de reescritura que se cancelan a mitad de camino, después de haber pagado lo más caro y antes de haber recibido nada.

¿Cuál es la alternativa al rewrite?

Modernización incremental. Tres piezas, en este orden:

1. Auditoría y mapa de riesgo por ROI

Antes de decidir qué construir, hay que saber qué hay. Una auditoría de código, infraestructura y dependencias produce un mapa honesto: qué módulos se caen, cuáles son lentos, cuáles son caros de cambiar y cuáles sostienen el valor del negocio. Cruzando riesgo operacional con valor de negocio sale un orden de reemplazo defendible en un directorio — no una lista de deseos técnicos. Y una conclusión frecuente e incómoda: hay módulos que conviene dejar quietos.

2. El patrón strangler fig, en términos de negocio

El nombre viene de una higuera que crece alrededor de un árbol hasta reemplazarlo. Aplicado a sistemas: se instala una fachada (un proxy o API gateway) frente al sistema viejo, y módulo por módulo se va redirigiendo el tráfico hacia componentes nuevos. El sistema viejo sigue operando todo lo que aún no se migra.

Lo que esto significa para el negocio:

• La operación nunca se detiene. No hay día D, no hay fin de semana de migración, no hay "recen para que funcione el lunes".
• Cada módulo migrado genera valor de inmediato, en vez de esperar al final del proyecto.
• El proyecto se puede pausar en cualquier punto — por presupuesto, por prioridades — y todo lo avanzado queda funcionando en producción. Intenta hacer eso con un rewrite a mitad de camino.

3. Wins medibles en cada sprint

La modernización no se reporta con porcentajes de avance en una Gantt, sino con métricas operacionales que mejoran sprint a sprint:

Si en un mes de trabajo ninguna de estas métricas se movió, es legítimo preguntar por qué. Esa transparencia es la diferencia entre modernizar y facturar. Un ejemplo del impacto posible: tras modernizar la plataforma de un cliente del rubro turismo, sus ventas de e-commerce crecieron más de 80%.

¿Cómo decidir qué reemplazar primero?

La secuencia importa tanto como el patrón. Los criterios que usamos en modernización de sistemas legacy:

1. Dolor alto, acoplamiento bajo primero. Módulos que fallan seguido o frenan al equipo, pero que tienen bordes claros con el resto del sistema. Son el mejor primer win: impacto visible, riesgo contenido.
2. Frecuencia de cambio. Un módulo que el negocio pide modificar todos los meses paga su modernización rápido. Uno que no se toca hace tres años puede esperar.
3. El corazón, al final. El núcleo del sistema — facturación, inventario, el proceso que es el negocio — se migra cuando el equipo ya tiene el método probado en zonas de menor riesgo.
4. Lo muerto se apaga, no se migra. La auditoría siempre encuentra funcionalidades sin uso. Migrarlas es pagar dos veces por algo que nadie necesita.

El resultado es una matriz simple por módulo: reemplazar, envolver (dejarlo detrás de una API moderna sin reescribirlo), dejar quieto o apagar.

¿Qué se hace cuando el sistema no tiene tests?

Es el caso normal, no la excepción. La herramienta son los tests de caracterización: en lugar de escribir pruebas de lo que el sistema debería hacer, se escriben pruebas que capturan lo que hace hoy, incluidas sus rarezas. Es como fotografiar cada pared antes de remodelar la casa: si un cambio altera el comportamiento observable, la prueba avisa antes de que lo note un cliente.

Para salidas complejas — reportes, cálculos de precios, interfaces con otros sistemas — se usa la variante golden master: se guarda la salida actual completa y se compara automáticamente después de cada cambio. Con esa red de seguridad, el código que "nadie quiere tocar" se vuelve código que se puede tocar con riesgo controlado. Sin ella, cada modificación es una apuesta.

¿Cómo se transfiere el conocimiento al equipo interno?

Modernizar sin transferir conocimiento es cambiar un lock-in por otro: antes dependías de un sistema que nadie entendía, ahora dependes del proveedor que entiende el nuevo. Para evitarlo, la transferencia se trabaja durante el proyecto, no como un manual entregado al final:

• Trabajo en pares entre nuestro equipo y el tuyo en los módulos críticos.
• Decisiones documentadas (qué se decidió, por qué, qué alternativas se descartaron), no solo código comentado.
• Demos semanales donde el avance se muestra funcionando, con el equipo interno presente.
• Revisión de código compartida, para que tu equipo conozca el sistema nuevo antes de heredarlo.

Al cierre, el código, la documentación y las credenciales quedan 100% a tu nombre — así trabajamos siempre, y está detallado en nuestras preguntas frecuentes. Si el sistema en cuestión ya no da para modernizarse y lo que corresponde es construir algo nuevo, te lo vamos a decir en la auditoría: para eso existe nuestro servicio de desarrollo de software a medida.

¿Tienes un sistema que sostiene la operación y que nadie quiere tocar? Conversemos: partimos con una auditoría y te entregamos un mapa honesto del estado real antes de que comprometas presupuesto.

Preguntas frecuentes

¿Cuánto demora modernizar un sistema legacy?

Los primeros wins medibles llegan en semanas — típicamente en los primeros dos o tres sprints, sobre el primer módulo priorizado. La modernización completa puede tomar varios meses, dividida en fases mensuales con entregas usables. La diferencia clave con un rewrite: el valor llega durante el proyecto, no al final.

¿Hay que congelar las funcionalidades nuevas durante la modernización?

No, y esa es una de las ventajas del enfoque incremental. El sistema viejo sigue operando mientras se migra, y las funcionalidades nuevas se construyen directamente sobre los componentes modernos cuando es posible. El negocio no se detiene a esperar a TI.

¿Qué pasa si no hay documentación y el proveedor original ya no está?

Es la situación más común, y no impide modernizar. La auditoría inicial reconstruye el mapa desde el código, la infraestructura y las dependencias reales, y los tests de caracterización capturan el comportamiento actual del sistema sin necesidad de que nadie lo explique. No necesitas al autor original para avanzar con seguridad.