Qué hacer si tu proveedor de software desaparece

Un día el proveedor que te hizo la aplicación deja de contestar. A veces se anuncia —un correo diciendo que cierran, que el desarrollador se va, que la empresa entra en concurso—, y a veces simplemente se hace el silencio: los correos rebotan, el teléfono no lo coge nadie y la factura del mes no llega. Mientras tanto, tu equipo sigue usando la herramienta todos los días.

Si estás ahí, la buena noticia es que casi nunca es tan grave como parece la primera semana. La mala es que lo que puedas hacer depende de cosas que se decidieron hace años, cuando firmaste el contrato y cuando alguien creó las cuentas del servidor. Por eso lo primero no es buscar otro proveedor, sino saber qué tienes.

Cuando tu proveedor de software desaparece, el orden importa más que la velocidad: primero que la herramienta siga funcionando, después saber qué es tuyo, luego recuperar los accesos y, solo al final, decidir qué hacer con lo que hay.

Primero, averigua qué tienes de verdad

Una aplicación no es solo el código. Es el código, el sitio donde se ejecuta, la base de datos con tu información, el dominio por el que se entra y una docena de cuentas en servicios de terceros de las que depende sin que nadie se acuerde. Cualquiera de esas piezas puede estar a tu nombre o al del proveedor, y la diferencia lo cambia todo.

Antes de hablar con nadie, haz inventario. Esta es la lista que usamos cuando nos llega un proyecto huérfano:

Pieza	Dónde mirar	Si no la tienes
Código fuente	Repositorio (GitHub, GitLab, Bitbucket) o entregas por contrato	Sin él no se puede modificar nada, solo mantener lo que corre
Servidor o hosting	Factura mensual: ¿a quién se la cobran?	Si deja de pagarse, la aplicación se apaga
Base de datos	Panel del hosting o copias de seguridad	Es tu información; es lo primero que hay que asegurar
Dominio	Registrador del dominio y titular que figura	Quien lo controla decide adónde apunta tu web
Servicios de terceros	Pasarela de pago, correo, mapas, tiendas de apps	Pueden cortarse por impago o quedar en una cuenta ajena

Para cada fila, la pregunta es la misma: ¿la cuenta está a nombre de tu empresa y tienes tú las credenciales? Las filas en las que el titular es el proveedor son tu prioridad.

Lo urgente: que siga funcionando esta semana

Mientras averiguas lo demás, hay tres cosas que no pueden esperar.

Una copia de la base de datos. Si tienes cualquier forma de acceso —el panel del hosting, un usuario de administración, una exportación desde la propia aplicación—, saca una copia completa hoy y guárdala fuera de ese servidor. El código se puede reconstruir; los datos de tus clientes, no.

Los pagos que mantienen todo encendido. Averigua cuándo vence el hosting, el dominio y los certificados. Si el servidor lo pagaba el proveedor y el proveedor ya no existe, la aplicación se apagará el día que falle el cobro, y no te avisará nadie. A veces basta con ponerse en contacto con el proveedor de hosting, explicar la situación y pasar la facturación a tu empresa.

Nada de cambios. No es el momento de pedirle a alguien de confianza que "le eche un vistazo y arregle esa cosa que fallaba". Tocar un sistema que nadie conoce puede romper lo que hoy funciona, y no hay nadie que sepa volver atrás.

¿De quién es el código si tu proveedor ha cerrado?

Es la pregunta que más angustia genera y la que tiene una respuesta menos intuitiva. Que hayas pagado el desarrollo no significa automáticamente que el código sea tuyo.

En España, la Ley de Propiedad Intelectual atribuye al empresario los derechos de explotación de un programa cuando lo crea un trabajador suyo en el ejercicio de sus funciones (artículo 97.4). Pero si lo encargaste a una empresa externa, esa regla no te cubre: los derechos los tiene, en principio, quien lo desarrolló, y pasan a ti solo si hay una cesión, que la propia ley exige que conste por escrito (artículo 45).

En la práctica eso significa que la respuesta está en tu contrato. Busca una cláusula de propiedad intelectual o de cesión de derechos, y fíjate en tres cosas: si la cesión es exclusiva, si incluye el código fuente y no solo el uso del programa, y si permite modificarlo y encargar su mantenimiento a otros.

Hay además matices que dependen de la situación concreta. Si la empresa está en concurso de acreedores, el código puede figurar entre sus activos y las decisiones pasan por la administración concursal. Si el desarrollo lo hizo un autónomo que ha dejado la actividad, la conversación es con esa persona. Aquí conviene hablar con un abogado especializado en propiedad intelectual antes de dar nada por hecho: nosotros podemos decirte qué hay técnicamente, pero no qué dice tu contrato en términos jurídicos.

Lo que sí suele ser cierto es que, aunque la titularidad sea dudosa, tienes derecho a seguir usando lo que pagaste. La ley reconoce al usuario legítimo de un programa ciertas facultades, como hacer copia de seguridad o corregir errores cuando es necesario para usarlo (artículo 100), aunque el contrato puede limitar algunas de ellas. La herramienta no deja de ser utilizable de un día para otro por el cierre del proveedor.

Recuperar los accesos cuando nadie contesta

Si el proveedor sigue existiendo aunque no responda, lo más rápido es casi siempre insistir por un canal que deje constancia —un burofax, un correo a la dirección que figure en el contrato— pidiendo expresamente la entrega del código, las credenciales y la documentación. A veces la desaparición es solo desorden, y una petición formal lo desbloquea.

Cuando eso no funciona, cada pieza tiene su camino.

