Qué reviso antes de heredar un sistema en producción

El escenario más común, y el menos discutido

Casi todo el contenido técnico que circula asume que empiezas de cero: arquitectura limpia, decisiones frescas, cero deuda. Pero la mayoría del trabajo serio de software no es así. Es entrar a un sistema que ya lleva años operando, que ya tiene usuarios reales, dinero real moviéndose, y que no se puede apagar mientras lo arreglas.

Ahí las reglas cambian. No puedes "empezar bien" — tienes que entender qué hay antes de tocar nada, porque cada cambio que hagas puede tumbar algo que llevaba años funcionando por razones que nadie documentó.

Esta es la revisión que hacemos antes de tomar el control operativo de cualquier plataforma en producción.

Primero: el inventario de lo que está expuesto

Antes de mirar una sola línea de código, la pregunta más urgente es qué de este sistema es alcanzable desde internet, y quién puede llegar hasta ahí.

El dato reciente que hace que esto sea prioridad número uno: según el Reporte de Investigaciones de Brechas de Datos 2025 de Verizon, la explotación de vulnerabilidades ya representa 20% de todas las brechas como vector de acceso inicial — un aumento de 34% respecto al año anterior. Y dentro de esa categoría, los dispositivos de borde (VPNs, firewalls, gateways de acceso remoto) pasaron de ser el 3% al 22% de los objetivos — un crecimiento de casi ocho veces en un solo año.

Lo más revelador del mismo reporte: de esas vulnerabilidades en dispositivos de borde, solo 54% se remediaron por completo durante el año, con una mediana de 32 días para aplicar el parche. Un mes es tiempo de sobra para alguien que ya sabe que la puerta está abierta.

Cuando heredas un sistema, ese inventario casi nunca existe documentado. Hay que reconstruirlo.

Segundo: dónde viven los secretos

En sistemas que llevan años operando, las credenciales tienden a acumularse en lugares que nadie recuerda: variables de entorno de servidores que sobrevivieron tres migraciones, archivos de configuración con contraseñas en texto plano, llaves de API en el historial de un repositorio aunque ya se hayan borrado del código actual.

Las preguntas que hay que responder: ¿qué credenciales existen? ¿quién las conoce? ¿cuáles siguen activas de gente que ya no trabaja ahí? ¿alguna está en un repositorio, aunque sea en un commit viejo?

Tercero: el mapa de dependencias que nadie tiene

El código propio del sistema suele ser la parte más fácil de entender. Lo difícil son las dependencias: bibliotecas de terceros con versiones congeladas hace años, servicios externos que alguien conectó y nadie documentó, integraciones que fallan en silencio y que el equipo aprendió a "arreglar reiniciando".

El caso clásico —y sigue siendo el mejor ejemplo pedagógico años después— es Equifax en 2017: una vulnerabilidad conocida en Apache Struts que llevaba meses sin parchear terminó exponiendo datos de cerca de 147 millones de personas. No fue un ataque sofisticado ni un día cero. Fue una dependencia desactualizada que nadie tenía en su radar.

Cuarto: quién sabe cómo funciona esto realmente

Este punto no es técnico, y es el que más gente subestima. En sistemas heredados suele haber una o dos personas que "saben cómo funciona" — no porque esté documentado, sino porque llevan años operándolo. Si esa persona se va antes de que tú entiendas el sistema, la información se va con ella.

Parte de heredar bien es documentar lo que solo vive en la cabeza de alguien, antes de que sea urgente.

Quinto: qué se puede tocar sin miedo, y qué no

Al final de la revisión, lo que debes tener no es una lista de todo lo que está mal — es un mapa de riesgo: qué partes del sistema puedes modificar con confianza, cuáles requieren un plan de respaldo antes de tocarlas, y cuáles no deberías tocar todavía hasta entender mejor por qué funcionan como funcionan.

Ese mapa es lo que permite modernizar sin detener la operación — que es la única forma de modernizar algo que ya está en producción.

Cuándo recomendamos no tomar el proyecto

Hay casos donde la respuesta correcta es no aceptar el trabajo, al menos no todavía:

• Cuando no hay acceso al inventario real. Si no puedes ver qué está expuesto, no puedes hacerte responsable de asegurarlo.
• Cuando se espera modernizar sin ventana alguna de riesgo. Todo cambio en producción tiene un margen de error; si la expectativa es cero, la conversación tiene que empezar por ahí, no por el código.
• Cuando la persona que conoce el sistema ya se fue y no hay nada documentado. Se puede hacer, pero el costo real es mucho más alto de lo que suele estimarse — y es mejor decirlo antes, no a la mitad.

Cómo trabajamos esto en Devson Labs

En Devson Labs tomamos sistemas que ya están en producción y no pueden fallar — encontramos lo que está roto antes de que falle, endurecemos lo que está expuesto, y modernizamos sin detener la operación.

Si tienes un sistema en producción que ya no está aguantando —por seguridad, por escala, o porque da miedo tocarlo— cuéntanos el cuello de botella y te decimos si vale la pena atacarlo y qué implicaría.