Son sistemas que siguen facturando, operando y sosteniendo procesos críticos, pero que cargan decisiones técnicas de otro contexto. La pregunta real no es si hay legacy, sino qué hacer con él sin poner en riesgo el negocio. Refactorizar, reescribir o convivir son estrategias con consecuencias técnicas y financieras.
Un sistema se vuelve problemático cuando cada cambio incrementa el riesgo operativo. El código puede funcionar, pero la fricción aparece en forma de despliegues frágiles, tiempos de entrega largos y dependencias implícitas que nadie domina del todo. En este punto, el legacy deja de ser una ventaja competitiva y se convierte en una fuente constante de technical drag. Aun así, muchos de estos sistemas están profundamente alineados con el dominio del negocio, lo que vuelve peligrosa cualquier decisión impulsiva.
Refactorizar es la opción correcta cuando el sistema sigue siendo válido, pero su estructura interna impide avanzar. Pensemos en una plataforma de e‑commerce construida hace varios años en PHP con un framework aún soportado. El sistema procesa miles de órdenes al día y genera ingresos directos, pero cada nueva funcionalidad requiere semanas porque la lógica de negocio vive mezclada con controladores gigantes y consultas directas a base de datos.
En un escenario así, la refactorización progresiva permite recuperar control sin interrumpir la operación. Se comienza escribiendo tests de regresión alrededor de los flujos críticos: checkout, pagos y facturación. Con esa red de seguridad, el equipo introduce una separación clara entre dominio, servicios y persistencia, moviendo la lógica fuera de la capa HTTP. El resultado no es un sistema “nuevo”, sino uno predecible, donde el costo de cambio baja y el time‑to‑market mejora de forma tangible.
La reescritura se vuelve necesaria cuando la arquitectura es el reto. Un ejemplo común es un sistema interno desarrollado en un stack end‑of‑life, con capas fuertemente acopladas y sin posibilidad real de testear. Cada cambio introduce bugs colaterales y el conocimiento del sistema vive en pocas personas.
Aquí, reescribir no significa copiar funcionalidad, sino replantear el diseño desde el dominio. El proceso inicia entendiendo qué partes del sistema generan valor y cuáles solo existen por inercia. A partir de ahí, se construyen servicios nuevos, pequeños y bien delimitados, que conviven temporalmente con el sistema antiguo. La migración es gradual y orientada al negocio, reduciendo el riesgo del clásico big‑bang rewrite. Cuando se hace bien, el beneficio se puede ver dimensiones técnicas y estratégicas
Hay casos donde tocar el core no es la mejor opción. Sistemas regulatorios, fiscales o altamente auditados suelen ser estables pero costosos de modificar. En estos contextos, la estrategia más madura es aislar el legacy y construir alrededor de él. Mediante APIs, adapters y capas de protección, el sistema antiguo se mantiene como una pieza confiable mientras la innovación ocurre fuera de su perímetro.
Esta convivencia controlada permite que el negocio evolucione sin asumir riesgos innecesarios. El legacy no desaparece, pero deja de bloquear decisiones futuras.
Refactorizar, reescribir o convivir no son decisiones puramente técnicas. Involucran riesgo operativo, presupuesto, talento disponible y expectativas del negocio. En una fábrica de software, el verdadero expertise no está en elegir la opción más elegante, sino la más sostenible. El legacy moderno debe ser gestionado con intención, claridad y responsabilidad técnica.
Contacto
contacto@karvon.mx
56 1995 1546
Av Convento de Actopan #41 Col Las Margaritas Ampliacion
Tlalnepantla Edomex cp 54050
