Qué hacer cuando la empresa que desarrolló tu software desaparece

Un día pides un cambio pequeño en tu aplicación y nadie contesta. El correo rebota, el teléfono no existe, o la persona que lo llevaba ya no trabaja allí. El software sigue funcionando, pero de golpe no hay quien lo toque. Es una situación más común de lo que parece: la empresa que lo desarrolló cerró, cambió de rumbo, o simplemente dejó de considerarte un cliente prioritario.

La reacción instintiva —"hay que rehacerlo entero"— casi nunca es la primera decisión correcta. Antes hay pasos que reducen el riesgo sin gastarte el presupuesto de un proyecto nuevo. Esto es lo que conviene hacer, y en qué orden.

Paso 1: auditar lo que realmente tienes

No puedes decidir nada hasta saber qué hay. Y "qué hay" no es solo el código: es todo lo que hace falta para que ese código siga vivo.

• El código fuente. ¿Lo tienes tú, en un repositorio al que puedes acceder, o vive solo en el servidor donde se ejecuta? ¿Está completo, o falta la parte de configuración, los scripts de despliegue o las migraciones de base de datos?
• Las dependencias. Toda aplicación se apoya en librerías y frameworks de terceros. Conviene inventariar cuáles usa y en qué versión, porque las versiones antiguas dejan de recibir parches de seguridad y bloquean cualquier actualización posterior.
• La infraestructura. Dónde está alojada, qué servicios externos consume (pasarelas de pago, envío de correo, APIs de terceros), qué certificados caducan y cuándo.
• El conocimiento. ¿Hay documentación de la arquitectura y del despliegue, o todo estaba en la cabeza de quien lo programó? Casi siempre es lo segundo.

El resultado de esta fase es un informe: estado real del proyecto y riesgos ordenados por gravedad. Sin ese mapa, cualquier decisión posterior es una apuesta.

Paso 2: recuperar el control del código y los accesos

Este paso es tan importante como el anterior y se olvida con frecuencia. Si el proveedor desapareció, es probable que parte de las llaves de tu propio software estén a su nombre:

• El dominio y sus DNS.
• El hosting o la cuenta de la nube donde corre la aplicación.
• El repositorio de código.
• Las cuentas de los servicios externos (correo transaccional, analítica, pasarela de pago).
• Los certificados y las credenciales de acceso a la base de datos.

Haz una lista de todos esos activos y de a nombre de quién están. Lo que esté bajo una cuenta que no controlas es un punto único de fallo: el día que esa cuenta caduque o se cancele, tu software se cae y no puedes hacer nada. Recuperar la titularidad —transferir el dominio, migrar el hosting a una cuenta tuya, invitar a un administrador nuevo al repositorio— es prioritario y a menudo se puede hacer aunque el proveedor no colabore, siguiendo los procedimientos de cada plataforma.

Paso 3: estabilizar antes de evolucionar

Con el mapa hecho y los accesos recuperados, la tentación es pedir ya las mejoras que llevas meses queriendo. Es pronto. Primero hay que estabilizar: resolver lo urgente para que el proyecto deje de ser frágil.

Estabilizar significa, en la práctica:

• Actualizar las dependencias con vulnerabilidades conocidas, empezando por las que están expuestas a internet.
• Tapar los puntos de rotura evidentes: procesos sin control de errores, tareas programadas que fallan en silencio, copias de seguridad que no existían o no se estaban verificando.
• Documentar el despliegue, para que publicar un cambio deje de ser una operación de riesgo que solo sabía hacer una persona.
• Añadir algo de red de seguridad —pruebas automáticas en la lógica crítica— para poder tocar el código sin cruzar los dedos.

Solo cuando el proyecto está estable tiene sentido volver a hablar de funcionalidades nuevas. Evolucionar sobre una base inestable multiplica el coste de cada cambio.

Paso 4: decidir si compensa reescribir

A veces la auditoría concluye que el código está tan mal que mantenerlo sale más caro que rehacerlo. Es una decisión legítima, pero conviene tomarla con datos, no por frustración. Señales de que una reescritura puede compensar:

• La tecnología base está descatalogada y no hay ruta de actualización realista.
• Cada cambio pequeño rompe tres cosas en otro sitio, de forma sistemática.
• El coste de estabilizar y mantener, proyectado a dos o tres años, se acerca al de un desarrollo nuevo.

Y señales de que no compensa todavía:

• El software cubre bien el proceso de negocio y el problema es solo de mantenimiento.
• Buena parte de la lógica es correcta y reutilizable, aunque el envoltorio esté anticuado.
• No hay tiempo ni presupuesto para parar la operación mientras se rehace.

Cuando la reescritura es la opción, casi siempre se hace por fases, reutilizando lo que sirve y sustituyendo módulo a módulo, no apagando lo viejo de un día para otro.

El orden importa

Auditar, recuperar accesos, estabilizar y, solo entonces, decidir si evolucionar o reescribir. Saltarse pasos —sobre todo empezar por "lo rehacemos"— es lo que convierte un problema acotado en un proyecto caro.

Si estás en esta situación y quieres una valoración concreta de tu caso, esto es exactamente lo que cubre el servicio de rescate de software: auditoría del proyecto, recuperación del control, estabilización y, a partir de ahí, evolución y mantenimiento con un responsable técnico que se queda.

---

Lecturas relacionadas

• Mantenimiento de software: qué incluye y cada cuánto hay que tocarlo — Qué se hace de verdad en el mantenimiento continuo, que es donde debería acabar un proyecto ya estabilizado.
• Cuánto cuesta el desarrollo de software a medida — Referencias de precio útiles si la auditoría concluye que compensa rehacer por fases.