Heredar un sistema que nadie documentó

El sistema funciona. Lo escribió alguien que ya no trabaja con la empresa, hace cinco o siete años, y nadie sabe cómo está hecho por dentro. Cada vez que hace falta un cambio, el presupuesto se detiene en la misma frase: nadie quiere ser el que lo toque.

Es una de las situaciones más comunes que nos llegan, y también una de las peor entendidas. Se presenta como un problema técnico, y en la mayoría de los casos el código es la parte menos grave. Lo grave es que el conocimiento de cómo opera ese sistema vivía en una cabeza y esa cabeza se fue.

Este post es lo que hacemos cuando nos toca entrar a un sistema así, en el orden en que lo hacemos. Sirve igual si decides hacerlo con tu equipo interno.

Lo primero no es el código, son las llaves

Antes de abrir un archivo, levantamos un inventario de propiedad y accesos. Es la parte que más incomoda y la que más veces encuentra algo roto.

Quién es el titular del dominio y quién paga la renovación. Dónde están los registros DNS y quién puede cambiarlos. En qué servidor o proveedor de hosting corre, y a nombre de quién está esa cuenta. Dónde está el repositorio del código, si existe, y si tienes acceso de administrador. Quién tiene la credencial de la base de datos. Qué cuentas de terceros están involucradas, correo transaccional, pasarela de pago, mensajería, y con qué correo se crearon.

La respuesta a alguna de esas preguntas suele ser el correo personal del desarrollador anterior. No necesariamente por mala fe: se crearon cuentas para resolver rápido y nadie las transfirió después. El resultado es que la empresa opera sobre infraestructura que no controla, y eso es un riesgo de continuidad, no un detalle administrativo.

Recuperar el control de las llaves es lo primero, siempre, y a veces es lo único urgente. Un sistema sin documentación pero con accesos en orden es un proyecto normal. Un sistema con documentación impecable cuyo dominio está a nombre de un tercero ilocalizable es una emergencia.

La prueba de fuego: levantarlo desde cero

La auditoría técnica empieza con un ejercicio simple y despiadado: intentar poner el sistema a correr en un entorno nuevo, desde el código y los respaldos que existen, sin la ayuda del que lo escribió.

Si eso se logra en unas horas, el sistema es mantenible aunque no esté documentado. Si no se logra, acabas de descubrir el problema más importante: ese sistema no se puede reconstruir. Está vivo porque el servidor donde vive sigue encendido, y el día que ese servidor falle, la recuperación no va a ser una restauración sino una reconstrucción.

Lo que se revisa después, en este orden: si hay respaldos, si están automatizados, y sobre todo si alguna vez se restauró uno para comprobar que sirve. Un respaldo que nunca se restauró es una intención, no un respaldo. Luego el modelo de datos, que es donde está la lógica real del negocio y lo que más cuesta reemplazar. Luego las dependencias sin actualizar, para saber qué es riesgo de seguridad y qué solo es antigüedad, que no es lo mismo. Y al final el código, que a estas alturas ya se lee mucho más rápido porque los datos te contaron qué hace.

Una auditoría así se acota en días, no en semanas, y entrega algo concreto: un inventario, un mapa del modelo de datos, una lista de riesgos ordenada por urgencia y un procedimiento de arranque escrito. Con eso la conversación cambia de "no lo toquemos" a "estas son las tres cosas que hay que resolver".

Rescatar o reescribir

Es la decisión que todo el mundo quiere tomar primero y la única que no se puede tomar sin lo anterior.

El criterio que usamos no es la edad del código ni el lenguaje en que está escrito. Es el modelo de datos. Si los datos están bien estructurados, con relaciones claras y sin campos que significan cinco cosas distintas, el sistema se rescata: se estabiliza, se documenta y se le agregan módulos nuevos alrededor. Un sistema viejo con datos sanos es una base perfectamente buena.

