Sistema legacy: ¿mantener, modernizar o reemplazar? La guía del founder no técnico

Un sistema legacy no es cuestión de edad, es cuestión de riesgo. Cómo diagnosticar el tuyo con cuatro preguntas y elegir entre mantener, encapsular, modernizar por partes o reemplazar.

El año pasado hablamos con el COO de una distribuidora en el interior de São Paulo, 40 empleados, operación rentable. Toda la facturación de la empresa pasaba por un sistema que un desarrollador freelance construyó en 2018. El desarrollador se fue en 2021. Desde entonces, nadie ha tocado una línea. Cuando Pix, la red de pagos instantáneos de Brasil, cambió una regla de conciliación, el equipo empezó a corregir los asientos a mano, todos los días, porque tocar el código se consideraba demasiado arriesgado. El sistema funcionaba. Y mandaba en la empresa. Era un sistema legacy en todos los sentidos que importan.

Un sistema legacy no es solo el mainframe bancario corriendo COBOL desde 1985. Es también el software de hace siete años que ya nadie sabe modificar con seguridad. Si fundaste u operas una empresa de 5 a 50 personas, tu versión del problema se parece mucho más a la distribuidora que al banco.

Esta guía define qué es realmente un sistema legacy, muestra cómo aparece en una empresa pequeña, cuánto cuesta convivir con uno, y ordena la decisión que importa: mantener, encapsular, modernizar por partes o reemplazar.

Qué es un sistema legacy

Un sistema legacy es un software que sigue en operación porque el negocio depende de él, pero cuya tecnología, arquitectura o falta de documentación hacen que cualquier cambio sea arriesgado y caro. La parte importante de esa definición está en la segunda mitad. La edad no es el criterio. El riesgo sí.

Un sistema de 15 años, bien documentado, con tests y con dos personas que lo conocen a fondo, no es legacy en el sentido que importa. Una app de 3 años hecha a las prisas en una plataforma no-code, sin documentación, cuyo único autor ya dejó la empresa, es profundamente legacy. El término describe una relación entre el sistema y tu capacidad de cambiarlo, no una fecha de nacimiento.

El test práctico es una pregunta: si el negocio necesitara que este sistema cambie antes de fin de trimestre, ¿alguien podría hacerlo con confianza? Si la respuesta incluye un suspiro, tienes un sistema legacy.

Vale la pena separar el concepto de un vecino cercano: la deuda técnica es el conjunto de atajos acumulados dentro de un sistema que alguien todavía mantiene. El sistema legacy es la etapa siguiente, cuando la capacidad de mantener se perdió. Toda empresa carga deuda técnica; no toda empresa carga un legacy. Escribimos una guía aparte sobre cómo diagnosticar la deuda técnica antes de que llegue a esa etapa.

Cómo un sistema se vuelve legacy en una empresa pequeña

En las empresas que atendemos, de 5 a 50 personas, el legacy casi nunca nace de una mala decisión. Nace de tres patrones, todos racionales en su momento.

El freelancer que se fue. El patrón de la distribuidora. Un desarrollador competente construye el sistema, la empresa crece encima de él, el desarrollador sigue su camino. El código puede incluso ser bueno. Irrelevante: nadie más puede leer las decisiones que viven solo en su cabeza. La empresa no perdió un proveedor, perdió el acceso a su propio sistema. Este caso es tan común que le dedicamos una guía entera al bus factor, el riesgo de que un único dev sostenga el codebase.

El no-code que se osificó. Bubble, Glide, una planilla llena de macros, Zapier apilado. Herramientas excelentes para validar; pésimas para olvidarlas en producción durante cuatro años. El costo de la plataforma sube con el uso, los workarounds se acumulan, y un día la “automatización provisoria” es el sistema de operaciones de la empresa, y nadie recuerda por qué existe la regla de la celda G14.

El ERP customizado de 2018. La empresa contrató una consultora para adaptar un ERP de estantería. La consultora entregó y salió de escena. Las customizaciones nunca se documentaron, la versión del ERP se congeló (actualizar las rompería), y ahora el proveedor cobra caro por tocar lo que la propia empresa pagó por construir.

En los tres patrones la secuencia es la misma: el sistema fue la decisión correcta cuando se hizo, el negocio cambió, y la capacidad de cambiar el sistema no acompañó. Legacy es el nombre de ese desfase.

