Cuándo conviene modernizar un software legacy

El coste de mantener un sistema antiguo rara vez aparece como una partida en la contabilidad. Se reparte en horas de trabajo manual, proyectos que no se hacen y riesgos que nadie ha valorado. Para decidir con criterio conviene hacerlo visible.

No hace falta precisión contable. Basta con una estimación razonable para compararla con el coste de modernizar y ver si la conversación tiene sentido.

Un sistema que depende de un sistema operativo, una base de datos o unas librerías sin soporte deja de recibir parches de seguridad. Las vulnerabilidades que se descubren a partir de entonces quedan abiertas de forma indefinida. OWASP incluye este problema entre sus riesgos principales para aplicaciones web bajo la categoría de componentes vulnerables y desactualizados, y recomienda mantener un inventario de versiones y vigilar los componentes que ya no reciben mantenimiento.

• Inventaría de qué depende el sistema: versión del sistema operativo, motor de base de datos, lenguaje o entorno de ejecución, librerías y componentes de terceros.
• Comprueba cuáles han llegado al fin de su soporte oficial y desde cuándo.
• Revisa cómo se autentican los usuarios: contraseñas compartidas, usuarios genéricos o ausencia de registros de acceso son señales de riesgo.
• Identifica qué datos sensibles contiene y quién puede llegar a ellos, incluidas copias en carpetas compartidas.

Modernizar no siempre significa reescribir. Hay un abanico de opciones con riesgos y costes muy distintos, y a menudo la respuesta combina varias según la parte del sistema.

Para sistemas críticos, la sustitución por partes suele ser más segura que un cambio total en una fecha. La idea es que el sistema nuevo vaya asumiendo funciones una a una, mientras el antiguo sigue haciendo el resto, hasta que deja de ser necesario.

1. Mapea las funciones del sistema actual y quién usa cada una. Muchas veces aparecen funciones que nadie usa y que no hace falta migrar.
2. Elige una primera función acotada, con valor visible y pocas dependencias, por ejemplo la consulta de pedidos por parte de los comerciales.
3. Decide qué sistema es el propietario de cada dato durante la convivencia y cómo se sincronizan, para evitar dos versiones de la verdad.
4. Construye la función nueva, ponla en producción para un grupo reducido y compara resultados con el sistema antiguo.
5. Cuando funcione, retira esa función del sistema antiguo y pasa a la siguiente.
6. Planifica el apagado final: migración de los datos históricos que se necesiten, archivo del resto y baja de la infraestructura.

Un ejemplo ilustrativo: una distribuidora con un programa de gestión antiguo podría empezar por un portal web de pedidos para clientes que lee y escribe en la base de datos existente a través de una capa de integración. Después, mover la gestión de tarifas; más adelante, el almacén. El núcleo contable podría quedarse donde está o pasar a un producto estándar al final.

• Perder reglas de negocio implícitas: el código antiguo hace cosas que nadie recuerda. Se reduce extrayendo reglas con casos reales antes de reescribir y comparando resultados.
• Datos de mala calidad: años de registros con criterios cambiantes. Se reduce con limpieza previa y cargas de prueba repetibles.
• Convivencia que se eterniza: dos sistemas en paralelo durante años duplican el coste. Se reduce fijando fechas de retirada por función.
• Rechazo de los usuarios: quienes dominan el sistema antiguo pierden eficiencia al principio. Se reduce implicándolos en el diseño y formando con sus propios casos.
• Querer mejorarlo todo a la vez: mezclar modernización técnica con un rediseño completo del proceso multiplica el riesgo. Conviene separar ambas decisiones o abordarlas por fases.

Modernizar tiene sentido cuando el coste de seguir, sumado al riesgo, supera razonablemente al de cambiar. Estas preguntas ayudan a ordenarlo:

1. ¿Alguno de sus componentes ha perdido el soporte de seguridad, o lo perderá pronto?
2. ¿Depende de una sola persona para mantenerse?
3. ¿Está bloqueando integraciones o mejoras que el negocio necesita?
4. ¿Se puede dividir en partes que se migren por separado?
5. ¿Están documentadas, o se pueden documentar, las reglas que aplica?

Si varias respuestas apuntan a cambiar, el siguiente paso no es presupuestar una reescritura, sino hacer un diagnóstico: inventario técnico, mapa de funciones y propuesta de fases. Con esa información podemos estudiar contigo qué conviene mantener, qué envolver y qué sustituir primero.