Heredar un software sin proveedor: qué hacer cuando quien lo hizo ya no está
El programa funciona, pero quien lo construyó desapareció: sin documentación, sin accesos claros y sin nadie que se atreva a tocarlo. Los pasos para retomar el control de un software heredado — sin dramatismo y sin rehacerlo por sistema.
Respuesta corta: primero asegura lo urgente — accesos, copias y dominios — antes de decidir nada. Después, una auditoría externa del estado real: qué hay, en qué estado está y qué implica mantenerlo. Solo entonces se decide entre tres caminos: retomar el mantenimiento, evolucionar sobre lo que hay, o planificar la sustitución por fases mientras el sistema sigue sosteniendo la operación. Lo que no hay que hacer: ni tocarlo a ciegas, ni rehacerlo por sistema, ni seguir un año más cruzando los dedos.
Un escenario mucho más común de lo que parece
El desarrollador freelance que cambió de vida, la empresa que cerró, el proveedor que responde cada vez más tarde hasta que deja de responder, el empleado que se fue con las contraseñas en la cabeza. El resultado es el mismo: un sistema del que depende tu operación diaria y nadie que responda por él. Suele convivir con una mezcla de miedo («que nadie lo toque, que funciona») y parálisis («habría que hacer algo con esto») que puede durar años — cada uno de ellos, acumulando riesgo.
Fase 1 — Asegura, antes de decidir (esta semana)
Sin tocar una línea de código:
- Inventaría los accesos: servidor u hosting, dominio, base de datos, panel de administración, repositorio de código si existe, cuentas de servicios conectados. ¿Cuáles tienes tú y cuáles tenía solo el proveedor?
- Recupera la titularidad de lo que no controles — el dominio y el hosting a nombre de tu empresa, no del proveedor desaparecido. Es lo primero porque es lo que puede convertir un problema en una emergencia.
- Haz una copia completa ahora — aplicación y datos — y guárdala fuera del servidor. Aunque esté mal hecha, aunque no sepas restaurarla: una copia de hoy vale oro el día que algo pase.
- Documenta lo que el equipo sabe: quién lo usa, para qué, qué falla de vez en cuando, qué trucos conoce la persona que más lo usa. Ese conocimiento oral es parte del sistema.
Fase 2 — Auditoría del estado real (sin compromiso de nada)
Con lo urgente asegurado, toca saber qué tienes entre manos — y esto sí conviene que lo haga alguien externo con criterio:
- ¿Existe el código fuente y es accesible? No es raro descubrir que solo existe lo desplegado, o que el código está pero sin la pieza que lo compila.
- ¿En qué estado está?: tecnologías, versiones, seguridad, dependencias abandonadas, deuda acumulada.
- ¿Qué hace exactamente? — que no siempre coincide con lo que el equipo cree que hace.
- ¿Qué costaría mantenerlo, evolucionarlo o sustituirlo? Con órdenes de magnitud honestos, no con un presupuesto de rehacerlo todo disfrazado de auditoría.
Es exactamente el tipo de análisis acotado, con entregable y sin compromiso, que hacemos como Discovery: un documento con el estado real y los caminos posibles, con el que puedes decidir — con nosotros o con quien quieras.
Fase 3 — Los tres caminos (y cómo elegir)
1. Retomar el mantenimiento. Si el sistema es razonablemente sólido, un proveedor serio puede hacerse cargo: ordenar accesos, montar copias verificadas y monitorización, y responder por él con tiempos por escrito. Es el camino más corto para dormir tranquilo.
2. Evolucionar sobre lo que hay. Si además el negocio necesita cosas nuevas, muchas veces se puede construir alrededor — integrarlo, ampliarlo por módulos — sin tirar lo que funciona.
3. Sustituir por fases. Si la auditoría revela que el sistema es insostenible (tecnología muerta, sin código fuente, seguridad irrecuperable), se planifica la sustitución mientras el viejo sigue funcionando: software a medida por fases, empezando por lo más crítico, con migración de datos incluida. Sin big-bang: el sistema viejo se apaga cuando el nuevo ya sostiene la operación.
La trampa a evitar: el proveedor que, sin auditar nada, sentencia «esto hay que rehacerlo entero». A veces es verdad; muchas veces es la venta fácil. Exige el diagnóstico antes que el veredicto.
Y para que no vuelva a pasar
El día que retomes el control, deja tres cosas por escrito con quien sea que trabaje contigo desde entonces: la propiedad (código, datos y accesos a tu nombre), la documentación como entregable de cada trabajo, y la salida — que cambiar de proveedor sea siempre posible. Un sistema del que eres dueño de verdad no vuelve a quedarse huérfano.
¿Dependes de un sistema del que ya nadie responde? Empecemos por saber qué tienes: una revisión externa, con entregable, sin compromiso. Cuéntanos tu caso →
Servicios relacionados: Mantenimiento y evolución · Consultoría y Discovery
Sobre el autor
Oscar Blanco
Fundador y responsable técnico de MUROSOFT
Desarrollador fullstack con más de una década construyendo software para empresas. En MUROSOFT analiza el proceso antes que la tecnología: qué se hace hoy, qué cuesta y qué merece la pena automatizar. Trabaja de forma directa con quien va a usar el sistema, sin capas intermedias entre el problema y quien lo resuelve.