Cuánto cuesta convivir con un legacy

El argumento para no tocarlo es siempre el mismo: “funciona”. Es verdad, y por eso el costo del legacy engaña. No aparece como una factura. Aparece repartido en cuatro líneas que nadie suma.

El impuesto de integración. Cada herramienta nueva necesita hablar con el sistema viejo, y no habla. Entonces la conversación se vuelve gente: alguien exporta un CSV, alguien vuelve a digitar, alguien revisa. En la distribuidora eran tres horas por día de conciliación manual. Doce mil reales al mes de salario haciendo el trabajo que haría una integración, sin aparecer en ningún reporte como costo del sistema.

El impuesto de contratación. Los buenos desarrolladores evitan stacks muertas y código sin documentación. Cuando finalmente decides contratar a alguien para cuidar el sistema, descubres que el mercado cobra una prima por heredar un problema, cuando acepta heredarlo.

El riesgo concentrado. La pregunta que le hacemos a todo operador en esta situación: ¿qué pasa con la operación si el sistema se cae un viernes y queda fuera 48 horas? Si la respuesta es “se detiene todo”, el sistema es un punto único de falla sin plan de recuperación. Ese riesgo no cuesta nada por mes. Cuesta todo, una vez.

El costo de oportunidad. La funcionalidad que no se puede lanzar, el canal de venta que no se puede integrar, el reporte que pidió el inversionista y que toma una semana armar a mano. Es el costo más difícil de medir y casi siempre el mayor.

El patrón no es exclusivo de las empresas pequeñas. La GAO, el tribunal de cuentas de Estados Unidos, audita hace años los sistemas legacy del gobierno federal y encontró sistemas críticos con más de 50 años, consumiendo la mayor parte del presupuesto de TI solo para seguir en pie. La escala es otra; la mecánica, el dinero yendo a mantener en vez de evolucionar, es idéntica.

Si quieres profundizar en la parte recurrente de esa cuenta, nuestra guía de costo de mantenimiento de software desmenuza lo que se paga después del lanzamiento.

El diagnóstico: cuatro preguntas antes de decidir el camino

No necesitas una auditoría de seis meses para saber el tamaño del problema. Necesitas respuestas honestas a cuatro preguntas. Convoca al equipo de operaciones, no solo al de tecnología, y responde por escrito.

1. ¿El sistema atiende el proceso, o el proceso se contorsiona para atender al sistema? Cuenta los workarounds: planillas paralelas, redigitación, “eso lo resolvemos por WhatsApp”. Cada workaround es el proceso cediendo. Hasta dos, convive. Por encima de eso, el sistema está dictando cómo trabaja la empresa.

2. ¿Cuántas personas pueden modificar el sistema con seguridad? Dos o más: tienes mantenimiento. Una: tienes un riesgo con plazo indefinido. Cero: no tienes un sistema, tienes una caja sellada de la que depende la operación.

3. ¿Qué pasa si se cae por 48 horas? Si existe un contorno manual razonable, el riesgo es administrable. Si la empresa deja de facturar, la respuesta define la urgencia independientemente de las otras tres.

4. ¿Cuánto cuesta por año mantenerlo vivo, sumando los impuestos invisibles? Licencias y servidor, más las horas de trabajo manual que genera, más la prima que pagas por soporte. La mayoría de los operadores nunca hizo la suma. La suma suele decidir la conversación.

Dos respuestas malas o más: sigue leyendo. Las cuatro tranquilas: tu sistema es viejo, no es legacy. Guarda esta guía para dentro de dos años.

Los cuatro caminos: mantener, encapsular, modernizar por partes, reemplazar

Todo proveedor que consultes va a recomendar el camino que vende. La consultora de integración recomienda integrar, la software house de reescritura recomienda reescribir, el vendedor de ERP recomienda su ERP. Ninguno de los cuatro caminos es correcto en general. Cada uno es correcto para un diagnóstico.

Mantener, deliberadamente. Si el sistema es estable, el riesgo está concentrado en personas y no en tecnología, y el negocio no pide cambios frecuentes, la respuesta correcta puede ser no tocar la arquitectura y atacar solo el riesgo: documentar lo que existe, garantizar backups y un ambiente de recuperación probados, y tener más de una persona (interna o socia) capaz de operar el código. Es el camino más barato y el más subestimado, porque no tiene proveedor hinchando por él.