Si el modelo de datos ya no representa cómo opera el negocio hoy, si la misma regla está implementada en tres lugares con resultados distintos, o si cada cambio pequeño exige tocar media aplicación, entonces mantenerlo cuesta más que reemplazarlo y la cuenta empeora cada año.

Hay una tercera vía que es la que más usamos y la que menos se ofrece: reemplazar por partes. El sistema viejo sigue operando, se construye lo nuevo alrededor del mismo modelo de datos, y se van moviendo módulos en un orden que el negocio decide. No hay un día del gran cambio, no hay congelamiento de la operación, y cada entrega ya sirve para algo. Si el reemplazo implica mover el histórico, cómo se hace eso está en migración de datos.

Si estás en esta decisión y no tienes con quién contrastarla, es exactamente el tipo de cosa que se puede ordenar en una llamada de treinta minutos.

Estabilizar antes que mejorar

Cuando tomamos un sistema heredado, las primeras semanas no traen funcionalidad nueva. Esto se conversa al inicio porque puede sonar a que no está pasando nada.

Se ponen los accesos a nombre de la empresa. Se automatiza el respaldo y se restaura uno completo para comprobar que funciona. Se documenta el procedimiento de arranque y se deja el entorno reproducible. Se atienden las dependencias con riesgo de seguridad conocido. Y se escribe lo mínimo indispensable para que otra persona pueda entrar: cómo se levanta, cómo se despliega, dónde está cada cosa, qué no hay que tocar y por qué.

Es la parte menos vistosa del trabajo y la que hace que todo lo demás sea posible. Cambiar funcionalidad sobre un sistema que no se puede reconstruir es tomar un riesgo que no se puede deshacer.

Cuando lo correcto es no hacer nada

Hay un caso honesto en contra de todo lo anterior, y lo decimos cuando lo vemos.

Si el sistema cubre lo que la operación necesita, nadie está pidiendo cambios, y el negocio no tiene planes que dependan de él, entonces no hace falta un proyecto. Hacen falta tres cosas y ninguna es un desarrollo: recuperar los accesos, tener un respaldo automatizado y verificado, y tener escrito cómo se levanta si el servidor muere. Eso se resuelve en días.

Un sistema estable y aburrido que hace su trabajo no es deuda técnica. Es un activo, y modernizarlo porque está viejo es gastar sin motivo. La conversación cambia cuando el sistema empieza a impedir algo que el negocio quiere hacer, no cuando cumple años. De hecho, buena parte de los casos que llegan pidiendo un sistema nuevo no necesitan software sino otra cosa, y eso lo desarrollamos en cuándo no necesitas más software.

Qué pedirle a quien lo vaya a tomar

Cuatro preguntas útiles. Qué entrega la auditoría, en qué formato y en cuántos días. Si el primer hito incluye poner los accesos a nombre de la empresa y verificar un respaldo restaurado. Cómo se decide entre rescatar y reescribir, y en qué evidencia se basa esa decisión. Y qué documentación queda al final, escrita para quién.

Una propuesta que salta directo a "lo reescribimos todo" sin haber abierto el sistema no está evaluando: está vendiendo lo que sabe hacer. Y una que promete tocarlo sin auditarlo primero está asumiendo un riesgo que vas a pagar tú. Hay más preguntas de este tipo en doce preguntas antes de contratar una agencia.

Cómo lo trabajamos

Tomamos sistemas existentes y lo primero que entregamos es claridad: inventario de accesos, estado real del sistema y riesgos ordenados, antes de proponer una sola línea de desarrollo. Si de ahí sale un proyecto, sale con alcance escrito; si sale que no hace falta, también lo decimos. Al cerrar, el código, los datos, los accesos y la documentación quedan a tu nombre. El alcance completo está en sistemas a medida.

Si tienes un sistema que nadie se atreve a tocar, la llamada de descubrimiento dura treinta minutos, es gratuita y sin compromiso. Salir de ella sabiendo si tu caso es de rescate, de reemplazo o de simple orden administrativo ya es un resultado. Puedes agendarla aquí.