Software heredado sin documentación: qué hacer en dos semanas

Heredar un sistema crítico —el que factura, despacha o matricula— sin documentación y sin el desarrollador que lo escribió es más común de lo que parece. Esta guía sobre software heredado sin documentación propone un orden: asegurar el control en dos semanas, reconstruir lo que nadie escribió, medir el riesgo con fechas reales de soporte y elegir cómo modernizar sin detener la operación.

¿Por qué un sistema heredado sin documentación es un riesgo para el negocio?

Porque el conocimiento de cómo funciona vive en la cabeza de una persona que ya no está, y cada cambio se convierte en una apuesta. Un sistema heredado (o sistema legado) es el que sigue haciendo un trabajo crítico, pero está construido con tecnologías, versiones o prácticas que su equipo actual ya no domina.

Sin documentación pasan cuatro cosas a la vez: nadie sabe qué se rompe si algo cambia, los parches de seguridad se posponen por miedo, integrarlo con otros sistemas cuesta más de lo razonable y migrarlo parece imposible. Según Droptica, en su análisis de problemas del software heredado, sin pruebas automáticas cada cambio se prueba a mano y crece la dependencia de quien escribió el código.

Estas cifras miden otros contextos (gobierno de EE. UU., grandes empresas, encuestas). Sirven como orden de magnitud, no como pronóstico para su empresa.

• Gasto en lo que ya existe. El gobierno federal de EE. UU. gasta más de USD 100.000 millones al año en tecnología, y cerca del 80 % se va en operar y mantener sistemas existentes (GAO-25-107795, 17 de julio de 2025).
• Riesgo en lo más crítico. De los 11 sistemas heredados que la GAO juzgó más urgentes, siete tenían vulnerabilidades conocidas y ocho usaban lenguajes desactualizados (misma fuente).
• Deuda técnica. En una encuesta de 2020 a 50 CIO de grandes empresas, McKinsey halló que la estimaban entre 20 % y 40 % del valor de su parque tecnológico.
• Tiempo de desarrolladores. Stripe («The Developer Coefficient», septiembre de 2018) estimó más de 17 horas semanales de mantenimiento y depuración por desarrollador. Calculó además unos USD 85.000 millones al año en costo de oportunidad por «código malo». Es una estimación de encuesta, no una medición.

¿Qué hacer en las primeras dos semanas cuando el desarrollador se fue?

Asegurar control antes de entender: accesos, respaldo, código, entorno de pruebas e inventario, en ese orden. El objetivo de estas dos semanas no es mejorar el sistema, es poder tocarlo sin miedo y recuperarlo si algo falla.

1. Días 1 y 2: recupere accesos y titularidad. Liste dónde vive cada pieza: servidor o nube, dominio y DNS, base de datos, repositorio, correo transaccional, pasarelas de pago, certificados y licencias. Todo debe quedar a nombre de la empresa, no de la persona que se fue; cambie las contraseñas y active la verificación en dos pasos. Revise también en el contrato quién tiene los derechos sobre el código.
2. Días 2 a 4: haga un respaldo completo y pruébelo. Archivos, base de datos y configuración. Una copia que nunca se restauró es una suposición: levante el respaldo en otra máquina y compruebe que el sistema arranca.
3. Días 3 a 6: ponga el código en un repositorio con control de versiones. Si el código solo está en el servidor, cópielo tal como corre hoy y márquelo con una etiqueta de versión. Desde ahí, todo cambio queda registrado y se puede deshacer.
4. Días 5 a 8: levante un entorno de pruebas aislado. Una copia del sistema con datos anonimizados, sin conexión a pasarelas de pago ni a correos reales. Es el único lugar donde se puede experimentar.
5. Días 6 a 10: haga el inventario. Componentes y versiones, tareas programadas, integraciones con terceros, usuarios y permisos, certificados y dominios con fecha de vencimiento. Este inventario alimenta la evaluación de riesgo de la sección cuatro.
6. Días 8 a 10: entreviste a quienes lo usan. Soporte, contabilidad, operaciones, el proveedor de hosting. Pregunte qué hace el sistema que no se ve en pantalla: cierres de mes, correos automáticos, reportes que alguien pide cada viernes.

¿Cómo se documenta un sistema que nadie explicó?

Se reconstruye por ingeniería inversa desde cinco fuentes: la base de datos, el código, el historial de versiones, la ejecución real y las personas. Ninguna alcanza sola; juntas dibujan el sistema con bastante fidelidad.

• La base de datos. El esquema muestra qué entidades maneja el negocio (clientes, pedidos, matrículas) y cómo se relacionan. Un diagrama del esquema es el documento de mayor valor por hora invertida.
• El código. Rutas, módulos, tareas programadas y llamadas a servicios externos. El análisis estático ayuda a mapear dependencias y código muerto.
• El historial de versiones. Si existe, los mensajes de los cambios y las fechas cuentan por qué el sistema es como es.
• La ejecución real. Los registros (logs) y el tráfico en el entorno de pruebas muestran qué se usa de verdad y qué no se ha tocado en años.
• Las personas. Los usuarios veteranos conocen las reglas que el código esconde.

Las herramientas tienen un límite: leen el código, pero no saben si una lógica responde a un requisito regulatorio. Según In-Com, en su análisis del análisis estático en sistemas sin documentación, eso solo sale de la memoria de los usuarios veteranos. Por eso las entrevistas no son opcionales.

Pruebas que fijan el comportamiento actual

La forma más fiable de documentar es escribir pruebas que registren lo que el sistema hace hoy, incluso lo que parece un error. Funcionan como documentación ejecutable: cuando alguien cambie algo, la prueba avisa si el comportamiento cambió. Empiece por los flujos que mueven dinero.