Encapsular e integrar. El sistema sigue siendo el motor, pero deja de ser la pared. Se construye una capa por encima, generalmente APIs o servicios pequeños alrededor, que deja que las herramientas nuevas hablen con él sin que nadie toque sus entrañas. Resuelve el impuesto de integración sin el riesgo de un cambio de motor. El límite: el encapsulamiento no rejuvenece el núcleo. Si el núcleo necesita cambiar con frecuencia, esto solo compra tiempo, lo que, en muchos casos, es exactamente lo que se quiere comprar.

Modernizar por partes. Sustituir el sistema por partes, empezando por las áreas de mayor fricción, con el sistema viejo y el nuevo conviviendo durante la transición. Es el patrón que Martin Fowler bautizó como strangler fig, la higuera que crece alrededor del árbol hasta sustituirlo. La virtud es el riesgo diluido: cada etapa entrega valor y puede interrumpirse sin desastre. El precio es gestión: convivir con dos sistemas exige disciplina de alcance, y los proyectos sin dueño claro degeneran en tres sistemas.

Reemplazar de una vez. La reescritura completa. Existen casos donde es el camino correcto: la plataforma va a ser descontinuada, el costo de mantener superó el de rehacer, o el diagnóstico de la pregunta 3 dio “se detiene todo” sin contorno. Pero es el camino más arriesgado de los cuatro, y suele llegar a la mesa demasiado temprano, empaquetado como inevitable. Antes de firmar cualquier propuesta de reescritura, lee nuestra guía sobre por qué la reescritura de software es casi siempre la pregunta equivocada, existe exactamente para ese momento.

La regla práctica que usamos con clientes: empieza por el camino más barato que resuelva el riesgo señalado en el diagnóstico, no por el más completo. Se puede subir de escalón después; bajar es caro.

El error más caro: tratar la decisión como técnica

La trampa final no está en los caminos, está en quién decide. Los operadores no técnicos tienden a delegar esta decisión entera “a quien entiende”, y quien entiende casi siempre tiene un sesgo: el dev interno prefiere reescribir (nadie sueña con mantener código ajeno), el proveedor prefiere el proyecto más grande, la consultora prefiere la herramienta de la casa.

La decisión sobre un sistema legacy es una decisión de negocio con insumos técnicos, de la misma familia que build vs buy y que contratar adentro o afuera. El diagnóstico de las cuatro preguntas es deliberadamente no técnico porque quien tiene que responderlas es quien siente el costo: tú. El papel del socio técnico es dar opciones con precios y riesgos honestos dentro de cada camino, no elegir el destino.

Es el tipo de conversación que separa a un socio de un proveedor: el socio muestra el trade-off, el proveedor muestra la propuesta.

Preguntas frecuentes

¿Qué es un sistema legacy?
Es un software que sigue en operación porque el negocio depende de él, pero cuya tecnología, arquitectura o falta de documentación hacen que los cambios sean arriesgados y caros. El criterio no es la edad del sistema, es la capacidad (perdida) de cambiarlo con seguridad.

¿Qué es un programa legacy?
El mismo concepto a nivel de una aplicación específica: un programa que sigue en uso, pero que nadie puede actualizar con seguridad, sea por falta de documentación, por depender de tecnología descontinuada o porque quien lo construyó ya no está disponible.

¿Qué es un modelo legacy?
El término aparece en dos sentidos: un modelo de datos antiguo que los sistemas nuevos deben respetar para hablar con el legacy, y, más recientemente, versiones antiguas de modelos de IA mantenidas en producción. En ambos, la lógica es la misma del sistema legacy: algo viejo que permanece porque cambiarlo cuesta más que convivir con él, hasta que deja de costar.

¿Un sistema legacy es siempre malo? ¿Cuándo vale la pena reemplazarlo?
No. Un sistema viejo, estable y que atiende el proceso es un activo, no un problema. Vale la pena actuar cuando el diagnóstico muestra riesgo concentrado (una o cero personas capaces de mantenerlo), workarounds multiplicándose o un costo anual invisible mayor que el de modernizar. Y reemplazar de una vez es el último camino a considerar, después de mantener, encapsular y modernizar por partes.