Recovering source code is not simply downloading a folder from a server. A usable repository should show the current code, history, branches, releases and enough context to identify what is running in each environment. The aim is to restore controlled development, not merely to collect files.
Clarify the recovery situation
The appropriate response depends on what remains available:
| Situation | Priority |
|---|---|
| Supplier is cooperating | Arrange an orderly transfer of repository, access, history and deployment knowledge. |
| Repository exists but access is lost | Use organisation ownership, administrator recovery and verified account contacts. |
| Only a production server is available | Preserve the environment, obtain a copy and assess whether the deployed files are complete source code. |
| Only old archives or developer laptops exist | Collect evidence, compare versions and rebuild a controlled repository. |
| No credible source is available | Stabilise the live service and assess replacement or reconstruction options. |
Preserve evidence before changing anything
During a difficult takeover, avoid immediately editing production or overwriting repositories. Record:
- current account owners and access levels;
- repository URLs and organisation settings;
- production release identifiers and timestamps;
- server and application versions;
- deployment logs and pipeline configuration;
- available backups and archives;
- the source of each recovered copy.
Create protected copies before attempting repairs. This preserves the ability to compare and roll back.
Confirm that the repository is complete
A repository can appear healthy while omitting essential parts of the system. Check for:
- application source and configuration templates;
- database migrations or schema definitions;
- dependency manifests and lock files;
- build and deployment scripts;
- tests and representative test data procedures;
- infrastructure definitions where used;
- documentation for scheduled jobs and integrations;
- release tags or another reliable production history.
Secrets should not be stored directly in the repository. Their absence is normal, but the location and recovery process for required secrets must be documented.
Match recovered code to production
The most important technical question is whether the recovered code can reproduce the live application. Use evidence such as deployment records, commit identifiers, artefact hashes, release notes and controlled test builds.
Do not declare recovery complete solely because the pages look similar. Background jobs, integrations, reporting and data migrations may differ.
Recover control of the repository platform
Where the repository sits in GitHub, GitLab, Bitbucket, Azure DevOps or another hosted platform, establish:
- which organisation or workspace owns it;
- who has owner-level administration;
- billing and recovery contacts;
- protected branch and approval rules;
- deployment keys, tokens and connected applications;
- webhooks and CI/CD integrations;
- off-platform backups or mirrors.
Move control through documented platform procedures. Do not solve a governance problem by sharing one personal account.
Rebuild a controlled working baseline
- Place the best verified copy in a business-controlled repository.
- Mark the source and date of uncertain material.
- Create a reproducible development or test environment.
- Build and run the application without relying on one person's workstation.
- Compare important journeys and integrations with production.
- Record gaps, unsupported components and urgent risks.
- Tag the verified baseline and restrict uncontrolled changes.
Legal and licence checks
Access to code does not by itself establish the right to use, modify or transfer it. Review the relevant contracts, assignments and licences, including supplier background components and open-source obligations. If ownership is disputed or the supplier has failed, obtain specialist advice before redistributing or materially modifying uncertain code.
Recovery acceptance checklist
| Area | Completion evidence |
|---|---|
| Administrative control | Business has tested owner-level recovery and named administrators. |
| Completeness | Code, migrations, dependencies, build and deployment material are present. |
| Production match | Current deployed release is linked to a verified commit or artefact. |
| Reproducibility | Authorised team can build and run a representative environment. |
| Rights | Use, modification and transfer position has been reviewed. |
| Continuity | Repository is backed up and no longer depends on one personal account. |
Prove the recovered baseline
Ask the receiving team to produce a clean build from the recovered repository and link it to the release currently running in production. Any manual file, undocumented dependency or inaccessible account discovered during that exercise becomes a specific recovery action.