Software legacy: ¿reparar, modernizar o rehacer? Cómo decidir

Casi todas las empresas que llevan tiempo funcionando tienen alguna: la aplicación de gestión que se hizo hace años, la intranet que solo entiende una persona o el programa de pedidos que "funciona, pero que nadie lo toque". En el sector se le llama software legacy, sistemas legacy o software heredado: un sistema que sigue siendo importante para el negocio, pero que se construyó con tecnologías, decisiones o personas que ya no están.

Tener software legacy no es un problema en sí mismo. El problema llega cuando mantenerlo empieza a costar más de lo que aporta, cuando frena cambios que el negocio necesita o cuando se convierte en un riesgo. Llegados a ese punto, la pregunta es siempre la misma: ¿lo arreglamos, lo vamos modernizando o lo tiramos y empezamos de cero?

Este artículo no te va a dar una respuesta universal, porque no la hay. Te va a dar los criterios para tomar la decisión con información, y no por cansancio o por la recomendación de quien solo sabe hacer una de las tres cosas.

Qué significa "legacy" (y qué no)

Que una aplicación sea antigua no la convierte automáticamente en un problema. Hay sistemas con muchos años que siguen siendo estables, rápidos y fáciles de mantener. Y hay aplicaciones relativamente recientes que ya se comportan como software legacy porque nadie sabe cómo están hechas.

En la práctica, un sistema se vuelve legacy cuando se dan varias de estas situaciones:

• Tecnología sin soporte: el lenguaje, el framework (el "esqueleto" sobre el que se construye la aplicación) o el servidor ya no reciben actualizaciones de seguridad. En PHP, por ejemplo, cada versión tiene una fecha a partir de la cual deja de recibir parches, y se puede consultar en la página oficial de versiones soportadas.
• Conocimiento concentrado o perdido: solo una persona sabe cómo funciona, o ya no está nadie de quienes lo hicieron.
• Cambios lentos y arriesgados: cualquier modificación pequeña tarda semanas y rompe algo en otro sitio.
• Dificultad para integrarse: no se puede conectar fácilmente con la tienda online, el banco, la gestoría u otras herramientas que hoy se dan por hechas.
• Dependencia de piezas que desaparecen: un componente de pago, una librería abandonada o un proveedor que ya no da servicio.

Si reconoces varias, no significa que haya que rehacer nada. Significa que conviene decidir qué hacer antes de que la decisión la tome una avería.

Las tres opciones, explicadas sin tecnicismos

Reparar y estabilizar

Consiste en dejar el sistema como está en lo esencial, pero ponerlo bajo control: copias de seguridad fiables, accesos a nombre de la empresa, corrección de los errores que más molestan, actualización de lo imprescindible por seguridad y algo de documentación.

Es la opción menos ambiciosa y, muchas veces, la más sensata como primer paso. No resuelve los problemas de fondo, pero reduce el riesgo y te da tiempo para decidir con calma.

Modernizar por fases

Es lo que se suele llamar modernización de software: ir sustituyendo o renovando partes del sistema poco a poco, mientras el conjunto sigue funcionando. Por ejemplo: actualizar primero la versión del lenguaje, después separar el módulo de facturación, más adelante rehacer la parte que usan los clientes.

Hay una técnica conocida para hacerlo de forma ordenada, que el ingeniero Martin Fowler describió como el patrón "strangler fig": el sistema nuevo va creciendo alrededor del antiguo y asumiendo sus funciones hasta que el viejo puede retirarse. Su gran ventaja es que en ningún momento dependes de un "gran día" en el que todo cambia a la vez.

Rehacer desde cero

Consiste en construir una aplicación nueva que sustituya a la antigua y, cuando está lista, migrar los datos y cambiar de una a otra.

Es la opción más atractiva sobre el papel: código limpio, tecnología actual, sin arrastrar errores del pasado. Pero también es la más cara y la que más riesgos concentra. Durante el desarrollo hay que mantener los dos sistemas, el negocio sigue cambiando mientras tanto y es muy fácil olvidar reglas que el sistema antiguo aplicaba sin que nadie las hubiera escrito en ningún sitio.

Cómo decidir: las preguntas que importan

En lugar de partir de una preferencia ("esto hay que tirarlo" o "esto no se toca"), conviene responder a unas cuantas preguntas. La mayoría no son técnicas.

1. ¿El sistema sigue haciendo lo que el negocio necesita?

