Modernizar un sistema legacy sin frenar la operación

Casi toda empresa con más de diez años tiene uno: un sistema que funciona, que nadie quiere tocar, que hizo el sobrino de un socio o una empresa que ya no existe, y del que depende algo importante. Anda. Y cada vez que hay que cambiarle algo, alguien dice "cuidado con eso".

La tentación es tirarlo y hacerlo de nuevo. Es, casi siempre, la peor decisión disponible. Esta nota explica por qué, qué alternativas hay, cuánto cuesta cada una y cómo decidir cuál corresponde.

Por qué reescribir de cero sale mal

La reescritura completa es la estrategia más intuitiva y la que más proyectos fracasados produce. Las razones son estructurales, no de ejecución.

El sistema viejo sabe cosas que nadie escribió. Diez años de operación dejaron adentro decenas de reglas que nunca se documentaron: el descuento especial de un cliente, la validación que se agregó porque una vez pasó algo, el caso raro de fin de mes. Nadie las recuerda todas. Aparecen de a una, en producción, cuando el sistema nuevo ya reemplazó al viejo.

Durante la reescritura, la empresa no puede detenerse. El sistema viejo sigue necesitando cambios mientras se construye el nuevo. Terminás manteniendo dos sistemas y pagando dos veces.

No entregás valor hasta el final. Una reescritura de doce meses son doce meses de gasto sin ningún beneficio, y con una fecha de corte donde todo cambia de golpe. Si esa fecha se corre —y se corre—, el proyecto empieza a perder apoyo interno justo cuando más lo necesita.

El día del cambio es un evento de riesgo alto. Todo el mundo aprende un sistema nuevo al mismo tiempo, con la operación corriendo.

Esto no significa que reescribir esté siempre mal. Significa que es la opción más cara y más riesgosa, y que sólo se justifica cuando las otras no aplican.

Las cinco estrategias, de menor a mayor riesgo

1. No tocarlo

Es una opción legítima y se descarta demasiado rápido. Si el sistema funciona, cubre lo que tiene que cubrir y no hay un requerimiento nuevo importante, modernizarlo es gastar plata en un problema que no tenés.

Cuándo aplica: el sistema es estable, hay quien lo pueda mantener, no tiene problemas de seguridad graves, y no bloquea ninguna iniciativa del negocio.

2. Actualizar la infraestructura sin tocar el sistema

Muchas veces el problema no es el software sino dónde está corriendo: un servidor físico en la oficina, un sistema operativo sin soporte, una base de datos en una versión que ya no recibe parches de seguridad.

Mover el mismo sistema a infraestructura moderna, agregarle respaldos automáticos y monitoreo resuelve el riesgo más urgente —que es perder los datos o quedar expuesto— sin tocar una línea de código.

Costo típico: USD 2.000 a 6.000. Es la intervención con mejor relación riesgo-beneficio que existe y casi siempre es el primer paso correcto.

3. Ponerle una API adelante

El sistema viejo queda intacto, pero se le construye una capa que expone sus datos y sus operaciones de forma moderna. A partir de ahí, todo lo nuevo se construye contra esa capa.

Esto es lo que desbloquea la mayoría de las situaciones. Podés tener una app móvil, un portal para clientes, un tablero, o integrar con otro sistema, sin haber tocado el núcleo.

Cuándo aplica: el sistema viejo hace bien lo que hace, pero está encerrado y no se puede conectar con nada.

Costo típico: USD 5.000 a 15.000, según lo accesible que sea la base de datos del sistema viejo.

4. Reemplazo por partes

La estrategia que funciona cuando hay que reemplazar de verdad. Se elige un módulo, se construye su versión nueva, se pone en producción, y el sistema viejo deja de ocuparse de eso. Después el siguiente.

Durante la transición conviven los dos, con la capa de integración manteniéndolos sincronizados. Es más trabajo total que una reescritura de una sola vez, y es sustancialmente menos riesgoso: cada paso entrega valor, cada paso se puede revertir, y si el presupuesto se corta a mitad de camino, lo que ya se hizo sigue sirviendo.

Por dónde empezar: por el módulo más independiente, no por el más importante. Necesitás que el primer reemplazo salga bien para construir confianza interna.

