Mi proveedor de software ha desaparecido: qué hacer, paso a paso

Pasa más de lo que parece. La agencia que desarrolló la aplicación cierra, el freelance cambia de trabajo o, simplemente, deja de contestar. Mientras tanto, el software sigue en producción: los clientes lo usan, los pedidos entran y nadie sabe muy bien qué hay detrás.

La buena noticia es que casi siempre se puede recuperar el control. La mala es que, si se hace con prisas, es fácil empeorar la situación. Este artículo resume el orden en el que conviene actuar.

Primero: no toques nada (todavía)

Cuando el sistema funciona, la tentación es "arreglar" lo que molesta o encargar cambios a la primera persona disponible. Es justo lo que hay que evitar al principio. Sin saber cómo está montado, cualquier cambio puede romper algo que hoy funciona y, sin el proveedor original, no habrá nadie que sepa deshacerlo.

Las primeras semanas el objetivo no es mejorar nada, sino asegurar que no se pierde nada: accesos, datos y conocimiento.

1. Haz inventario de lo que sabes (y de lo que no)

Antes de llamar a nadie, reúne en un documento todo lo que tengáis. No hace falta que sea técnico:

• Dominio: dónde está registrado y a nombre de quién.
• Alojamiento: qué empresa da el servidor o el hosting y quién recibe las facturas.
• Código fuente: si existe un repositorio (GitHub, GitLab, Bitbucket…) o alguna copia entregada.
• Base de datos: dónde están los datos de clientes, pedidos o facturas.
• Servicios externos: pasarela de pago, envío de emails, mapas, APIs de terceros, licencias.
• Personas y documentos: contratos, presupuestos, correos con instrucciones, manuales.

Las preguntas sin respuesta son tan importantes como las respuestas: indican dónde está el riesgo.

2. Asegura los accesos críticos

Lo más urgente es que las cuentas importantes estén bajo control de tu empresa. Si el dominio o el hosting están a nombre del proveedor, el día que deje de pagarlos la aplicación desaparece con ellos.

Por orden de prioridad:

1. Dominio: es lo que hace que la web y el correo funcionen. Comprueba la titularidad y la fecha de renovación.
2. Hosting o servidor: acceso al panel y a la facturación.
3. Correo electrónico asociado al dominio.
4. Servicios de pago y cualquier cuenta que mueva dinero o datos de clientes.

Si alguna contraseña la conocía el proveedor, cámbiala en cuanto tengas el acceso, empezando por las de las cuentas que dan acceso a todo lo demás.

3. Haz una copia de seguridad completa (y comprueba que sirve)

Con los accesos asegurados, el siguiente paso es tener una copia completa del código y de la base de datos guardada fuera del servidor. Y, sobre todo, comprobar que esa copia se puede restaurar: una copia que nadie ha probado es solo una esperanza.

Esta copia es tu seguro. A partir de aquí, cualquier trabajo sobre el sistema se puede hacer sin miedo a perderlo todo.

4. Revisa el contrato y la propiedad del código

Antes de encargar el mantenimiento a otra empresa, revisa qué dice el contrato con el proveedor anterior sobre la propiedad del código, las licencias y la entrega de accesos. En caso de duda, consúltalo con un abogado: no todos los contratos dejan claro quién es el dueño de lo desarrollado.

Si el proveedor sigue localizable, aunque no quiera continuar, merece la pena pedirle una transición ordenada: traspaso de accesos, documentación y una conversación con quien vaya a hacerse cargo.

5. Encarga un diagnóstico técnico antes de decidir

Con todo lo anterior hecho, toca entender en qué estado está realmente el sistema. Un buen diagnóstico revisa:

• cómo está organizado el código y si se puede mantener;
• las versiones de lenguaje, framework y servidor, y si siguen teniendo soporte de seguridad;
• las dependencias externas y qué pasaría si alguna falla;
• cómo se despliega una nueva versión y si hay copias de seguridad automáticas;
• los riesgos de seguridad más evidentes.

El resultado debería ser un informe que entienda quien toma decisiones, no solo un técnico, con los riesgos ordenados por urgencia y opciones con su coste aproximado. Es precisamente lo primero que hacemos en un rescate de software.

¿Reparar, modernizar o rehacer?

Es la pregunta que todo el mundo se hace, y la respuesta depende del diagnóstico. A grandes rasgos:

Rehacer desde cero parece la opción más limpia, pero es la más cara y arriesgada, y a menudo repite los errores del sistema anterior. Lo habitual es estabilizar primero y sustituir piezas de forma progresiva. Si al final sí hace falta una herramienta nueva, conviene plantearla como un desarrollo de software a medida bien definido, no como una reacción de urgencia.

Señales de que hay que actuar ya

Algunas situaciones no admiten esperar a tener todo ordenado:

• el dominio o el hosting están a punto de caducar;
• la aplicación muestra errores que afectan a cobros, pedidos o datos de clientes;
• hay indicios de un problema de seguridad;
• el servidor funciona con versiones que ya no reciben actualizaciones de seguridad.

En esos casos, lo primero es contener el problema y asegurar una copia; el resto puede esperar unos días.

Cómo evitar que vuelva a pasar

Una vez recuperado el control, unas pocas medidas evitan repetir la experiencia:

• Cuentas a nombre de la empresa: dominio, hosting, repositorio y servicios externos, siempre con un acceso de administración propio.
• Código en un repositorio de la empresa, no en el ordenador de un proveedor.
• Documentación mínima: cómo se despliega, dónde está cada cosa y qué servicios externos se usan.
• Contrato claro sobre propiedad del código y entrega de accesos al terminar la relación.
• Mantenimiento acordado, aunque sea pequeño, para que alguien vigile actualizaciones y copias de seguridad.

Nada de esto es caro, y marca la diferencia entre un susto y una crisis.

Si estás en esta situación ahora mismo, cuéntanos qué tienes y qué ha pasado: te diremos por dónde empezar.