Rescatar un proyecto web abandonado: qué revisar antes de seguir
Tu proveedor ha desaparecido o el proyecto se ha quedado a medias. Qué recuperar primero, qué revisar del código y cómo decidir entre continuar, mejorar por fases o rehacer.
5 min de lectura
Pasa más de lo que parece. El programador que hizo la aplicación ya no contesta. La agencia cerró o dejó de dar soporte. El proyecto lleva meses "casi terminado". O la aplicación funciona, pero nadie se atreve a tocarla porque la última vez que alguien cambió algo dejó de funcionar la facturación.
Mientras tanto, el negocio depende de ella. Este artículo explica qué hacer, en orden, para recuperar el control y decidir con datos si seguir con lo que hay o empezar de nuevo.
Primero: recupera los accesos
Antes de mirar una sola línea de código, asegúrate de que tienes en tu poder todo lo necesario para que la aplicación siga funcionando aunque el proveedor no vuelva nunca:
Dominio: que esté registrado a nombre de tu empresa y que tengas acceso al panel del registrador. Si el dominio está a nombre del proveedor, es lo primero que hay que resolver.
Servidor o alojamiento: acceso de administrador, quién lo paga y cuándo caduca.
Código fuente: el repositorio completo (Git) con su historial, no solo una copia de los ficheros del servidor.
Base de datos: una copia reciente y el acceso para hacer más.
Servicios de terceros: pasarela de pago, envío de emails, mapas, APIs, certificados, cuentas de tiendas de aplicaciones. Cada uno con su contraseña, a nombre de tu empresa.
Revisa también tu contrato con el proveedor: quién es el propietario del código y en qué condiciones te lo tiene que entregar. Si hay dudas, consúltalo con tu asesor antes de que el problema crezca.
Y haz una copia completa (código y base de datos) fuera del servidor actual. Hoy mismo.
Segundo: entiende qué tienes
Con los accesos asegurados, toca una revisión técnica. Estas son las preguntas que responde:
| Qué se revisa | Por qué importa |
|---|---|
| ¿Está el código en un repositorio con historial? | Sin historial no se sabe qué se cambió, cuándo ni por qué. |
| Versiones del lenguaje, del framework y de las librerías | Las versiones sin soporte no reciben parches de seguridad, y el alojamiento acabará retirándolas. |
| ¿Lo que hay en el servidor coincide con el repositorio? | Es habitual encontrar cambios hechos directamente en el servidor que no están en ningún otro sitio. |
| Seguridad básica | Contraseñas en el código, formularios sin protección, usuarios de administración olvidados. |
| Tests automáticos | Sin tests, cada cambio es una apuesta. Con algunos, se puede cambiar con confianza. |
| Cómo se despliega | Si publicar un cambio consiste en subir ficheros a mano, cualquier despiste rompe la web. |
| Integraciones | ERP, pagos, envíos: qué depende de qué y qué pasa si algo falla. |
| Copias de seguridad | Si existen, si se han probado y dónde están. |
| Qué falta por hacer | En proyectos a medias, la diferencia entre lo que se pidió, lo que se pagó y lo que funciona de verdad. |
El resultado de esta revisión es un informe con los riesgos ordenados por urgencia y una estimación de lo que costaría cada camino.
Tercero: decide el camino
Continuar con lo que hay
Si el código es razonable, está en un framework con soporte (Laravel, Symfony o similar) y los problemas son concretos, lo más barato es seguir: arreglar lo urgente y continuar el desarrollo.
Mejorar por fases
Es la opción más habitual. La aplicación funciona y el negocio depende de ella, pero tiene versiones antiguas, poca o ninguna prueba automática y partes frágiles. Se estabiliza primero y se mejora pieza a pieza, sin parar el negocio:
Estabilizar: copias de seguridad probadas, monitorización, parches de seguridad urgentes y un despliegue que no dependa de subir ficheros a mano.
Proteger: tests automáticos en lo que más dinero mueve (pedidos, pagos, facturación) antes de tocarlo.
Actualizar: versiones del lenguaje y del framework, por pasos.
Mejorar: nuevas funciones y rediseño de las partes que lo necesiten.
Rehacer
Rehacer desde cero es tentador y casi siempre más caro y más largo de lo que parece, porque la aplicación antigua tiene años de reglas de negocio que nadie documentó. Solo compensa cuando la base es irrecuperable: tecnología sin futuro, código que nadie puede leer o una arquitectura que no soporta lo que el negocio necesita ahora. Incluso entonces, conviene hacerlo por partes, sustituyendo módulos mientras la aplicación antigua sigue funcionando.
Cuánto cuesta
Como orientación, sin IVA, el rescate o la migración de un proyecto existente cuesta entre 3.000 y 12.000 € y lleva de 3 a 8 semanas: revisión, estabilización y las primeras mejoras. Lo que venga después (terminar funcionalidades pendientes, nuevas fases) se presupuesta aparte, ya con la aplicación bajo control.
Si quieres un rango para tu caso, descríbelo en nuestro asistente de proyectos.
Cómo evitar que vuelva a pasar
El dominio, el alojamiento y las cuentas de servicios, siempre a nombre de tu empresa.
El código en un repositorio al que tengas acceso, con cada cambio registrado.
Un contrato que diga que el código es tuyo y cómo se entrega si la relación termina.
Documentación mínima: cómo se instala, cómo se despliega y qué integraciones tiene.
Más de una persona capaz de mantener la aplicación, aunque sea de otro proveedor.
Si tu aplicación está en esta situación, escríbenos: empezamos por la revisión y te decimos con franqueza si merece la pena seguir con lo que hay. Puedes ver cómo trabajamos los rescates en rescate de proyectos web. Si lo que se ha quedado sin soporte es una tienda online, mira antes cómo migrar sin perder posicionamiento.