Software antiguo no es lo mismo que software que hay que sustituir

Es fácil asumir que una aplicación con varios años de uso necesita renovarse por el simple hecho de tener antigüedad. No es así. Muchas aplicaciones llevan mucho tiempo funcionando y siguen resolviendo correctamente el proceso para el que se crearon, sin generar ningún problema real.

El problema no aparece por la edad del software, sino cuando empieza a limitar cosas concretas: el mantenimiento, la capacidad de introducir cambios, las nuevas funcionalidades, las integraciones con otros sistemas, la estabilidad, el conocimiento de cómo funciona, los despliegues, o la capacidad de la empresa para evolucionar su propio negocio.

Señales de que una aplicación empieza a limitar el negocio

Ninguna señal es determinante por sí sola, pero cuando varias coinciden a la vez, suele valer la pena analizarlo con más detalle:

  • Cada pequeño cambio resulta desproporcionadamente complejo. Lo que debería ser un ajuste menor obliga a tocar varias partes del sistema a la vez, lo que alarga los plazos y aumenta el riesgo de romper algo que funcionaba.
  • Existe miedo a modificar ciertas partes porque pueden romper otras. Cuando nadie quiere tocar un módulo concreto, suele ser señal de que nadie entiende bien sus dependencias, no de que esté especialmente bien construido.
  • Solo una persona o un proveedor conoce realmente el sistema. Cualquier ausencia, cambio de proveedor o salida de esa persona se convierte en un riesgo operativo real para el negocio.
  • La tecnología de base ya no tiene soporte o mantenimiento sencillo. Encontrar quien pueda trabajar con ella, o componentes compatibles, se vuelve cada vez más difícil y más caro.
  • Las nuevas funcionalidades tardan cada vez más en llegar. No necesariamente porque el equipo trabaje peor, sino porque cada incorporación exige más cuidado del que debería.
  • Cuesta integrarlo con nuevas herramientas. El negocio necesita conectar el sistema con otra plataforma y la arquitectura actual no lo pone fácil.
  • Los despliegues son manuales o especialmente delicados. Publicar un cambio genera incertidumbre, en lugar de ser un paso rutinario y previsible.
  • Faltan pruebas o documentación actualizada. Nadie puede verificar con seguridad que un cambio no ha roto algo en otra parte del sistema.

Cuándo no conviene modernizar todavía

Modernizar no siempre es la decisión correcta en un momento dado. Probablemente no haga falta todavía cuando:

  • La aplicación sigue cubriendo correctamente el proceso para el que se creó.
  • Sigue siendo razonablemente mantenible: los cambios, aunque ocasionales, no generan grandes sobresaltos.
  • La tecnología de base sigue soportada y no hay señales claras de que vaya a dejar de estarlo a corto plazo.
  • Los cambios que necesita son poco frecuentes y controlables.
  • Los problemas que existen son puntuales y pueden resolverse sin una intervención mayor.
  • El coste y el riesgo de intervenir no están justificados por el valor que aportaría el cambio.

No existe una fórmula universal para decidirlo: depende de cuánto le cuesta hoy a la empresa mantener la aplicación tal como está, comparado con lo que costaría evolucionarla.

Modernizar no significa una sola cosa

Según el estado de la aplicación, evolucionarla puede implicar caminos muy distintos:

  • Mantener. El sistema sigue cumpliendo correctamente su función. No hace falta intervenir más allá del mantenimiento habitual.
  • Mejorar o refactorizar. Se conserva la aplicación, pero se corrigen problemas internos concretos sin cambiar lo que ya funciona bien.
  • Actualizar. Se actualizan frameworks, dependencias, infraestructura o base de datos cuando eso reduce riesgo o desbloquea posibilidades, sin tocar el resto.
  • Ampliar. Se incorporan nuevos módulos o funcionalidades sin sustituir el sistema existente.
  • Integrar. Cuando el problema real es que el sistema está aislado de otras herramientas, la solución puede ser conectarlo, no reescribirlo.
  • Modernizar progresivamente. Evolucionar determinadas partes por fases, sin detener ni reescribir el resto del sistema.
  • Reescribir o sustituir. Solo cuando, tras analizar las alternativas anteriores, mantener o evolucionar lo existente deja de ser razonable.

