Qué hacer cuando heredas un software y quien lo hizo ya no está

Un escenario mucho más común de lo que parece

El desarrollador freelance que cambió de vida, la empresa que cerró, el proveedor que responde cada vez más tarde hasta que deja de responder, el empleado que se fue con las contraseñas en la cabeza. El resultado es siempre un sistema del que depende tu operación diaria y nadie que responda por él. Suele convivir con una mezcla de miedo («que nadie lo toque, que funciona») y parálisis («habría que hacer algo con esto») que puede durar años, y cada año acumula más riesgo.

Fase 1. Asegura antes de decidir (esta semana)

Sin tocar una línea de código:

1. Haz inventario de los accesos: servidor u hosting, dominio, base de datos, panel de administración, repositorio de código si existe y cuentas de servicios conectados. Apunta cuáles tienes tú y cuáles tenía solo el proveedor.
2. Recupera la titularidad de lo que no controles. El dominio y el hosting tienen que estar a nombre de tu empresa, no del proveedor desaparecido. Va primero porque es lo que puede convertir un problema en una emergencia.
3. Haz ahora una copia completa de la aplicación y los datos, y guárdala fuera del servidor. Aunque esté mal hecha y no sepas restaurarla, una copia de hoy vale oro el día que algo pase.
4. Pon por escrito lo que sabe el equipo: quién lo usa, para qué, qué falla de vez en cuando y qué trucos conoce la persona que más lo usa. Ese conocimiento oral es parte del sistema.

Fase 2. Auditoría del estado real (sin compromiso de nada)

Con lo urgente asegurado, toca saber qué tienes entre manos. Esto sí conviene que lo haga alguien externo con criterio, y debe responder a cuatro preguntas:

• ¿Existe el código fuente y es accesible? No es raro descubrir que solo existe lo desplegado, o que el código está pero falta la pieza que lo compila.
• ¿En qué estado está? Tecnologías, versiones, seguridad, dependencias abandonadas y deuda acumulada.
• ¿Qué hace exactamente? No siempre coincide con lo que el equipo cree que hace.
• ¿Qué costaría mantenerlo, evolucionarlo o sustituirlo? Con órdenes de magnitud honestos, no con un presupuesto de rehacerlo todo disfrazado de auditoría.

Es el tipo de análisis acotado, con entregable y sin compromiso, que hacemos como Discovery. Recibes un documento con el estado real y los caminos posibles, y con él puedes decidir, con nosotros o con quien quieras.

Fase 3. Los tres caminos (y cómo elegir)

1. Retomar el mantenimiento. Si el sistema es razonablemente sólido, un proveedor serio puede hacerse cargo: ordenar accesos, montar copias verificadas y monitorización, y responder por él con tiempos por escrito. Es el camino más corto para dormir tranquilo.

2. Evolucionar sobre lo que hay. Si además el negocio necesita cosas nuevas, muchas veces se puede construir alrededor, por ejemplo integrándolo o ampliándolo por módulos, sin tirar lo que funciona.

3. Sustituir por fases. Si la auditoría revela que el sistema es insostenible (tecnología muerta, sin código fuente, seguridad irrecuperable), se planifica la sustitución mientras el viejo sigue funcionando. Se hace con software a medida por fases, empezando por lo más crítico y con la migración de datos incluida. No hay big-bang: el sistema viejo se apaga cuando el nuevo ya sostiene la operación.

Hay una trampa que evitar, y es el proveedor que sentencia «esto hay que rehacerlo entero» sin haber auditado nada. A veces tiene razón, pero muchas veces es la venta fácil. Exige el diagnóstico antes que el veredicto.

Y para que no vuelva a pasar

El día que retomes el control, deja tres cosas por escrito con quien trabaje contigo a partir de entonces. La propiedad, con código, datos y accesos a tu nombre. La documentación, como entregable de cada trabajo. Y la salida, para que cambiar de proveedor sea siempre posible. Un sistema del que eres dueño no vuelve a quedarse huérfano.