Recuperación de proyectos
Su aplicación ya no funciona: ¿qué comprobar antes de reconstruirla?
Accesos, código, datos, recorridos y despliegue: una lista para decidir qué reparar o reconstruir, ilustrada por la recuperación de HODNOS.
La respuesta en breve
Una aplicación bloqueada exige primero hechos: qué falla, qué sigue siendo accesible y qué debe preservarse. Estas constataciones permiten elegir entre una reparación, una recuperación específica y una reconstrucción.
- Recupere los accesos, el código y los datos antes de introducir cambios en la aplicación utilizada.
- Decida a partir de los recorridos y las limitaciones constatadas: la antigüedad de una tecnología no basta para justificar una reescritura.
- Incluya pruebas, transición y traspaso en el alcance de recuperación, con criterios de validación explícitos.
- ComprenderCódigo, accesos y recorridos
- ProtegerCopias y control de versiones
- RelanzarFunciones útiles y pruebas
Describa lo que ya no funciona
Que una página se muestre no demuestra que la aplicación funcione. Un usuario puede ver su cuenta sin poder reservar, pagar o recuperar una solicitud. Empiece por las acciones de negocio: ¿quién intenta hacer qué, en qué momento y con qué resultado? Conserve un ejemplo reproducible y el mensaje de error, si lo tiene.
Para un directivo, esta descripción permite jerarquizar las consecuencias: solicitudes perdidas, trabajo manual o actividad interrumpida. Para el equipo técnico, proporciona un punto de partida verificable. Distinga una avería reciente de una función que nunca ha sido operativa. La respuesta a una regresión conocida puede diferir de la recuperación de un producto inacabado.
El recorrido esperado
Ejemplo: un cliente elige una franja horaria, confirma su reserva y recibe la confirmación.
El punto de fallo
Indique el paso exacto, la cuenta de prueba utilizada y el comportamiento observado, sin enviar contraseñas en el documento inicial.
La prioridad de negocio
Precise si existe una alternativa provisional y qué operaciones deben reanudarse primero.
Recuperar lo necesario para intervenir
El diagnóstico depende de los elementos accesibles. El código desplegado puede diferir del repositorio; puede existir una copia de seguridad sin que se haya verificado su restauración. Hay que conciliar las fuentes, la aplicación realmente utilizada y los datos. Este paso evita decidir sobre una versión incompleta del proyecto.
Precise quién controla cada servicio y cómo se transmitirán los accesos. Puede empezar por un inventario sin modificar la producción. Antes de intervenir, acuerde las copias de seguridad necesarias y el procedimiento que seguir si el cambio no ofrece el resultado esperado.
- Código fuente disponible, repositorio Git y versión correspondiente a la aplicación desplegada.
- Alojamiento, dominio, certificados y procedimiento de despliegue identificados.
- Base de datos, archivos de usuarios, exportaciones y copias de seguridad localizados.
- Servicios de terceros enumerados: pagos, emails, almacenamiento, autenticación y API.
- Cuentas de prueba, registros de errores y documentación disponibles.
- Responsables de los accesos y condiciones de traspaso definidos.
¿Reparar, recuperar una parte o reconstruir?
Un código PHP antiguo o un MVP construido con una herramienta visual no son, por sí solos, motivos para rehacerlo todo. La decisión depende de lo que siga siendo aprovechable, los datos que preservar, los usos esperados y la capacidad de verificar las próximas evoluciones. Un cambio de tecnología debe responder a una limitación identificada.
Una buena propuesta explica qué conserva, qué sustituye y por qué. También precisa las incertidumbres que debe despejar el diagnóstico. Si el problema aún se entiende mal, comprometerse de inmediato con una reforma completa dificulta comparar el coste de reparar con el de reconstruir.
| Constatación por confirmar | Opción que considerar | Verificación esperada |
|---|---|---|
| Un cambio reciente ha roto un recorrido antes fiable | Corrección específica o vuelta a una versión conocida | Reproducir el fallo y verificar el recorrido tras la corrección. |
| Algunos módulos funcionan y siguen siendo accesibles | Recuperación progresiva de las partes defectuosas | Probar los intercambios entre los elementos conservados y sustituidos. |
| El producto funciona, pero su despliegue sigue siendo manual y frágil | Mayor fiabilidad del despliegue y la explotación | Desplegar una versión identificada y preparar una reversión. |
| Los recorridos esenciales no son utilizables y se puede recuperar muy poco código | Reconstrucción del alcance prioritario | Justificar los elementos conservados y validar los datos migrados. |
HODNOS: poner de nuevo en marcha una plataforma tras varios intentos
HODNOS conecta clientes con artistas. Al asumir el proyecto, los recorridos esenciales de reserva, pago y mensajería ya no eran realmente utilizables. La aplicación se basaba en código PHP antiguo, modificado directamente por FTP en un servidor OVH, sin control de versiones en GitHub. Varios desarrolladores habían intervenido sin conseguir ponerla de nuevo en funcionamiento.
CUB3 recuperó el código, creó el repositorio Git e identificó los pocos elementos útiles para la migración. La misión pasó después a reconstruir casi toda la plataforma: registro, reservas, pagos, mensajería y back-office. La infraestructura se trasladó a AWS y se describió con Terraform. Web, iOS y Android se entregaron en tres meses, con tres miembros de CUB3 movilizados.
Este resultado corresponde a la restauración del funcionamiento y a una entrega técnica. No demuestra un resultado comercial, y tres meses no es un plazo universal de recuperación. La lección útil es el método: recuperar, establecer los hechos, elegir los elementos que reconstruir y después verificar los recorridos esenciales.
Defina qué significa «de nuevo en funcionamiento»
Una recuperación debe conducir a criterios que pueda comprobar. Sustituir una captura por una demostración completa del recorrido permite verificar los pasos, los permisos y los datos. Precise también los casos de fallo: pago rechazado, dato ausente o cuenta no autorizada, según su producto.
La puesta en línea forma parte del trabajo que preparar. Acuerde las condiciones de transición, las posibles interrupciones, la verificación de los datos y quién está autorizado para decidir. El seguimiento tras la entrega debe ser explícito: quién recibe una incidencia, cómo se evalúa y qué acompañamiento se ha acordado.
- Los recorridos acordados se demuestran con los perfiles correspondientes.
- Los datos recuperados se comprueban según criterios acordados.
- La versión entregada y las condiciones de despliegue son identificables.
- La transición, las verificaciones y la reversión están preparadas.
- Se transmiten los accesos, la documentación y el seguimiento tras la entrega.
Sobre el terreno
Un proyecto concreto
PHP antiguo, modificaciones por FTP y ausencia de control de versiones en GitHub: una plataforma recuperada, con web, iOS y Android entregados en tres meses.
La recuperación de HODNOS