Viejo no es lo mismo que legacy
Hay sistemas de quince años que hacen su trabajo, se entienden, se modifican sin drama y no le cuestan a nadie una noche de sueño. No hay que tocarlos. Reescribir software que funciona por incomodidad estética es de las formas más caras de no lograr nada.
Un sistema se vuelve legacy cuando cambiarlo se ha vuelto arriesgado o caro en relación con su valor. La antigüedad es una pista; el síntoma real es que el negocio empieza a adaptarse al software en lugar de al revés. Las señales siguientes son medibles, que es lo que las hace útiles: permiten sustituir la discusión de opiniones por una cifra.
Siete señales medibles
1. Cada cambio pequeño toma semanas
Añadir un campo, ajustar una regla de negocio o cambiar el formato de un reporte debería ser trabajo de días. Cuando cualquier modificación exige semanas de análisis por miedo a lo que se pueda romper, el costo no está en el desarrollo: está en la incertidumbre. Mídelo: toma las últimas diez solicitudes de cambio y anota cuánto tardaron desde que se pidieron hasta que estuvieron en producción.
2. Sólo una persona sabe cómo funciona
El riesgo aquí no es de software, es de continuidad del negocio. Si esa persona renuncia o se enferma, ¿cuánto tarda la empresa en poder cambiar algo? Si la respuesta se mide en meses, ya estás pagando un seguro que no contrataste.
3. Nadie se atreve a actualizar nada
Sistemas operativos, bases de datos y librerías que se quedan en versiones sin soporte porque “si lo tocas, se cae”. Además del riesgo de seguridad —el software sin soporte deja de recibir parches—, cada año de retraso hace la actualización futura más grande y más cara. Mídelo: cuántas versiones de retraso acumulan tus componentes críticos.
4. La integración con cualquier cosa nueva es imposible o carísima
El negocio quiere una tienda en línea, un portal para clientes o conectar con un proveedor logístico, y todo choca contra el mismo muro: el sistema no tiene forma de exponer sus datos. Cuando el software empieza a decidir qué oportunidades comerciales se pueden perseguir, el costo dejó de ser técnico.
5. Hay una hoja de cálculo paralela
Cuando el equipo mantiene por fuera la información que el sistema debería dar, ya emitió su veredicto. Cuenta cuántas hojas paralelas existen y cuántas horas al mes consumen: es un costo real que hoy está escondido en la nómina.
6. Los incidentes se repiten
No los incidentes nuevos, los mismos de siempre. El proceso que se cae a fin de mes, el reporte que hay que regenerar a mano, el bloqueo que se resuelve reiniciando. Cada repetición es horas de gente cara y, a menudo, confianza del cliente. Mídelo: cuenta incidentes recurrentes por trimestre y multiplícalos por las horas que consume cada uno.
7. Contratar a alguien que lo mantenga es difícil o carísimo
Cuando la tecnología es tan poco común que el mercado laboral prácticamente no la ofrece, el costo de mantenimiento sólo puede subir. No es un juicio sobre la calidad de esa tecnología; es aritmética de oferta y demanda.
Cómo estimar el costo real antes de decidir
Antes de comparar contra el precio de modernizar, hay que saber cuánto cuesta no hacerlo. Cuatro sumas bastan para una estimación defendible:
- Horas al mes dedicadas a trabajo manual que el sistema debería hacer, valuadas al costo real de esas personas.
- Horas de incidentes recurrentes, incluyendo a quienes se quedan esperando mientras se resuelven.
- Tiempo perdido en cada cambio: la diferencia entre lo que tarda hoy y lo que tardaría en un sistema mantenible, multiplicada por cuántos cambios pide el negocio al año.
- Oportunidades que se descartaron porque el sistema no las soportaba. Es la más difícil de calcular y suele ser la mayor.
El resultado anual sorprende con frecuencia, y sirve para lo importante: convertir “habría que modernizar eso algún día” en una comparación entre dos números.
Modernizar no significa reescribir
Reescribir desde cero es la opción más cara, la más lenta y la que más proyectos ha hundido: durante meses hay dos sistemas que mantener, el nuevo tiene que alcanzar todo lo que el viejo hacía —incluidas las reglas que nadie documentó y sólo existen en el código— y el negocio no percibe ningún beneficio hasta el final.
Las alternativas por partes casi siempre ganan:
- Estrangulamiento gradual. Se construye lo nuevo alrededor de lo viejo, redirigiendo una función a la vez hasta que el sistema original queda sin uso. Cada paso entrega valor y es reversible.
- Exponer con una API. A veces el sistema es correcto y el problema es que está encerrado. Una capa de acceso bien definida desbloquea integraciones sin tocar el núcleo.
- Reemplazar sólo el punto que duele. El módulo de reportes, la interfaz que el equipo usa ocho horas al día, la parte que impide integrar. El resto sigue tal cual.
- Actualizar la base y detenerse ahí. Poner versiones con soporte y monitoreo decente, sin cambiar la funcionalidad, es a veces todo lo que hace falta este año.
La decisión entre estas rutas depende de dónde estén concentradas las señales del inicio. Ése es exactamente el trabajo de un diagnóstico: convertir siete síntomas dispersos en un orden de intervención con costos asociados.
Si reconociste tres o más de las siete señales, lo que corresponde no es decidir todavía si hay que reescribir: es medir. Un diagnóstico de consultoría tecnológica deja por escrito qué está costando el sistema actual, qué se puede modernizar por partes y en qué orden — y con frecuencia concluye que hay que tocar mucho menos de lo que se temía.