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

El sistema que nadie toca porque "funciona"

Hay un tipo de sistema que aparece en casi todas las empresas medianas con cierta historia tecnológica. 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 — crece. 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, crecimiento de 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 — es 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 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 mejorarlo?

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 son 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 mejoras incrementales.
• El costo de reescribir supera el costo proyectado de mantenimiento en un horizonte de dos a tres años.

Reescribir tiene sentido cuando:

• El sistema no puede escalar para soportar el crecimiento proyectado del negocio.
• 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 — 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.

// 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".

---

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.

2. Estima el costo real de una interrupción no planificada. No el costo técnico de arreglarlo — 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 puede absorber el crecimiento proyectado. 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 el crecimiento ya llegó y el sistema está al límite.