Software legado: cuándo modernizar un sistema antiguo y cómo hacerlo sin detener la operación

Casi todas las empresas con más de diez años tienen uno: el sistema que funciona, que nadie quiere tocar y del que depende una parte crítica de la operación. Lo mantiene una persona que sabe cómo arreglarlo, corre en un servidor que nadie actualiza y su documentación es la memoria de quien lo escribió.

La modernización de software legado no es un problema técnico. Es una decisión de riesgo: cuánto cuesta seguir así versus cuánto cuesta cambiarlo, y qué pasa si algo falla mientras tanto.

Cuándo un sistema legado deja de ser aceptable

Un sistema antiguo que funciona no es necesariamente un problema. Lo es cuando aparecen estas señales:

Riesgo de continuidad. Una sola persona sabe operarlo o repararlo. Si esa persona no está, la empresa se detiene.

Riesgo de seguridad. El sistema operativo, el motor de base de datos o el lenguaje ya no reciben parches de seguridad.

Imposibilidad de integrar. No expone API ni permite acceso a sus datos, así que cada conexión con otro sistema se resuelve exportando archivos a mano.

Costo de cambio creciente. Cualquier modificación menor toma semanas y nadie se atreve a tocar ciertos módulos.

Incumplimiento normativo. No permite cumplir con obligaciones vigentes —tributarias, de protección de datos, de trazabilidad— y no hay forma de adaptarlo.

Hardware o licencias sin reemplazo. Depende de una versión que ya no se comercializa o de un servidor que no se puede reponer.

Una o dos señales admiten convivencia. Cuatro o más significan que el riesgo ya supera al costo de modernizar.

Las cinco estrategias posibles

No hay que elegir “reescribir” por defecto. Existen cinco caminos, de menor a mayor esfuerzo:

Estrategia	Qué implica	Cuándo conviene	Riesgo
Encapsular	Poner una API delante del sistema sin tocarlo	Funciona bien pero no se puede integrar	Bajo
Rehospedar	Mover el sistema a otra infraestructura sin cambios	Riesgo de hardware o del centro de datos	Bajo
Replataformar	Actualizar versiones y componentes, manteniendo la lógica	Obsolescencia técnica sin problema funcional	Medio
Reconstruir por partes	Reemplazar módulo a módulo mientras el resto opera	Sistema crítico que no puede detenerse	Medio
Reemplazar	Sustituir por un producto estándar o un desarrollo nuevo	El sistema ya no representa el proceso	Alto

La estrategia más subestimada es la primera. Encapsular un sistema legado detrás de una API resuelve el problema de integración en semanas, sin tocar el código, y compra tiempo para decidir el resto.

La estrategia que menos falla: reemplazo progresivo

Cuando el sistema es crítico y hay que reconstruirlo, el enfoque de “apagar el viejo y encender el nuevo” un lunes es el que más incidentes produce.

El reemplazo progresivo funciona así:

Poner una capa intermedia delante del sistema legado. Todo el tráfico pasa por ahí.
Elegir un módulo acotado y reconstruirlo por separado.
Redirigir ese módulo en la capa intermedia hacia el sistema nuevo, dejando el resto en el legado.
Operar en paralelo un tiempo, comparando resultados de ambos.
Consolidar cuando los resultados coinciden.
Repetir con el siguiente módulo.
Apagar el legado cuando ya no queda nada apuntando a él.

La ventaja es que cada paso es reversible y el riesgo se acota a un módulo por vez. La desventaja es que el proyecto dura más y hay que sostener dos sistemas durante la transición.

El problema de los datos

La migración de datos suele ser la parte más subestimada del proyecto.

Lo que hay que resolver:

Calidad. Registros duplicados, campos usados para algo distinto de su propósito, valores inconsistentes acumulados durante años.
Reglas implícitas. Códigos y convenciones que solo alguien conoce.
Histórico. No todo debe migrarse. Una práctica sensata es migrar los datos operativos vigentes y dejar el histórico en un repositorio consultable de solo lectura.
Conciliación. Verificar que los saldos y totales del sistema nuevo coincidan con el antiguo antes de cortar.
Reversibilidad. Poder volver atrás si algo no cuadra.

Cómo recuperar el conocimiento perdido

Cuando no hay documentación —el caso habitual—:

Analizar el código y la base de datos para reconstruir el modelo real.
Registrar el comportamiento en producción: qué operaciones se ejecutan, con qué frecuencia, con qué datos.
Entrevistar a los usuarios, que conocen las reglas aunque no sepan dónde están escritas.
Documentar las excepciones antes de reconstruir. Son las que rompen el sistema nuevo.
Escribir pruebas contra el comportamiento actual y usarlas como criterio de aceptación del nuevo módulo.

Ese último punto es el más valioso: convierte el sistema legado en su propia especificación.

Errores frecuentes

Reescribir todo de una vez. El proyecto se alarga, el sistema viejo sigue cambiando y la brecha nunca se cierra.
Replicar el sistema tal cual. Se arrastran veinte años de parches y decisiones que ya no aplican.
Rediseñar el proceso completo al mismo tiempo. Cambiar la tecnología y el proceso simultáneamente duplica el riesgo.
Migrar todo el histórico. Costoso y rara vez necesario.
Cortar en mal momento. Cierre de mes, temporada alta o cambio normativo.
No dejar plan de reversa. Todo corte debe poder deshacerse.

Qué se gana

Además de reducir el riesgo, la modernización habilita cosas que antes eran imposibles:

Integración con otros sistemas mediante API.
Acceso a los datos para reportería y análisis.
Automatización de procesos que hoy son manuales.
Uso de IA sobre datos propios, que requiere que los datos sean accesibles.
Cumplimiento de obligaciones vigentes de protección de datos y trazabilidad.
Escalabilidad sin depender de un servidor físico.

Preguntas frecuentes

¿Cuánto cuesta modernizar un sistema legado?

Varía enormemente según la estrategia. Encapsular con una API puede resolverse en semanas; reconstruir por partes un sistema crítico se mide en meses o años. El primer paso siempre debería ser un diagnóstico que cuantifique el riesgo actual y compare las alternativas.

¿Se puede modernizar sin detener la operación?

Sí, y es el enfoque recomendado. El reemplazo progresivo permite que el sistema siga operando mientras se reconstruye módulo a módulo, con períodos de operación en paralelo y posibilidad de revertir cada paso.

¿Qué hago si nadie sabe cómo funciona el sistema?

Se reconstruye el conocimiento analizando el código y la base de datos, registrando el comportamiento en producción y entrevistando a los usuarios. Las pruebas escritas contra el comportamiento actual se convierten en la especificación del sistema nuevo.

¿Conviene reemplazarlo por un producto estándar?

Depende de si el sistema legado refleja un proceso genérico o uno propio del negocio. Si es genérico, el estándar suele ser mejor opción. Si contiene la forma particular en que la empresa opera, conviene evaluar un desarrollo a medida o una arquitectura híbrida.

¿Cuánto tiempo puedo seguir con el sistema actual?

Depende de qué señales de riesgo presenta. Si el riesgo es de seguridad o de continuidad —una sola persona lo sostiene, no recibe parches—, el plazo es corto y conviene actuar aunque el sistema funcione. Si es solo obsolescencia técnica sin impacto operativo, se puede planificar con calma.

Reduzcamos el riesgo antes que sea urgente

En Syscode acompañamos proyectos de modernización e integración de sistemas con enfoque progresivo: sin cortes abruptos y con reversibilidad en cada etapa.

Agenda un diagnóstico gratuito y evaluemos qué riesgo real tiene hoy tu sistema antiguo.