Modernizar el sistema actual o desarrollar uno nuevo
Rehacer todo es la primera reacción y casi nunca la mejor decisión. Estas son las señales que inclinan cada camino.
· 3 minutos de lectura
Un sistema que lleva años funcionando acumula dos cosas a la vez: el conocimiento del negocio, que es valioso, y deuda técnica, que estorba. Rehacerlo desde cero significa botar las dos.
Por eso la decisión no se toma por cómo se ve el código, sino por cinco señales concretas.
Las señales que inclinan a rehacer
La tecnología quedó sin soporte y no hay ruta de actualización
Cuando la versión del lenguaje o del motor de base de datos dejó de recibir parches de seguridad y no existe un camino gradual para subir, el reloj corre. No es una molestia estética: es una vulnerabilidad conocida sin corregir.
Cada cambio pequeño rompe tres cosas
Si tocar una pantalla obliga a probar el sistema entero porque nadie sabe qué depende de qué, el costo de cada mejora crece hasta que dejar de mejorar parece razonable. Ese es el punto en el que el sistema empieza a frenar el negocio.
No queda nadie que lo entienda ni forma de averiguarlo
Sin documentación, sin quien lo escribió y con código que no se explica solo, el tiempo de entender supera al de reconstruir.
El negocio ya no se parece al que el sistema modela
Cuando la empresa cambió de modelo y el sistema sigue representando el anterior, cada función nueva se construye peleando contra la estructura. Aquí el problema no es técnico.
El costo de operarlo supera al de reemplazarlo
Servidores antiguos, licencias caras, horas de personas cubriendo a mano lo que el sistema no hace. Cuando esa suma anual se acerca al costo de un sistema nuevo, la cuenta se hace sola.
Las señales que inclinan a conservar
- El sistema hace lo que el negocio necesita, aunque no sea elegante.
- La tecnología todavía tiene soporte, aunque esté algunas versiones atrás.
- Existe documentación o gente que lo conoce.
- Los problemas se concentran en una parte identificable, no en todo.
Que el código no esté escrito como uno lo habría escrito no es una señal. Es una opinión, y reescribir por opinión cuesta meses y empieza con menos funciones de las que ya tienes.
El camino que suele funcionar: reemplazar por partes
Entre conservar y rehacer hay una tercera opción, y en la mayoría de los casos es la mejor.
Consiste en dejar el sistema antiguo operando y construir lo nuevo alrededor, una parte a la vez. El sistema viejo va perdiendo responsabilidades hasta que queda vacío y se apaga.
Se hace así:
- Estabilizar primero. Respaldos que funcionen, un ambiente de pruebas, y las vulnerabilidades más urgentes corregidas. Sin esto, cualquier cambio es un riesgo.
- Elegir la parte que más molesta. No la más fácil ni la más grande: la que genera más trabajo manual o más reclamos.
- Construirla aparte y conectarla. El sistema nuevo lee y escribe donde el antiguo, o los dos comparten los datos durante la transición.
- Mover a los usuarios de a poco, con vuelta atrás disponible.
- Repetir con la siguiente parte.
Por qué conviene
La operación nunca se detiene. El gasto se reparte en meses en vez de concentrarse. Cada etapa entrega algo utilizable, así que si el presupuesto se corta a mitad de camino igual quedó valor. Y si una parte sale mal, afecta a una parte y no al sistema completo.
Qué exige
Disciplina para no dejar el proyecto a medias con dos sistemas conviviendo para siempre, que es el riesgo real de este camino. Por eso conviene fijar desde el inicio en qué orden se apagan las piezas del sistema antiguo.
Cómo empezar
Antes de decidir hace falta una revisión: en qué estado está el código, qué tan desactualizada está la tecnología, si los respaldos funcionan y qué tan expuesto está. Esa revisión termina con un informe y una recomendación, y es tuyo tomes o no un plan después.
Está dentro de la mantención y evolución de software y de la consultoría tecnológica, según si lo que sigue es sostenerlo o decidir qué construir.