Cuándo tu sistema antiguo se convierte en el mayor riesgo de tu empresa

El sistema que nadie toca porque "funciona"

Hay un tipo de sistema antiguo que aparece en casi todas las empresas medianas con algunos años de historia. Nadie sabe exactamente quién lo construyó. La documentación es escasa o directamente no existe. Solo una o dos personas del equipo entienden cómo funciona de verdad. Y cada vez que alguien propone tocarlo, la respuesta es la misma: "mejor no, está funcionando".

Ese sistema no es un activo estable. Es una deuda que se acumula con intereses.

El problema no es que sea viejo. Los sistemas pueden durar décadas si se mantienen bien. El problema es cuando el sistema deja de ser mantenible: cuando cualquier cambio pequeño requiere semanas de trabajo, cuando un error en producción tarda días en diagnosticarse, o cuando la persona que lo conoce renuncia y de repente nadie sabe cómo opera el negocio.

---

Qué es deuda técnica y por qué importa ahora

La deuda técnica es el costo acumulado de decisiones de desarrollo que priorizaron la velocidad sobre la solidez. Como la deuda financiera, no desaparece sola: aumenta. Y como la deuda financiera, llega un punto en que los intereses consumen más recursos que el capital original.

En términos concretos: un sistema con alta deuda técnica no solo es difícil de modificar. Es caro de operar, frágil ante cambios de contexto (nuevas integraciones, cambios regulatorios, más volumen) y dependiente de conocimiento que vive en personas, no en documentación.

La señal más clara de que la deuda llegó a un nivel crítico no es técnica sino operacional: cuando el equipo dedica más tiempo a apagar incendios que a construir cosas nuevas, el sistema ya está gobernando a la empresa, no al revés.

---

Cómo se ve el riesgo en la práctica

Estos son los patrones que se repiten con más frecuencia en sistemas heredados que llegan a un punto crítico:

Punto único de falla humana. Una sola persona entiende el sistema en profundidad. Si esa persona se va (por renuncia, enfermedad o vacaciones), la operación queda expuesta. No es un escenario hipotético: es el modo en que muchas empresas descubren que tienen un problema.

Integraciones sin contrato. El sistema se conecta con otros sistemas mediante integraciones que nadie documentó formalmente. Cuando uno de esos sistemas externos cambia su API o su estructura de datos, el error aparece en producción antes de que alguien lo detecte en desarrollo.

Lógica de negocio enterrada en el código. Las reglas que gobiernan cómo opera el negocio (cálculos de precios, flujos de aprobación, condiciones de excepción) están hardcodeadas en el sistema sin documentación externa. Cambiar una regla de negocio requiere un ciclo de desarrollo completo, con todo el riesgo que eso implica.

Dependencias sin soporte. Librerías, frameworks o versiones de lenguaje que ya no reciben actualizaciones de seguridad. Cada mes que pasa sin actualizar es un mes más de exposición a vulnerabilidades conocidas.

Cualquiera de estos patrones por separado es manejable. Cuando aparecen juntos (y en sistemas heredados suelen aparecer juntos), el riesgo deja de ser técnico y se convierte en riesgo de negocio: la operación pasa a depender de un sistema que nadie puede mantener.

---

La decisión que nadie quiere tomar: ¿reescribir o mantener?

Cuando el diagnóstico es claro, la pregunta que sigue es inevitable: ¿conviene reescribir el sistema desde cero o invertir en mantenerlo y ponerlo al día?

No hay una respuesta universal. Pero hay criterios concretos para orientar la decisión:

Mantener y refactorizar tiene sentido cuando:

• El sistema tiene una base funcional sólida y los problemas están acotados a módulos específicos.
• El negocio no puede tolerar una interrupción del servicio durante una migración.
• El conocimiento del dominio está suficientemente capturado como para guiar cambios graduales.
• El costo de reescribir supera el costo estimado de mantenimiento en un horizonte de dos a tres años.

Reescribir tiene sentido cuando:

• El sistema no aguanta el volumen que el negocio espera tener.
• Las dependencias son tan obsoletas que mantenerlas seguras es inviable.
• El costo de cada cambio es desproporcionado respecto al valor que entrega.
• La arquitectura original no puede adaptarse a requisitos nuevos sin cirugía mayor en cada iteración.

Hay una tercera opción que se subestima: el strangler fig pattern, que consiste en reemplazar el sistema heredado de forma incremental, módulo por módulo, mientras el sistema original sigue operando. Es más lento que una reescritura completa, pero reduce drásticamente el riesgo de interrupción. La analogía es simple: en vez de demoler el edificio y construir uno nuevo, vas renovando habitación por habitación mientras la gente sigue viviendo adentro. Algo parecido se hizo en el caso Paraíso del Sur: el sistema existente siguió funcionando y lo nuevo se construyó para convivir con él.

// Ejemplo simplificado: una capa de abstracción que permite
// redirigir llamadas del sistema heredado al nuevo módulo
// sin cambiar el contrato externo.

class PricingService {
  private legacyClient: LegacyPricingClient;
  private newClient: NewPricingClient;
  private useNewModule: boolean;

  async getPrice(productId: string): Promise<number> {
    if (this.useNewModule) {
      return this.newClient.getPrice(productId);
    }
    return this.legacyClient.getPrice(productId);
  }
}

Este patrón permite migrar con un feature flag, validar el nuevo módulo en paralelo y revertir si algo falla, sin que el sistema completo quede expuesto.

---

El momento en que el riesgo se vuelve urgente

La mayoría de las empresas no actúa sobre sus sistemas heredados hasta que algo falla. Un incidente en producción, una integración que se rompe, o la renuncia de la persona clave que lo mantenía. En ese momento, el margen de maniobra es mínimo y las decisiones se toman bajo presión.

Actuar antes del incidente no es conservadurismo, es gestión de riesgo. Y la primera acción no es técnica: es diagnóstica. Entender qué tan expuesta está la empresa requiere mapear las dependencias del sistema, identificar los puntos únicos de falla y estimar el costo real de una interrupción no planificada.

Ese diagnóstico suele revelar que el riesgo era mayor de lo que se percibía, y que las opciones disponibles son más amplias de lo que parecía cuando el sistema "estaba funcionando". Es, en el fondo, el mismo trabajo de diseño previo que decide si un sistema sobrevive, aplicado a algo que ya existe.

---

Qué hacer ahora

1. Mapea las dependencias críticas de tu sistema. Identifica qué personas, librerías externas e integraciones son puntos únicos de falla. Si esa información no existe documentada, conseguirla es la primera prioridad, no el último paso antes de una crisis. Si prefieres no hacerlo solo, te acompañamos en una revisión de dependencias.

2. Estima el costo real de una interrupción no planificada. No el costo técnico de arreglarlo, sino el costo de negocio de que el sistema esté caído durante 24, 48 o 72 horas. Ese número cambia completamente la conversación sobre cuánto vale invertir en mantenimiento preventivo.

3. Evalúa si el sistema aguanta el volumen que viene. Si el negocio va a duplicar su volumen en los próximos dos años, pregúntate si el sistema fue diseñado para eso. Si la respuesta es no, el momento de planificar la transición es ahora, no cuando ese volumen ya llegó y el sistema está al límite.