Suppose your application is still serving customers, but its original agency is no longer available. You have source code and some credentials, yet no demonstrated way to restore the data or release a change. Your immediate decision is whether to authorise changes before anyone has proved a recovery path.
To recover an application when the developer is unavailable, start with business continuity: preserve what is working, establish authorised control and test what can be recovered. Agency unavailability alone is no reason to redeploy or rewrite. The framework below combines selected GitHub and AWS guidance with editorial recommendations; it cannot guarantee account transfer, a deployable build or successful recovery.
Stabilise before trying to fix
Appoint a business owner to approve changes and an authorised technical lead to investigate. Ask them to record what is running, preserve available operational records and agency correspondence, and document known faults. Keep preservation work separate from attempts to fix the application.
Do not redeploy production simply to see whether the code works, delete unfamiliar resources or rotate credentials indiscriminately. First ask the technical lead to map which applications, integrations and delivery processes use each credential. Suspected compromise warrants a separate security-containment decision, not an unconditional freeze on changes.
For any proposed production intervention, require a purpose, an approver, an expected service impact and a recovery path. Record unknowns explicitly rather than accepting an assurance that someone can probably deploy.
Establish authorised control and a recovery inventory
Record ownership, access and preservation status separately for each asset. Identify the account holder, the business’s authority to administer it, the authorised access route and unresolved dependencies. Where authority is unclear, seek resolution through contractual and provider account processes. Do not treat possession of a password as permission to take over an account.
Identify administrators and the source record available to preserve.
Identify accounts, running resources and available backups.
Record the registrant, DNS administrator and renewal responsibility.
Identify the automated delivery system and authorised operators.
Record secure locations, custodians and known consumers.
Identify payers, renewal responsibilities and unresolved obligations.
Recommended inventory checks, not transfer instructions. Record secret locations, not secret values.
Parallel checks for authorised control of source, hosting, domain, deployment, configuration and billing.Agree the continuity requirements before judging a recovery test sufficient. Set the recovery time objective (RTO), the target time to restore service, and the recovery point objective (RPO), the acceptable data-loss window. Have the business owner approve both.
AWS’s Reliability Pillar recommends backing up data, applications and configuration to meet RTO and RPO requirements. Use those three categories to check the inventory’s scope rather than accepting source code as the entire recovery package. This is AWS best-practice guidance, not evidence that a particular application will meet its objectives.
Preserve the source record without mistaking it for the system
GitHub documents a mirror clone as a way to back up a Git repository, including its revision history. If the repository uses Git Large File Storage (Git LFS), its LFS objects must also be fetched after the mirror clone. Ask the technical lead to record whether LFS is used and whether that additional step is complete.
A mirror preserves revision history. Fetch LFS objects separately when used.
Assess data, deployment configuration, secrets and external services separately.
GitHub’s repository-backup guidance does not establish recovery of the surrounding application environment.
Repository preservation answers a narrower question than full application recovery.Keep the preserved source record separate from investigation copies, and record what was captured and what remains unknown. Mark repository preservation complete only within that scope; leave application recovery open until it has been tested.
Prove recovery away from production
Commission an isolated examination before considering production deployment. Ask the technical lead to define how the test environment will be separated from live data, credentials and external services before running recovered code. Require explicit approval for any production dependency the investigation needs.
Record source revision, tools, packages, configuration and dependencies.
Document inputs, steps, failures and missing access.
Test restoration and proposed database migrations away from production.
Separate demonstrated recovery from blockers and untested areas.
An editorial investigation sequence, not a vendor-validated procedure or permission to deploy.
Use an isolated rehearsal to identify missing inputs and distinguish repeatable results from assumptions.Request a build record another maintainer can use: exact inputs, versions, configuration requirements and steps. Require a repeat attempt before calling the build reproducible. Keep build success, data restoration and application behaviour as separate results rather than treating any one as proof of the others.
Use the documented blockers to approve the next piece of work, whether that is resolving authorised access, locating a missing input or investigating a failed rehearsal. Keep the scope tied to diagnosis rather than making a rewrite commitment while recoverability remains unknown.
Test restoration against the continuity requirement
AWS’s recovery-testing guidance, in its 31 March 2022 version, calls for verifying that restored data is original, uncorrupted and accessible, with data loss within the workload’s RPO. Confirmation that backup files exist does not satisfy those checks. The guidance concerns data restoration, not proof of application deployability.
- The backup selected and the point in time it represents.
- Methods and results for checking original data, integrity and accessibility.
- The data-loss window compared with the approved RPO.
- Elapsed recovery time, including the rehearsal’s start and end boundaries.
- Failures, untested areas and dependencies still requiring intervention.
Compare the recorded time with the business’s RTO, but require the team to distinguish a database restore from restoration of service. If the rehearsal stops before essential operations are available, do not sign it off as meeting the service recovery target. Retain unmet or untested objectives in the business risk record.
Turn recovery evidence into operating control
Before authorising a production change, require the tested source and configuration, unresolved differences between staging and production, an approver and stop conditions. Specify brief post-deployment checks of essential business operations, often called smoke checks, and name the person who will review their results.
Require a rollback plan that addresses application and data changes separately. Ask what can be reversed, what requires restoration and what happens to data created after deployment. Have the team rehearse the proposed rollback away from production and record its limits. Do not accept “deploy the previous version” as the complete plan.
Put authorised access routes, build instructions, restoration steps, rollback procedures, checks and escalation responsibilities into a runbook alongside the test evidence. Ask a second authorised maintainer to use it in the isolated environment. Record where they need help and revise the instructions before signing off the handoff.
Keep replacement as a separate investment decision, informed by the recovery findings and business requirements. For recovery sign-off, demand evidence that another maintainer can repeat the work within the agreed objectives, with remaining gaps explicitly accepted by the business. Neither an unavailable agency nor one successful build should settle the application’s future.
Could a second maintainer demonstrate recovery without relying on the first?
