¿Qué es un sistema legacy?
Un sistema legacy es software del que tu negocio sigue dependiendo pero que ya no se puede cambiar con seguridad: la tecnología perdió el soporte del fabricante, la gente que lo entendía se fue, o cada modificación arriesga romper algo que nadie sabe predecir. La edad por sí sola no convierte un sistema en legacy; el riesgo de tocarlo, sí.
La escala del problema es registro público. La Oficina de Rendición de Cuentas del Gobierno de EE. UU. (GAO) encontró sistemas federales críticos de hasta 60 años todavía en producción, y las agencias federales dedican cerca del 80% de su gasto en IT a operar y mantener lo que ya existe, según el informe GAO-25-107795. Doomity, firma de desarrollo de software con clientes en EE. UU., Reino Unido, España y Portugal, moderniza sistemas legacy sin reescrituras big-bang — este glosario explica qué cubre el término en realidad.
Actualizado: agosto de 2026
¿Por qué un sistema que funciona acaba convertido en legacy?
Por deriva, no por decisión. Una versión del framework llega a su fin de vida y la actualización se pospone. El desarrollador que sabía por qué el módulo de facturación funciona así se marcha. Un apaño rápido acaba sosteniendo media operación. Cada elección fue razonable; la suma es un sistema que nadie se atreve a tocar.
El mecanismo detrás de esa deriva tiene nombre: deuda técnica. La deuda es el coste acumulado de las decisiones de ingeniería aplazadas — legacy es donde aterriza un sistema cuando esa deuda se capitaliza más allá del punto de cambio seguro. Doomity trata ambas como un solo diagnóstico: no se puede presupuestar una modernización sin mapear antes la deuda que la causó.
¿Cuáles son las señales de que tu sistema ya es legacy?
Seis señales se repiten tanto en las evaluaciones de legacy de Doomity que sirven de autotest. Una es una molestia; tres o más son un diagnóstico:
- Nadie quiere desplegar. Las releases se programan como una operación quirúrgica, porque el último deploy despreocupado causó una caída que alguien aún recuerda.
- Quien lo construyó ya no está. El proveedor cerró, la agencia pasó página o el único desarrollador que lo entendía se fue — y se llevó el mapa mental.
- El stack perdió el soporte de seguridad. VB6, Access clásico, AngularJS, Delphi antiguo o frameworks sin parches: no habrá más arreglos, llegue el CVE que llegue.
- Los cambios pequeños cuestan semanas. Añadir un campo toca cinco módulos, y la estimación de cualquier cosa es «depende».
- El conocimiento vive en una cabeza. Una sola persona sabe levantar el sistema cuando se cae — y esa persona tiene vacaciones, preaviso y valor de mercado.
- Las integraciones van con apaños. Exportaciones manuales, macros de hoja de cálculo y copia-pega programado sostienen los flujos de datos.
El diagnóstico legacy gratuito en /es/herramientas/diagnostico-legacy convierte estas señales en un autotest de diez preguntas con veredicto puntuado.
¿Es lo mismo un sistema legacy que un sistema viejo?
No — y la diferencia decide el presupuesto. Código antiguo con soporte, entendido y probado es solo software maduro. Doomity ha visto sistemas de 20 años en plena forma, y microservicios de hace tres que ya eran legacy porque el equipo que los construyó se disolvió:
| Dimensión | Sistema viejo que funciona | Sistema legacy |
|---|---|---|
| Edad | Alta — e irrelevante | Cualquiera — con tres años basta |
| Soporte y parches | El stack sigue recibiendo arreglos de seguridad | Componentes en fin de vida, CVEs conocidos sin parchear |
| Conocimiento del equipo | Documentado, compartido, sobrevive a una baja | Concentrado en una persona, o perdido |
| Coste y riesgo de cambiar | Proporcional al cambio | Desproporcionado — cada cambio arriesga el conjunto |
| Qué hacer | Seguir manteniéndolo; eso es el éxito | Evaluar, estabilizar, modernizar por partes |
¿Cuáles son ejemplos reales de sistemas legacy?
Los ejemplos mejor documentados son públicos: las oficinas de auditoría gubernamentales publican la edad, el lenguaje y el riesgo de los sistemas que inspeccionan, lo que los hace verificables como ninguna anécdota del sector privado. Cuatro destacan:
- El Individual Master File del IRS. La fuente de datos autoritativa de las cuentas fiscales individuales de EE. UU. es una aplicación de 60 años escrita en un lenguaje arcaico, y el IRS lleva más de una década intentando sustituirla, según el informe GAO-23-104719. Cada devolución de impuestos individual en EE. UU. sigue dependiendo de ella.
- El sistema de coordinación nuclear del Pentágono. La GAO documentó en el informe GAO-16-468 (2016) que el Strategic Automated Command and Control System — que coordina las funciones operativas de las fuerzas nucleares de EE. UU. — seguía funcionando sobre un ordenador IBM Series/1 de los años 70 y disquetes de 8 pulgadas.
- Un sistema del Tesoro de 51 años en COBOL. Entre los sistemas críticos del informe GAO-25-107795 hay un sistema del Departamento del Tesoro que tras 51 años en producción sigue ejecutándose en COBOL y lenguaje ensamblador — lenguajes con cada vez menos gente capaz de mantenerlos.
- El 28% de los sistemas del gobierno central británico. La propia State of digital government review del gobierno del Reino Unido (enero de 2025) estimó que el 28% de los sistemas de los departamentos del gobierno central eran legacy en 2024 — frente al 26% del año anterior.
El patrón que Doomity encuentra en las evaluaciones del sector privado es el mismo a menor escala — ERPs sin soporte, bases de datos Access, herramientas VB6 sosteniendo la operación diaria — con una diferencia: ningún auditor publica un informe, así que el riesgo permanece invisible hasta que estalla.
¿Qué riesgos reales carga un sistema legacy?
Tres, en orden creciente de visibilidad. Seguridad: los componentes en fin de vida acumulan vulnerabilidades conocidas sin parche a la vista. Continuidad: el sistema depende de hardware, licencias o una persona que pueden desaparecer cualquier trimestre. Y el coste de oportunidad — el más silencioso: el estudio de McKinsey y Oxford sobre 5.400 proyectos de TI concluyó que los grandes proyectos superan el presupuesto en un 45% y entregan un 56% menos de valor del prometido, y el informe DORA 2025 conecta la baja capacidad de entrega justo con el miedo al cambio que un legacy institucionaliza. Un sistema que no puedes cambiar con seguridad es una estrategia que no puedes ejecutar.
¿Hay que reescribir un sistema legacy para arreglarlo?
No — y el reflejo de la reescritura total es como un sistema legacy se convierte en dos sistemas y un proyecto de migración. La alternativa que Doomity defiende es la modernización incremental: estabilizar lo frágil, envolver lo que funciona tras interfaces limpias y sustituir componentes por rebanadas que entregan valor mientras el sistema viejo sigue operando. El marco para decidir entre ambos caminos está en reescribir vs refactorizar.
Doomity ejecuta la modernización legacy como encargo de alcance cerrado que empieza por una evaluación, no por un presupuesto. Sus ingenieros vienen de equipos que construyeron para Holcim, Canon España e Indra — organizaciones donde el sistema legacy ERA el negocio — y su proceso de entrega integra IA: hasta un 40% más rápido, con cada hallazgo verificado por un ingeniero senior.
FAQ
En informática, legacy (heredado) significa software del que una organización sigue dependiendo pero que ya no puede cambiar con seguridad: el fabricante retiró el soporte, los desarrolladores originales se fueron o cada modificación arriesga romper algo imprevisible. El término describe riesgo, no edad: un sistema de tres años puede ser legacy y uno de veinte no serlo.
El Individual Master File del IRS es el ejemplo clásico: una aplicación de 60 años que sigue siendo la fuente autoritativa de las cuentas fiscales individuales de EE. UU., según auditorías de la GAO. La GAO también documentó un sistema del Tesoro de 51 años en COBOL y, en 2016, un sistema de coordinación nuclear del Pentágono con disquetes de 8 pulgadas. La mayoría de empresas tiene equivalentes menores: ERPs sin soporte, bases de datos Access, herramientas VB6.
No hay umbral oficial: el test práctico es si puedes cambiarlo con seguridad. Si el stack recibe parches, el equipo entiende el código y un deploy es rutina, no es legacy tenga la edad que tenga. Si los cambios dan miedo, el conocimiento está en una sola cabeza o el soporte terminó, es legacy aunque se lanzara hace tres años.
Que funcione hoy no es la métrica — la métrica es qué pasa cuando llegue el cambio: un parche de seguridad que no puedes aplicar, una normativa, la integración que exige un cliente grande o la dimisión de la persona clave. Modernizar es más barato mientras el sistema está estable y el conocimiento sigue en la empresa. Se encarece exactamente cuando se vuelve urgente.
Normalmente más de lo que sus dueños temen. Las reglas de negocio codificadas en un legacy son el activo más valioso y más difícil de recuperar que tiene una empresa: sobrevivieron a años de operación real. La modernización conserva esas reglas y sustituye la carcasa frágil que las rodea — frameworks sin soporte, dependencias muertas, integraciones sin documentar. Tirarlo todo es pagar por redescubrir tus propias reglas.
Por una evaluación, no por una propuesta. El diagnóstico legacy gratuito de Doomity en /es/herramientas/diagnostico-legacy da una primera señal puntuada en tres minutos. El siguiente paso, si procede, es una evaluación técnica de alcance cerrado que mapea riesgo, dependencias y concentración de conocimiento — y sales con un plan, lo ejecute Doomity o no.
Si tres o más de las seis señales te suenan a tu sistema, el paso útil es una evaluación que mapee qué es frágil, qué es valioso y en qué orden arreglarlo — antes de que llegue el cambio que no se puede posponer.