Qué hacer cuando el desarrollador original dejó el sistema

Un sistema funcionando, la empresa dependiendo de él, y nadie que responda cuando algo falla. Es una situación incómoda y bastante común, sobre todo cuando el desarrollo lo hizo una persona sola o un equipo que cambió de sector.

La urgencia hace que muchos partan buscando quién lo tome. Conviene invertir el orden: primero asegurar el acceso, después evaluar, y recién entonces decidir.

Primero: recuperar los accesos

Esto es lo urgente, aunque el sistema esté funcionando sin problemas hoy. Sin accesos no se puede hacer nada el día que falle, y el día que falle no vas a tener tiempo de conseguirlos.

La lista mínima:

• El dominio. Debe estar en una cuenta a tu nombre, con el correo de recuperación bajo tu control.
• El servidor o el servicio donde corre el sistema.
• La base de datos, y un respaldo reciente que puedas descargar.
• El código fuente, completo y en un repositorio al que tengas acceso.
• Los servicios de terceros: pasarela de pago, envío de correos, almacenamiento de archivos.
• Los certificados y las claves de las integraciones.

Si algo de esto está a nombre de quien desarrolló, pídelo ahora, mientras la relación siga siendo cordial. Recuperar un dominio registrado por un tercero que dejó de responder es un trámite lento y a veces sin solución.

Segundo: evaluar en qué estado está

Con los accesos en la mano, se puede saber qué hay. Una revisión seria responde cinco preguntas:

1. ¿Hay respaldos y funcionan? Un respaldo que nunca se restauró no es un respaldo. Hay que probarlo.
2. ¿Con qué está construido y qué tan desactualizado está? Las versiones sin soporte no reciben parches de seguridad, y eso tiene fecha.
3. ¿Se entiende el código? No hace falta que sea elegante. Hace falta que alguien nuevo pueda cambiar algo sin romper otra cosa.
4. ¿Se puede levantar una copia para trabajar? Si la única forma de probar un cambio es hacerlo directo en producción, cualquier arreglo es un riesgo.
5. ¿Qué tan expuesto está? Claves escritas dentro del código, permisos abiertos, datos personales sin proteger.

Esa revisión se cotiza aparte y termina con un informe. Es tuyo, tomes o no un plan de mantención después.

Tercero: decidir entre continuar y rehacer

La respuesta casi nunca es rehacerlo todo, aunque sea la primera reacción cuando el código ajeno cuesta de leer.

Conviene continuarlo cuando el sistema hace lo que el negocio necesita, la tecnología todavía tiene soporte, y el problema es que no hay quién lo atienda. Que el código no esté como uno lo habría escrito no es razón suficiente: reescribir cuesta meses y empieza con menos funciones que las que ya tienes.

Conviene rehacerlo cuando la tecnología quedó sin soporte y no hay ruta de actualización, cuando cada cambio pequeño rompe tres cosas, o cuando el negocio cambió tanto que el sistema ya no representa cómo se trabaja hoy.

Un camino intermedio que suele funcionar: estabilizar lo que hay, mantenerlo operando, y reemplazar de a una las partes que más molestan. La operación nunca se detiene y el gasto se reparte en el tiempo.

Lo que conviene dejar resuelto de aquí en adelante

Para no volver a la misma situación:

• Todas las cuentas a nombre de la empresa, no de quien desarrolla.
• Respaldos automáticos, y una prueba de restauración cada cierto tiempo.
• El código en un repositorio propio, con acceso para más de una persona.
• Documentación mínima de cómo se despliega y de qué depende el sistema.
• Un acuerdo de mantención con tiempos de respuesta por escrito.

En resumen

Asegura los accesos hoy, evalúa después y decide al final. La mayoría de los sistemas heredados se pueden continuar; los que no, se reemplazan por partes sin detener la operación.

Tomamos sistemas desarrollados por otros equipos, siempre con una revisión previa. Puedes ver cómo funciona en mantención y evolución de software, o cuéntanos qué tienes y lo revisamos.