La posición honesta de quien se dedica a esto es que la mayoría de los sistemas se pueden modernizar, y que reescribir desde cero suele ser una decisión tomada por incomodidad y no por análisis.
Pero «la mayoría» no es «todos». Hay casos en los que la respuesta correcta es sustituir, y conviene saber reconocerlos para no gastar dos años demostrándolo.
Las cuatro señales
1. El negocio que atiende ya no es el mismo
La señal más definitiva, y no es técnica. Si el sistema modela un negocio que la empresa dejó de tener —otro modelo de cobro, otros canales, otra estructura— entonces no hay nada que preservar: la lógica que contiene ya no es la que hace falta.
Modernizar un sistema para que siga haciendo bien algo que ya no se hace es el proyecto más caro posible.
2. No se puede ejecutar en ningún sitio
Cuando la plataforma sobre la que corre no tiene sucesor: hardware que ya no se fabrica, un motor de base de datos que no existe en versiones actuales, un lenguaje sin compilador mantenido. Si no se puede levantar en una máquina nueva, no se puede evolucionar.
Ojo: esto es menos frecuente de lo que se dice. COBOL y Delphi tienen compiladores actuales; lo que suele caducar es el entorno, no el lenguaje.
3. El costo de un cambio es siempre el mismo, sea grande o pequeño
En un sistema sano, un cambio pequeño cuesta poco. Cuando cualquier modificación —mover un botón o cambiar un cálculo— cuesta tres semanas porque hay que probarlo todo entero, el sistema ha dejado de ser modificable en la práctica.
Esa es la definición operativa de deuda técnica terminal, y la tratamos en deuda técnica: el costo oculto.
4. Ni el código ni el comportamiento se pueden recuperar
Sin código, sin quien lo conozca y sin posibilidad de observar lo que hace porque está fuera de uso. Aquí no hay qué preservar. Sobre los casos en que sí se puede, escribimos en cuando el código fuente no aparece.
Lo que no es una señal
Conviene decirlo, porque son las razones que más se esgrimen:
- «Está en una tecnología vieja». Un sistema en PHP 5 o en Delphi que funciona no es un problema; es un sistema que funciona en una tecnología vieja.
- «El código es feo». La incomodidad de quien lo lee no es un criterio de inversión.
- «Nadie del equipo lo conoce». Eso es un problema de conocimiento, y aprender siempre cuesta menos que reescribir.
Si de verdad hay que sustituir
Entonces conviene hacerlo sabiendo dónde se estrellan estos proyectos:
- Por partes, nunca todo de una vez. Un módulo que entra en producción, luego otro.
- Con el viejo vivo mientras tanto. Convivencia, como en migrar un sistema que no puede apagarse.
- Extrayendo las reglas del sistema viejo antes de apagarlo. Ese código sabe cosas que nadie recuerda.
- Con fecha de apagado comprometida. Sin ella, se acaba manteniendo dos sistemas para siempre.
Si no está seguro de en qué caso está, eso es exactamente lo que resuelve un diagnóstico.