Costo: el del sistema nuevo, pero repartido en el tiempo, más entre un 15% y un 25% extra por el trabajo de convivencia.

5. Reescritura completa

Cuándo se justifica de verdad:

• El sistema corre sobre tecnología para la que ya no conseguís a nadie que la mantenga.
• El modelo de datos es tan inadecuado para el negocio actual que cualquier cambio requiere rehacerlo igual.
• Hay un requerimiento legal o de seguridad que el sistema no puede cumplir de ninguna forma.
• El negocio cambió tanto que el sistema modela una empresa que ya no existe.

Si ninguna de esas cuatro aplica, probablemente lo que necesites sea alguna de las opciones anteriores.

Cómo se toma la decisión

Cinco preguntas, en orden.

1. ¿Qué problema concreto tenés hoy?

"Es viejo" no es un problema. "No podemos facturar electrónicamente", "se cae dos veces por mes", "no podemos darle acceso a los clientes", "el que lo mantenía se jubiló" sí lo son. Si no podés nombrar el problema, la respuesta es no tocarlo.

2. ¿Cuánto te cuesta hoy no resolverlo?

Horas perdidas, ventas que no se hacen, multas, riesgo de perder datos. Si el costo anual de no hacer nada es menor que el proyecto, no hay caso todavía.

3. ¿Alguien puede mantener el sistema actual?

Si la respuesta es una sola persona, tenés un riesgo de continuidad que es independiente de la tecnología. Y si esa persona es externa, es más urgente de lo que parece.

4. ¿La base de datos es accesible?

Es la pregunta técnica que más cambia el plan. Si se puede leer la base directamente, casi todas las estrategias intermedias están disponibles. Si el sistema es una caja negra sin acceso a los datos, las opciones se reducen mucho y el costo sube.

5. ¿Está documentado lo que el sistema hace?

Si no, el primer entregable de cualquier proyecto tiene que ser documentarlo. Y tiene valor por sí mismo, decidas después lo que decidas.

Lo que hay que hacer antes de cualquier cosa

Independientemente de la estrategia, hay tres cosas que conviene resolver primero porque son baratas y bajan el riesgo de inmediato:

Respaldos automáticos y probados. No alcanza con que exista el respaldo: hay que haber probado restaurarlo. Un respaldo que nunca se restauró es una hipótesis, no un respaldo.

Documentar el comportamiento actual. No el código: lo que el sistema hace. Qué procesos cubre, qué reglas aplica, qué reportes emite, quién lo usa y para qué. Se hace entrevistando a los usuarios, no leyendo el código, y es el insumo de cualquier proyecto posterior.

Inventario de integraciones. Con qué se conecta, qué archivos exporta, qué otro sistema depende de él. Es muy común descubrir a mitad de proyecto que un tercero consume un archivo que el sistema genera todas las noches y que nadie recordaba.

El error de gestión más común

Presentar la modernización como un proyecto técnico. "Hay que actualizar el sistema" no consigue presupuesto ni prioridad, porque no responde a ninguna pregunta que se haga la dirección.

Lo que sí funciona es atarlo a algo que la empresa quiere hacer y hoy no puede: dar acceso a los clientes, abrir una sucursal, integrar un canal de venta, cumplir un requisito de un cliente grande. La modernización deja de ser un costo de mantenimiento y pasa a ser el habilitador de algo con valor.

Además, esa forma de plantearlo tiene un efecto práctico: define el alcance. En vez de "modernizar el sistema", que no tiene borde, el proyecto pasa a ser "hacer posible X", que sí lo tiene.

En resumen

La pregunta correcta no es "¿reescribo o no?". Es "¿cuál es la intervención más chica que resuelve el problema que tengo hoy?".

En la mayoría de los casos esa intervención es mover la infraestructura, asegurar los respaldos y ponerle una capa de integración adelante. Con eso el sistema viejo deja de ser un riesgo y deja de ser una jaula, por una fracción del costo de reescribirlo.

Y si después de eso todavía hace falta reemplazarlo, vas a poder hacerlo de a partes, con el sistema documentado y sin frenar la operación.