Modernizar un sistema legacy sin parar la operación

Casi toda empresa con más de diez años carga un sistema del que nadie quiere hablar. Funciona —eso es lo incómodo— pero cambiarlo da miedo, el que lo hizo ya no está y cada modificación tarda semanas. Mientras tanto sostiene facturación, inventario o nómina, así que apagarlo no es opción.

Esta guía explica cómo modernizarlo sin detener la operación: cuándo conviene reescribir, cuándo encapsular y cuándo simplemente dejarlo en paz.

"Legacy" no significa viejo

Un sistema de 2009 que se puede modificar en dos días, tiene pruebas y alguien lo entiende, no es legacy: es maduro. Un sistema de 2021 que nadie se atreve a tocar sí lo es.

La definición útil es operativa: un sistema es legacy cuando el costo de cambiarlo es desproporcionado frente al valor del cambio. Las causas suelen ser tres, y conviene saber cuál es la tuya porque la solución difiere:

• Conocimiento perdido. Funciona, pero nadie sabe por qué. Falta documentación, no hay pruebas, el autor se fue.
• Tecnología sin salida. El lenguaje, el framework o la base de datos ya no reciben soporte ni parches de seguridad, y no hay a quién contratar.
• Diseño agotado. La arquitectura resolvía el negocio de hace diez años y hoy toda función nueva pelea contra ella.

El primer caso puede resolverse documentando y agregando pruebas, sin reescribir una línea. El tercero casi nunca.

Las cuatro rutas, y el costo real de cada una

Ruta	Cuándo tiene sentido	El riesgo
Dejarlo	Estable, cambia poco, sin riesgo de seguridad	La deuda crece calladita
Encapsular	Funciona bien pero está aislado	La complejidad no baja, se contiene
Reemplazar con SaaS	El proceso no es tu diferenciador	Adaptar la operación al software
Reescribir por partes	El diseño ya no da y el sistema es crítico	Convivencia larga entre dos sistemas

Falta una quinta que la gente intenta y casi nunca funciona: reescribir todo de golpe y cambiar en un fin de semana. Es la que más suena en las juntas y la que más proyectos entierra. Mientras se construye el reemplazo —doce, dieciocho meses— el sistema viejo sigue cambiando, así que persigues un blanco móvil. Y el día del cambio te juegas la operación entera en una sola noche.

El patrón que sí funciona: estrangular, no reemplazar

El strangler fig toma su nombre de la higuera que crece alrededor de un árbol hasta sustituirlo: cuando el original muere, la nueva estructura ya está en pie. Aplicado a software:

1. Poner una fachada delante. Todo el tráfico pasa por una capa intermedia que, al principio, solo reenvía al sistema viejo. Nada cambia funcionalmente, pero ya controlas el enrutamiento.
2. Mover una funcionalidad. Se elige un pedazo acotado —el más doloroso o el más aislado—, se construye nuevo y la fachada empieza a mandar ese tráfico al sistema nuevo.
3. Repetir. Función por función, con la operación corriendo todos los días.
4. Apagar lo que quede. Cuando ya no le llega tráfico, el sistema viejo se apaga sin ceremonia.

La ventaja no es técnica, es de riesgo: cada paso es reversible. Si una pieza falla, la fachada la regresa al sistema viejo mientras se arregla. Nunca hay una noche en la que todo se juega.

Por dónde empezar

No por lo más fácil ni por lo más grande. Por lo que cumple estas tres:

• Duele hoy. Si el primer entregable no alivia un dolor real, el proyecto pierde patrocinio antes del tercer mes.
• Está acotado. Poca dependencia con el resto. Los reportes y los módulos de consulta suelen ser buen primer bocado porque leen sin escribir.
• Se puede medir. Que exista un número —tiempo de proceso, errores, llamadas a soporte— que demuestre que sirvió.

Los datos son la parte difícil

La lógica se reescribe. Los datos hay que moverlos, y ahí está el trabajo que siempre se subestima.

Diez o veinte años de operación dejan cosas: registros con campos que ya nadie llena, tres formas distintas de escribir el nombre de un mismo cliente, códigos de estatus que solo alguien que ya se jubiló sabe interpretar. Toda migración descubre esto, siempre tarde.

Tres cosas ayudan:

Perfilar antes de migrar. Contar valores nulos, duplicados y formatos raros antes de diseñar el esquema nuevo. Media semana de análisis ahorra semanas de sorpresas.

Decidir qué no se migra. No todo el histórico tiene que vivir en el sistema nuevo. Mucho puede quedar en un archivo de solo lectura, consultable pero fuera del camino.

Sincronización en doble vía mientras conviven. Durante la transición los dos sistemas están vivos. Hay que definir por cada dato quién manda, y tener un proceso que detecte cuando se separan — porque se van a separar.

Lo que sale mal

• Reescribir sin entender. Los if raros del sistema viejo suelen ser reglas de negocio reales que nadie documentó. Bórralos y descubres en producción para qué servían.
• Modernizar lo que no molesta. Migrar por moda tecnológica y no por dolor de negocio. Si nadie nota la diferencia, era la pieza equivocada.
• Convivencia sin fecha. El strangler fig funciona si termina. Sin plan de apagado, quedas con dos sistemas que mantener en lugar de uno.
• Dejar fuera a quienes lo usan. Quien opera el sistema todos los días conoce reglas que no están en ningún manual. Sin ellos en el diseño, el reemplazo llega incompleto.

Cómo lo hacemos en Newsoft

Empezamos siempre por entender qué tipo de legacy es. Si el problema es conocimiento perdido, muchas veces la respuesta no es reescribir: es documentar, agregar pruebas y recuperar la capacidad de cambiar el sistema que ya existe. Sale mucho más barato y hemos cerrado proyectos así.

Cuando sí hay que reemplazar, trabajamos por partes con el patrón de fachada, en sprints de dos semanas con entregables verificables — el modelo de nuestras engineering cells. La operación no se detiene y cada paso puede revertirse.

Si el sistema viejo es contable o de facturación, casi siempre conviene no tocarlo y construir alrededor; ese caso lo desarrollamos en cómo integrar tu ERP con tus demás sistemas.

¿Tienes un sistema que nadie quiere tocar? Cuéntanos el caso. El discovery es gratuito y a veces la conclusión es que no hace falta reescribir nada.

Conclusión

Un sistema es legacy cuando cambiarlo cuesta más de lo que vale el cambio, no cuando tiene muchos años. Antes de decidir, identifica si el problema es conocimiento, tecnología o diseño: solo el tercero obliga a reescribir.

Y cuando toque reescribir, hazlo por partes, detrás de una fachada, empezando por algo que duela hoy y se pueda medir. La modernización que funciona no tiene día del cambio — tiene muchos días pequeños en los que nadie se entera.