SOLUCIÓN · QA, PRUEBAS Y MANTENIMIENTO DE SOFTWARE

Rescate y mantenimiento de un sistema heredado

Rescatar un sistema heredado significa entenderlo, estabilizar lo crítico, protegerlo con pruebas y modernizarlo por partes, en lugar de tirarlo y empezar de cero. Si el desarrollador que lo hizo ya no está, no hay documentación y cada cambio rompe otra cosa, empiezo con un diagnóstico que te dice qué mantener, qué arreglar y qué conviene reemplazar.

01 / EL PROBLEMA

Lo que pasa hoy

Muchos negocios dependen de un sistema hecho a la medida hace años: el control de pedidos, la facturación interna, el sistema de la bodega. Funciona, más o menos, pero nadie entiende bien cómo. Quien lo hizo ya no está, no hay pruebas ni documentación, el entorno para desarrollarlo solo existía en la computadora de esa persona y las dependencias tienen años sin actualizarse.

Cada cambio da miedo, y con razón: se corrige un reporte y deja de funcionar la captura de pedidos; se actualiza una librería y el sistema no arranca. Así que se deja de tocar. Las mejoras que el negocio necesita se postergan, los errores conocidos se rodean con trucos manuales y el sistema se vuelve un riesgo que todos conocen y nadie atiende.

El riesgo más serio suele ser la seguridad. Las tecnologías sin soporte no reciben parches, y las dependencias viejas acumulan vulnerabilidades conocidas y públicas. Un sistema expuesto a internet con esas condiciones es una puerta abierta, aunque «siempre haya funcionado».

Rehacerlo desde cero parece la solución limpia, pero es caro, tarda más de lo previsto y corre un riesgo grande: perder reglas de negocio que solo existen en el código viejo, que nadie documentó y que alguien descubrirá cuando falten. La alternativa sensata casi siempre empieza por rescatar: entender, estabilizar, proteger con pruebas y modernizar por partes.

02 / ENFOQUE

Cómo lo resolvería

  1. 01

    Diagnóstico técnico

    Reviso la estructura del código, las dependencias y sus vulnerabilidades conocidas, la base de datos, cómo se despliega y dónde corre. Uso análisis estático para detectar riesgos de seguridad y deuda técnica, el mismo enfoque de ScriptC. Trabajo con acceso de solo lectura y una copia de los datos.

  2. 02

    Respaldar y estabilizar lo urgente

    Antes de tocar nada, me aseguro de que existan respaldos restaurables del código, la configuración y la base de datos. Después corrijo los errores críticos y los riesgos de seguridad más graves, uno por uno y con pruebas.

  3. 03

    Documentar y proteger con pruebas

    Documento cómo funciona el sistema, dónde vive cada regla de negocio y cómo se despliega. Agrego pruebas sobre los flujos críticos para que cualquier cambio posterior se haga con una red de seguridad, y dejo un entorno de desarrollo reproducible con Docker.

  4. 04

    Decidir módulo por módulo

    No todo el sistema tiene el mismo destino. Algunos módulos se mantienen y solo se encapsulan; otros se actualizan a versiones con soporte; otros conviene reemplazarlos poco a poco por piezas nuevas que conviven con las viejas hasta sustituirlas, sin detener la operación.

  5. 05

    Plan de evolución y mantenimiento

    Te entrego una recomendación clara y priorizada: qué mantener, qué actualizar y qué reemplazar, con riesgos y orden sugerido. Si lo necesitas, quedamos con un esquema de mantenimiento mensual para errores, actualizaciones y mejoras pequeñas.

03 / EJEMPLO

Ejemplo de diagnóstico inicial de dos semanas

  1. Acceso de solo lectura al repositorio, al servidor y a una copia de la base de datos.
  2. Inventario de tecnologías, versiones y dependencias con vulnerabilidades conocidas.
  3. Prueba de que los respaldos existen y se pueden restaurar.
  4. Mapa de los flujos principales y dónde vive cada regla de negocio.
  5. Lista priorizada de riesgos y errores, con impacto y esfuerzo estimado.
  6. Propuesta de estabilización inmediata y de evolución por etapas, con la decisión de arreglar o rehacer por módulo.
HERRAMIENTAS
Herramientas SAST (Semgrep y similares)Auditoría de dependenciasGitDockerNode.js / Python / PHP / SQLGitHub Actions
PRUEBAS

Trabajo relacionado

GUÍAS

Para profundizar

Preguntas frecuentes

¿Conviene arreglar o rehacer mi sistema desde cero?

Normalmente conviene decidirlo después del diagnóstico y módulo por módulo. Si los problemas se concentran en partes concretas y la base es razonable, arreglar y modernizar por partes es más barato y seguro. Si la tecnología ya no tiene soporte, cada cambio rompe algo distinto y el costo de mantenerlo supera el de reemplazarlo, conviene rehacer por etapas, conservando las reglas de negocio que hoy solo viven en el código.

¿Trabajas con cualquier tecnología?

Me desenvuelvo mejor en JavaScript/TypeScript, Python, PHP y SQL; trabajé con PHP y SQL en un sistema transaccional en Faena Uniformes. Si tu sistema está en otra tecnología, el diagnóstico te dirá con honestidad si soy la persona indicada para mantenerlo o si conviene buscar a alguien con esa especialidad.

¿Puedo seguir operando mientras se rescata el sistema?

Sí, ese es el objetivo. El trabajo se hace en un entorno de desarrollo separado, con respaldos y pruebas, y los cambios se publican en ventanas acordadas. Reemplazar módulos poco a poco permite que el sistema viejo y las piezas nuevas convivan sin detener la operación.

¿Qué recibo al terminar el diagnóstico?

Un documento con el estado del sistema, los riesgos priorizados, la recomendación por módulo (mantener, actualizar o reemplazar) y una propuesta de etapas con su alcance. Ese documento es tuyo y te sirve aunque decidas hacer el trabajo con otra persona.

¿Cuánto cuesta rescatar un sistema heredado?

El diagnóstico es un trabajo acotado y es lo primero que conviene hacer, porque sin él cualquier presupuesto de rescate o reescritura es una apuesta. Después, el costo depende del tamaño del sistema, del estado del código, de los riesgos de seguridad encontrados y de cuántos módulos se decida actualizar o reemplazar. Se presupuesta por etapas, empezando por lo urgente.

¿Ofreces mantenimiento continuo?

Sí. Después del rescate se puede acordar un esquema de mantenimiento, normalmente una bolsa de horas mensual, para actualizaciones de seguridad, correcciones y mejoras pequeñas. El costo depende del tamaño del sistema y de la frecuencia de cambios.

¿Lo platicamos?

Si tu caso se parece, cuéntame cómo trabajas hoy. Te digo qué parte conviene automatizar o construir primero.