Si la aplicación cubre bien los procesos y lo que falla son cosas concretas (lentitud, errores, versiones antiguas), lo normal es reparar y, si hace falta, modernizar por partes. Si el negocio ha cambiado tanto que la aplicación ya no encaja (nuevas líneas de negocio, otra forma de vender, otros canales), rehacer empieza a tener más sentido.

2. ¿Se puede trabajar con el código?

Esta es la pregunta técnica clave, y solo se responde con una revisión del código: lo que en una auditoría técnica de software se conoce como auditoría de código. Un código ordenado, aunque sea antiguo, se puede actualizar y ampliar. Un código en el que nadie se atreve a cambiar nada sin romper otra cosa es mucho más difícil de modernizar, y ahí rehacer partes concretas suele ser más eficiente que seguir parcheando.

3. ¿Qué pasa si falla mañana?

Si el sistema gestiona cobros, pedidos, datos de clientes o algo que para la actividad si se cae, la prioridad es reducir el riesgo cuanto antes, decidas lo que decidas a medio plazo. Eso suele significar estabilizar primero, aunque el plan final sea sustituirlo.

4. ¿Cuánto conocimiento del negocio está "escondido" en el código?

Las aplicaciones que llevan años en uso acumulan excepciones, cálculos especiales y reglas que nadie recuerda haber pedido. Cuanto más de esto haya, más arriesgado es rehacer: cada regla olvidada aparecerá como un error el día que cambies de sistema.

5. ¿Existe ya una herramienta que lo resuelva?

A veces la respuesta honesta es que no necesitas ni mantener tu aplicación ni hacer una nueva: hay un programa estándar (un ERP, un CRM, una herramienta de facturación) que cubre lo que haces. Si tu proceso no tiene nada especial, merece la pena valorarlo antes de invertir en desarrollo.

Una tabla para orientarte

Con las respuestas anteriores, este cuadro ayuda a ver hacia dónde apunta cada situación. No sustituye a un análisis, pero ordena la conversación:

Fíjate en que "rehacer" aparece en pocos casos y casi siempre con matices. No es que rehacer sea malo: es que es la opción que más se elige por impulso y la que más caro sale cuando se elige mal.

Por dónde empezar, sea cual sea la decisión

Antes de elegir entre reparar, modernizar o rehacer, hay unos pasos que conviene dar siempre, porque cualquier opción los necesita:

1. Asegurar lo básico: copias de seguridad que se hayan probado, accesos al código, al servidor y al dominio a nombre de la empresa. Si no los tienes, en qué hacer si tu proveedor de software ha desaparecido explicamos cómo recuperarlos paso a paso.
2. Hacer inventario: qué hace la aplicación, quién la usa, con qué otros sistemas se comunica y qué partes son críticas.
3. Encargar un diagnóstico técnico que revise el código, las versiones y los riesgos, y que termine en un informe comprensible para quien decide, con opciones y su coste aproximado.
4. Decidir por partes: no tiene por qué ser una decisión única para todo el sistema. Es frecuente estabilizar el conjunto, modernizar un módulo y rehacer solo la parte que de verdad no tiene arreglo.

Esta es la forma en que planteamos un rescate de software: primero entender qué hay, después estabilizar y, solo entonces, decidir cómo evolucionar. Y si el diagnóstico concluye que lo mejor es una aplicación nueva, conviene plantearla como un desarrollo de software a medida bien definido, aprovechando todo lo aprendido del sistema anterior.

Errores habituales al modernizar software legacy

Algunos tropiezos se repiten con frecuencia y es fácil evitarlos si se conocen de antemano:

• Decidir sin diagnóstico: elegir la opción por intuición o por lo que propone el primer proveedor consultado.
• Rehacer sin documentar el sistema antiguo: si no sabes todo lo que hace la aplicación actual, la nueva no lo hará.
• Plantearlo todo de golpe: los proyectos de "todo o nada" acumulan riesgo al final, justo cuando hay menos margen para corregir.
• Olvidar los datos: migrar años de información de un sistema a otro es un trabajo en sí mismo, y conviene planificarlo desde el principio.
• No contar con quien usa la aplicación: las personas que trabajan con ella cada día saben qué es imprescindible y qué sobra mejor que nadie.

En resumen

El software legacy no se arregla con una decisión heroica, sino con una sucesión de decisiones sensatas. Primero, poner el sistema bajo control. Después, entender en qué estado está de verdad. Y, a partir de ahí, elegir para cada parte si conviene repararla, modernizarla o sustituirla.

Si tienes una aplicación antigua que te preocupa y no sabes por dónde empezar, cuéntanos qué hace y qué está fallando: te diremos qué pasos recomendamos, aunque la respuesta sea que no necesitas cambiar casi nada.