Project recovery
Recovering an unfinished web project: where should you start?
Is your website unfinished? Access to recover, diagnosis, quotes by work package, acceptance checks and launch: prepare a recovery with a clear, documented scope.
How do you take over an unfinished web project?
Gather the existing access credentials and files, then request a diagnosis of what works and what is missing. The quote should divide the recovery into verifiable work packages. Define who approves each package, which documents are handed over and which checks take place before launch.
Your website is waiting to launch, the design is incomplete or the previous provider is no longer continuing the project. Before commissioning the next steps, inventory what exists and describe the journeys your customers need to use.
What should you recover before the handover?
Prepare a handover folder identifying locations, responsible people and available versions. Share access through an appropriate channel using dedicated accounts. Passwords, keys and access codes stay out of public documents and project descriptions.
On Shopify, a collaborator request lets you review and grant the permissions needed for the assignment from your store administration.
- Domain: registrant, management account and person responsible for renewal.
- Hosting: provider, administration and environment currently in use.
- CMS or store: owner account, theme and installed extensions.
- Code repository: access, latest version and available instructions.
- Content: text, images, catalogue and approvals already obtained.
- Latest backups: dates, backed-up content and ability to restore.
What if domain access, code or backups are missing?
An incomplete handover does not allow every recovery step to be fixed in advance. For each missing item, record what cannot yet be verified and the next authorised action. Distinguish these three situations.
Without owner access to the domain or hosting, public pages can still be examined, but this cannot confirm that a launch or migration is possible. Identify the domain registrant, the hosting account owner and the relevant providers’ official recovery procedures. Verify the necessary access before setting a launch date.
Without a repository or code archive, you cannot yet determine which developments can be reused or under what conditions they can be changed and redeployed. Request the available deliverables, then verify what can actually be recovered with authorised access. Distinguish recovered files, missing items and outstanding checks. The absence of a repository alone neither requires a complete rebuild nor justifies a promise to recover the code.
Without a backup whose restoration has been tested, you do not have a verified rollback. Document the date and content of available copies and any uncertainties. With authorised access, have the ability to back up the existing site and restore it in a separate environment checked. Address this before any operation that could alter the current site.
The diagnosis should produce three lists: what can be audited immediately, what still depends on access or a document, and work excluded from a firm quote until those dependencies are resolved. For each awaited item, identify who is looking for it and which check will allow work to continue. Then complete the existing delivery checklist with the material actually recovered and the remaining reservations.
What can you keep, and what needs further work?
Request an assessment that distinguishes usable elements, necessary corrections and missing functions. A finished mock-up does not prove that the form, basket or integrations work. Have the important journeys tested on a working version.
The decision to retain or replace the foundation should rest on these observations. Ask which elements are reusable and which obstacles still prevent delivery.
How should you compare a recovery quote?
The quote should name the work packages: diagnosis, design completion, development, content integration, acceptance checks and deployment according to your needs. For each, clarify the deliverables, the information expected from your team, who approves it and the conditions for moving to the next package.
Ask how difficulties discovered during the recovery and additional requests will be priced before committing to that work.
How do you know a work package is complete?
Acceptance checks verify agreed actions on the delivered version. Prepare observable criteria and record reservations with their planned resolution. A screenshot alone is not enough to validate a journey.
Our delivery checklist provides a starting point to adapt to the agreed scope. Its public GitHub version offers documents in French and English to prepare checks and the project handover.
- The visitor finds the offer and submits an enquiry that is actually received.
- In a store, the agreed products, variants and basket work on a phone.
- Your team receives the agreed access, files and procedures.
What should you prepare for deployment and search visibility?
Define who authorises publication, who carries it out and how to return to the previous version. If URLs change, map each old address to its corresponding page and prepare permanent redirects. Google also recommends updating internal links and the sitemap, then monitoring the migration.
At launch, check pages, forms and staging restrictions. Define SEO monitoring and content improvements after launch separately.
An example: taking over Favola-France
Favola-France entrusted Oryon with a Shopify project that had started but remained unfinished. The design was reworked and integrated into an unpublished theme. In the project state described on 1 October 2026, deployment, launch and SEO, AEO and GEO support remain upcoming.
This case helps distinguish work already completed from the next steps. To prepare your recovery, bring the project address, its current state and the functions expected before publication.