El proveedor que cerró y se llevó la operación de sus clientes

Resumen:

• El riesgo de continuidad no requiere mala fe: basta con un cierre ordenado.
• Tener el código no basta: hacen falta credenciales, documentación y datos.
• Las señales de alarma son operativas y aparecen meses antes del cierre.
• Con un proveedor individual, el rigor debe ser mayor, no menor.

Un proveedor de software sectorial cerró. No fue una quiebra dramática: los socios se jubilaron, avisaron con dos meses y ofrecieron ayuda en la transición.

Aun así, varias de las empresas que usaban su sistema pasaron semanas complicadas. No porque nadie quisiera ayudarlas, sino porque la ayuda que necesitaban ya no era posible: hacía falta gente que ya no estaba y conocimiento que nunca se había escrito.

Qué hace falta para continuar sin el proveedor

La respuesta intuitiva es «el código». Es necesaria y muy insuficiente.

El caso más frecuente que vemos es el segundo: empresas con su código y sin las llaves de la casa donde está instalado.

Las señales que aparecen antes

Un cierre casi nunca es una sorpresa absoluta. Suele haber meses de señales que se interpretan como mala racha.

• Los tiempos de respuesta se alargan sin explicación.
• Cambia la persona de contacto varias veces en poco tiempo.
• Se aplazan entregas comprometidas sin fecha nueva firme.
• Se responde con evasivas a la petición de documentación o de acceso al repositorio.
• Dejan de proponer mejoras y solo atienden incidencias.

Ninguna de estas es concluyente por sí sola. Tres o más a la vez son motivo suficiente para pedir una copia completa de todo y verificar que sirve.

La prueba que casi nadie hace

Tener el respaldo no es lo mismo que tenerlo utilizable.

La comprobación honesta consiste en intentar levantar el sistema desde cero con lo que tienes guardado, en un entorno separado, sin llamar al proveedor. Si se consigue, la protección es real. Si no, ahora sabes exactamente qué falta y puedes pedirlo mientras todavía hay alguien a quien pedírselo.

Es un ejercicio de un día. Casi nunca se hace, y es la diferencia entre creerse protegido y estarlo.

Preguntas frecuentes

¿Qué es la custodia de código y cuándo se activa?

Es un acuerdo por el que un tercero conserva una copia del código fuente y la entrega al cliente si se cumplen determinadas condiciones, típicamente el cese de actividad del proveedor o el incumplimiento del mantenimiento. Su valor depende de que el depósito esté actualizado, no solo de que exista.

¿Basta con tener el código para poder continuar?

No. Hacen falta también las credenciales de los servicios de terceros, la documentación de despliegue y los datos. Hemos visto empresas con el código en la mano incapaces de ponerlo en marcha porque nadie sabía cómo se desplegaba ni dónde estaba alojado.

¿Cómo se detecta que un proveedor está en riesgo?

Señales operativas: respuestas cada vez más lentas, rotación de las personas de contacto, retrasos en entregas comprometidas, negativa a documentar. Ninguna es concluyente por separado y varias juntas justifican activar el plan de contingencia.

¿Qué debe incluir el contrato desde el principio?

Propiedad del código, entrega de credenciales al cierre, obligación de documentación mínima, plazo de preaviso para terminar el servicio y, si el sistema es crítico, custodia de código con depósito periódico verificable.

¿Sirve de algo si el proveedor es una persona sola?

Sirve más todavía. El riesgo de continuidad con un profesional individual es estructuralmente mayor, no por su calidad sino por su tamaño. Con un freelance conviene ser especialmente riguroso en el acceso al repositorio y en la documentación.

Lo que recomendamos a cualquier cliente

Cuatro cosas, independientemente de con quién trabaje.

El repositorio a nombre del cliente, con el proveedor invitado. No al revés. Es gratis y elimina de golpe el escenario más común.

Las cuentas de servicios a nombre de la empresa. Alojamiento, dominio y pasarelas contratados por el cliente, con acceso delegado al proveedor.

Un documento de despliegue de una página, actualizado cuando cambie algo relevante. No hace falta más.

Una prueba de restauración al año. Levantar el sistema desde el respaldo y comprobar que arranca.

Nada de esto encarece un proyecto. Lo que hace es convertir el cierre de un proveedor en un contratiempo administrativo en lugar de una crisis operativa.

Qué hacer si el proveedor ya cerró

Si el escenario ya ocurrió, el orden de actuación importa mucho.

Primero, asegurar los accesos. Antes que nada, obtener control de dominio, alojamiento y cuentas de servicios. Es lo que caduca y lo que, una vez perdido, es más difícil de recuperar.

Segundo, extraer los datos. Una copia completa de la base de datos, verificada, en tu propio almacenamiento. Aunque no puedas usarla todavía.

Tercero, documentar el comportamiento. Antes de que nadie toque nada, registrar qué hace el sistema: pantallas, procesos, informes. Es el conocimiento que se pierde primero.

Cuarto, decidir el destino. Continuar con el sistema tal cual mientras funcione, reescribirlo o migrar a una alternativa. Esa decisión se toma con calma, después de los tres pasos anteriores, no antes.

El error que hemos visto varias veces es invertir el orden: empezar a buscar un proveedor nuevo mientras las cuentas de servicios siguen a nombre de una empresa que ya no existe.

El caso particular del proveedor que se jubila

Es distinto de una quiebra y merece mención aparte, porque es el escenario más frecuente en el software sectorial español: programas construidos en los años dos mil por profesionales que hoy tienen edad de retirarse.

La ventaja es que hay tiempo y hay buena voluntad. La desventaja es que casi nadie la aprovecha: el aviso llega, el cliente lo registra mentalmente como algo a resolver, y pasan meses.

Si tu proveedor está en esa situación, hay una ventana de oportunidad que no volverá. Mientras siga disponible, se le puede pedir que documente, que explique decisiones de diseño y que acompañe una prueba de despliegue. Ese conocimiento vale más que el propio código y desaparece con la persona.