El repositorio. Si el código estaba en una cuenta del proveedor en GitHub o GitLab, sin su colaboración no hay forma de sacarlo. Pero a menudo existe una copia en el propio servidor donde se ejecuta la aplicación, y quien tenga acceso a ese servidor puede recuperarla.

El hosting. Los proveedores de infraestructura tienen procedimientos para transferir cuentas o servicios, pero exigen acreditar que eres el cliente final. Las facturas, el contrato con el desarrollador y el hecho de que el dominio sea tuyo ayudan.

El dominio. Si está registrado a tu nombre, recuperar el control es un trámite con el registrador. Si figura a nombre del proveedor, recuperarlo sin su colaboración es lento y no siempre posible.

Las apps en las tiendas. Una aplicación publicada desde la cuenta de desarrollador del proveedor en App Store o Google Play solo se puede transferir si lo inicia el titular de esa cuenta. Si no colabora, la alternativa es publicar una app nueva desde una cuenta tuya y pedir a los usuarios que la instalen.

Auditar antes de decidir

Con los accesos recuperados, la tentación es llamar a otra empresa y pedir que "siga donde lo dejaron", con plazo y precio. Desconfía de quien te los dé en ese momento.

Nadie puede comprometer una estimación sobre código que no ha leído. Lo razonable es una auditoría corta: alguien con criterio técnico revisa el código, la infraestructura y la base de datos, y te entrega un informe de lo que hay. Qué tecnologías usa y si siguen teniendo soporte, si el código se puede desplegar desde cero con lo que tienes, si hay pruebas, dónde están los riesgos de seguridad y cuánto conocimiento se ha perdido con el proveedor. Es trabajo de consultoría tecnológica, y es la base de cualquier decisión que tomes después.

Las tres salidas posibles

Con el informe en la mano, casi todo se reduce a una de tres opciones:

Mantener lo que hay. Si el código está razonablemente bien y la tecnología sigue viva, otro equipo puede asumirlo. Tras un periodo inicial para aprender el sistema y documentarlo, pasa a un mantenimiento normal. Para hacerte una idea de qué supone eso al año, lo contamos en cuánto cuesta mantener un software a medida.

Rescatar y sanear. El caso más habitual. El código funciona pero tiene partes frágiles, dependencias desactualizadas o piezas que nadie entiende. Se estabiliza lo crítico, se sustituye lo que da problemas y se sigue adelante sin reescribir.

Reescribir. Solo cuando la tecnología ha quedado sin soporte, cuando no hay código fuente recuperable o cuando mantenerlo cuesta más que rehacerlo. Es la opción más cara y la que más se sugiere a la ligera: desconfía de quien la proponga sin haber auditado antes.

Un ejemplo de cómo se ve esto en la práctica

Pongamos, como caso ilustrativo, una academia con varias sedes que gestiona matrículas, grupos y cobros con una plataforma que le hizo un desarrollador externo hace cuatro años. El desarrollador deja la actividad y dos meses después falla el cobro de una matrícula.

El inventario revela que el dominio es de la academia, pero el servidor lo pagaba el desarrollador desde su propia cuenta, y el código solo existe en ese servidor. La prioridad inmediata es la base de datos: se exporta y se guarda fuera. Después se contacta con el proveedor de hosting para que la facturación pase a la academia y la plataforma no se apague.

La auditoría encuentra un código entendible, pero con una librería de pagos sin actualizar desde hace años, que es la que estaba fallando. La salida es un rescate: se actualiza la integración de cobros, se mueve el código a un repositorio a nombre de la academia y se documenta cómo desplegarlo. No hace falta reescribir nada.

Cómo evitar que te vuelva a pasar

Un proveedor puede cerrar, jubilarse o cambiar de rumbo por motivos que no tienen nada que ver contigo. No se puede evitar; se puede hacer que no te deje colgado.

Cesión de derechos por escrito. El contrato debe decir que los derechos de explotación sobre el código desarrollado para ti pasan a tu empresa, incluido el código fuente y la posibilidad de modificarlo y encargarlo a terceros.

Todas las cuentas a tu nombre. Repositorio, hosting, dominio, cuentas de desarrollador en las tiendas, pasarela de pago. El proveedor trabaja con acceso delegado; el titular eres tú. Es gratis hacerlo bien desde el principio y muy caro arreglarlo después.

Documentación de despliegue. Un documento que explique cómo poner la aplicación en marcha desde cero en un servidor nuevo. Si nadie ajeno al proveedor podría seguirlo, no está terminado.

Depósito del código, si no puedes tenerlo tú. Cuando el proveedor no entrega el código —habitual en productos que licencian a varios clientes—, existe la figura del depósito del código fuente ante un tercero, que lo libera si el proveedor desaparece.

Estas cuatro condiciones son también las que conviene exigir al contratar. Lo desarrollamos en cómo elegir una empresa de desarrollo de software, y es la razón por la que en nuestro proceso entregamos repositorio, base de datos y documentación con el cliente como propietario.

Por dónde empezar mañana

Si tu proveedor acaba de desaparecer, el orden es: copia de la base de datos, pagos al día, inventario de cuentas, revisión del contrato con un abogado y, solo después, auditoría y decisión. Casi siempre hay más margen del que parece, siempre que no se toque nada a ciegas.

Puede que al hacer el inventario descubras que todo está a tu nombre y que lo único que necesitas es alguien que asuma el mantenimiento; en ese caso, cualquier equipo serio te sirve. Si lo que encuentras es un servidor ajeno, un código que nadie ha leído y una herramienta de la que depende tu día a día, cuéntanos qué tienes. Revisar la situación y decirte por dónde empezar lleva poco tiempo, y te vas con un plan aunque después decidas hacerlo con otros.