El documento mínimo que conviene tener

No hace falta un manual de cientos de páginas. Un documento corto, que se mantiene vivo en el repositorio, cubre lo esencial: mapa de componentes, modelo de datos, tareas programadas, integraciones, reglas de negocio conocidas y cómo desplegar y restaurar el sistema.

¿Cómo evaluar el riesgo de un sistema heredado?

Combine dos preguntas: qué tan crítico es para la operación y qué tan expuesto está técnicamente. Lo más expuesto suele ser lo que corre sobre versiones que el fabricante ya no parchea, porque cualquier vulnerabilidad nueva queda abierta. La categoría «componentes vulnerables y desactualizados» figura en el OWASP Top 10 de 2021 (A06), y la primera defensa es saber qué versiones tiene.

La tabla recoge las fechas de fin de soporte de las tecnologías más comunes en sistemas heredados, consultadas el 9 de octubre de 2026. Confirme la fecha en la página del fabricante antes de decidir.

Fuentes de las fechas: php.net y las fichas de PHP, MySQL, SQL Server, .NET Framework, Oracle JDK y Windows Server en endoflife.date.

Con el inventario, cada componente cae en uno de cuatro cuadrantes: crítico y expuesto (actuar ya), crítico y vigente (planificar), poco crítico y expuesto (aislar o retirar) y poco crítico y vigente (dejar como está). Si necesita apoyo mientras decide, el servicio de soporte de TI cubre la operación diaria.

¿Qué opciones hay para la modernización de software heredado?

Siete, y no todas implican reescribir. La guía de migración de AWS describe las «7 R» (retire, retain, rehost, relocate, repurchase, replatform y refactor), y Microsoft Azure agrega la reconstrucción completa (rebuild). AWS también contempla «relocate», que aquí agrupamos con rehost. La tabla las ordena de menos a más cambio.

AWS advierte que refactorizar es la estrategia más compleja y costosa, y recomienda trasladar primero y modernizar después. Su guía lista entre los casos de refactor el sistema «que nadie sabe mantener», pero nuestro criterio es documentar antes de decidir: sin inventario ni pruebas, un cambio profundo se hace a ciegas.

Si la decisión pasa por cambiar o integrar un ERP, la guía hermana sobre integrar o cambiar de ERP desarrolla ese caso. Y si el cambio implica construir piezas nuevas, el artículo cuánto cuesta un software a la medida explica de qué depende la inversión.

¿Cómo modernizar sin detener la operación?

Construyendo las piezas nuevas junto al sistema viejo y desviando el tráfico hacia ellas poco a poco, un patrón conocido como strangler fig o «higuera estranguladora». Martin Fowler, que lo popularizó, describe la alternativa a la reescritura total como un proceso gradual de modernización: se añaden funciones nuevas al lado, se trasladan comportamientos de a uno y el sistema viejo se apaga cuando ya no queda nada que él haga.

1. Elija un corte pequeño y de valor. Un reporte, la facturación electrónica o un portal de clientes: algo con bordes claros y beneficio visible.
2. Ponga una capa de enrutamiento delante. Un proxy o una API decide si cada petición va al sistema viejo o al nuevo. Esa capa es la que permite cambiar sin que los usuarios lo noten; es parte de lo que se conoce como integración de sistemas.
3. Construya la pieza nueva contra las pruebas de comportamiento que escribió al documentar. Si la pieza nueva pasa las mismas pruebas, hace lo mismo que la vieja.
4. Corra ambas en paralelo y compare resultados durante un ciclo completo de negocio, por ejemplo un cierre de mes.
5. Desvíe el tráfico por tramos y deje la vía de retorno abierta. Un porcentaje pequeño primero, y vuelta atrás inmediata si algo falla.
6. Apague la parte vieja y repita con el siguiente corte.

El traslado a la nube encaja en este esquema. Migrar un sistema legado a la nube puede empezar como un rehost (el mismo sistema, otra infraestructura) y modernizarse por cortes después. Con ese paso conviene tener respaldos verificados, monitoreo y alguien responsable de la infraestructura; es lo que cubre el servicio de hosting y cloud gestionado. Para decidir qué asegurar durante el cambio, la guía de seguridad en el desarrollo de software repasa los controles básicos.

¿Qué pedirle a un socio externo antes de entregarle el sistema?

Que el código, los datos y la documentación queden a nombre de su empresa, y que cada entrega se pueda probar. Es la forma de no cambiar un desarrollador único por un proveedor único. Cinco puntos que conviene exigir por escrito:

• Titularidad. Código, repositorio, datos, dominio y cuentas de nube a nombre de la empresa.
• Documentación entregada, no prometida. Un entregable con fecha, revisado por su equipo.
• Entregas frecuentes y probables. Algo nuevo que probar cada semana, no un informe a los tres meses.
• Alcance, fechas e inversión por escrito antes de empezar, con un diagnóstico previo del sistema.
• Datos históricos verificados. Si se migran datos, que su equipo los revise antes de la salida en vivo.

Así lo plantea el equipo de ingeniería de software a la medida de Mtechnology: una entrega semanal que se prueba en el navegador y código y datos a nombre del cliente, «con documentación y entrega formal». Los datos históricos se verifican con su equipo antes de salir en vivo. El primer paso es un diagnóstico de 30 minutos, sin costo.

Un sistema sin documentación se recupera en orden: control en dos semanas, conocimiento reconstruido por fuentes, riesgo medido con fechas del fabricante y modernización por cortes. Ningún paso exige entenderlo todo de entrada; exige poder recuperarlo, probarlo y cambiarlo sin detener la operación.