Estas opciones no son excluyentes entre sí, y casi nunca hace falta elegir la más radical.

La deuda técnica no es automáticamente una razón para reescribir

La deuda técnica es la acumulación de decisiones y atajos tomados en el pasado que hoy dificultan evolucionar el sistema. Tenerla no es, por sí solo, un motivo para reescribir nada.

Lo relevante es evaluar cuánto dificulta realmente evolucionar el sistema, qué riesgo introduce, qué coste operativo genera mantenerla, y qué partes de esa deuda afectan de verdad al negocio, frente a las que son solo una incomodidad técnica sin impacto real.

Cuando el conocimiento depende de una sola persona

Que solo una persona o un proveedor conozca bien una aplicación es un riesgo, pero no es un motivo automático para sustituirla. El objetivo razonable no es alarmarse, sino reducir esa dependencia con el tiempo: documentación, conocimiento compartido dentro del equipo, pruebas que expliquen cómo debería comportarse el sistema, una arquitectura más comprensible, y procedimientos de despliegue que no dependan de que una persona concreta esté disponible.

Modernizar por fases

Modernizar no tiene por qué ser una operación única. Una estrategia habitual es avanzar por fases: actualizar primero la capa más problemática, separar un módulo concreto, sustituir una interfaz, crear una capa de conexión alrededor del sistema existente para que otras herramientas puedan usarlo sin tocar su interior, modernizar determinados componentes, o migrar una parte de la base de datos.

A este tipo de estrategia, sustituir progresivamente piezas de un sistema mientras el conjunto sigue funcionando, a veces se la conoce como patrón «Strangler Fig»: en lugar de detener el sistema y reconstruirlo entero, se van reemplazando partes poco a poco hasta que lo antiguo deja de ser necesario. No hace falta profundizar más en el término: lo importante es que evolucionar por fases suele reducir el riesgo frente a un cambio radical de una sola vez.

Un ejemplo: una aplicación que sigue gestionando pedidos y facturación

Una aplicación interna desarrollada hace años sigue gestionando correctamente los pedidos y la facturación de una empresa. El problema no es que sea antigua: es que añadir una funcionalidad nueva obliga a tocar varias partes del sistema a la vez, solo una persona entiende bien uno de sus módulos, conectarla con una nueva plataforma de venta resulta difícil, y cada despliegue genera cierta incertidumbre.

Ante esta situación, las alternativas no se reducen a «dejarlo como está» o «rehacerlo todo». Podría tener sentido mantener la parte de facturación tal como funciona hoy, modernizar el módulo que concentra el conocimiento de una sola persona, crear una conexión para que hable con la nueva plataforma sin reescribir nada, y renovar progresivamente la interfaz en los puntos donde más lo necesita el equipo.

Cuándo puede tener sentido una reescritura completa

Reescribir un sistema completo desde cero es la opción con más riesgo, y no debería ser la primera que se valora. Tiene sentido considerarla después de haber descartado razonablemente las alternativas anteriores: cuando el sistema ya no puede evolucionar de forma segura, cuando el proceso que debía cubrir ha cambiado tanto que la aplicación original ya no encaja con él, o cuando construir algo nuevo, pensado para cómo funciona la empresa hoy, aporta más valor que seguir manteniendo lo existente.

En esos casos, el proyecto deja de ser una modernización y pasa a ser, en la práctica, un proyecto de software a medida. Una reescritura completa no es automáticamente la opción «mejor» ni la más moderna: es una decisión que conviene tomar solo cuando las alternativas anteriores se han evaluado en serio y no resultan suficientes.

Empieza por entender qué aporta la aplicación, no por elegir la tecnología

Antes de decidir cómo intervenir, conviene entender qué aporta hoy la aplicación al negocio, quién depende de ella, qué la hace difícil de mantener o evolucionar, y qué necesitaría poder hacer en el futuro.

Con esa base, decidir si conviene mantenerla, mejorarla, actualizarla, ampliarla, integrarla, modernizarla por fases o, en último caso, sustituirla, resulta una decisión mucho más informada que partir directamente de la tecnología que se quiere usar.