Project recovery
Your application no longer works: what should you check before rebuilding it?
Access, code, data, user journeys and deployment: a checklist for deciding what to repair or rebuild, illustrated by the HODNOS recovery.
The short answer
A stalled application first needs facts: what fails, what remains accessible and what needs preserving. These findings help you choose between a repair, a targeted recovery and a rebuild.
- Recover access, code and data before making changes to the application in use.
- Decide from observed journeys and constraints: the age of a technology alone does not justify a rewrite.
- Include testing, cutover and handover in the recovery scope, with explicit acceptance criteria.
- UnderstandCode, access and journeys
- SecureBackups and version control
- RelaunchUseful features and tests
Describe what no longer works
A page loading does not prove the application works. A user may see their account while being unable to book, pay or find a request. Start with business actions: who is trying to do what, at which point and with what result? Keep a reproducible example and the error message, if one is available.
For a business leader, this description helps rank the consequences: lost requests, manual work or interrupted activity. For the technical team, it provides a verifiable starting point. Distinguish a recent failure from a feature that has never worked. The response to a known regression may differ from taking over an unfinished product.
The expected journey
Example: a customer chooses a time slot, confirms a booking and receives confirmation.
The point of failure
Specify the exact step, test account used and observed behaviour, without sending a password in the brief.
The business priority
State whether a workaround exists and which operations need to resume first.
Recover what is needed to intervene
Diagnosis depends on what is accessible. Deployed code can differ from the repository; a backup may exist without its restoration having been checked. The sources, the application actually in use and the data must be reconciled. This step avoids decisions based on an incomplete version of the project.
Clarify who controls each service and how access will be transferred. You can start with an inventory without changing production. Before intervening, agree the necessary backups and the procedure to follow if a change does not give the expected result.
- Available source code, Git repository and version matching the deployed application.
- Identified hosting, domain, certificates and deployment procedure.
- Located database, user files, exports and backups.
- Listed third-party services: payments, emails, storage, authentication and APIs.
- Available test accounts, error logs and documentation.
- Defined access owners and handover arrangements.
Repair, recover part of it or rebuild?
Old PHP code or an MVP built with a visual tool is not, on its own, a reason to redo everything. The decision depends on what remains usable, the data to preserve, expected usage and the ability to verify future changes. A technology change should address an identified constraint.
A good proposal explains what it keeps, what it replaces and why. It also states the uncertainties diagnosis needs to resolve. If the issue is still poorly understood, immediately committing to a full redesign makes it difficult to compare repair and rebuilding costs.
| Finding to confirm | Option to consider | Expected verification |
|---|---|---|
| A recent change broke a previously reliable journey | A targeted fix or a return to a known version | Reproduce the failure and verify the journey after the fix. |
| Some modules work and remain accessible | Progressive recovery of failing parts | Test exchanges between retained and replaced components. |
| The product works, but deployment remains manual and fragile | More reliable deployment and operations | Deploy an identified version and prepare a rollback. |
| Essential journeys are unusable and very little code can be reused | Rebuild the priority scope | Justify retained elements and validate migrated data. |
HODNOS: restoring a platform after several attempts
HODNOS connects customers with artists. At takeover, essential booking, payment and messaging journeys were no longer really usable. The application relied on old PHP code, edited directly over FTP on an OVH server, without version control on GitHub. Several developers had worked on it without managing to restore it to working order.
CUB3 recovered the code, created the Git repository and identified the few elements useful for migration. The assignment then involved rebuilding almost the entire platform: registration, booking, payment, messaging and back-office. The infrastructure moved to AWS and was described with Terraform. Web, iOS and Android were delivered in three months, with three CUB3 team members involved.
This result concerns restored functionality and technical delivery. It does not demonstrate a commercial outcome, and three months is not a universal recovery timeline. The useful lesson is the approach: recover, establish the facts, choose what to rebuild, then verify essential journeys.
Define what “working again” means
A recovery should lead to criteria you can check. Replacing a screenshot with a complete journey demonstration lets you verify the steps, permissions and data. Also clarify failure cases: a declined payment, missing data or an unauthorised account, according to your product.
Going live is part of the work to prepare. Agree cutover conditions, possible interruptions, data verification and the person authorised to decide. Post-delivery follow-up should be explicit: who receives a report, how it is assessed and what support has been agreed.
- The agreed journeys are demonstrated with the relevant user profiles.
- Recovered data is checked against agreed criteria.
- The delivered version and deployment conditions are identifiable.
- Cutover, checks and rollback are prepared.
- Access, documentation and post-delivery support are handed over.
In the field
A real project
Old PHP, FTP changes and no GitHub version control: a platform restored to working order, with web, iOS and Android delivered in three months.
The HODNOS recovery