When the Vendor Disappears: Recovering Code, Domains, and Infrastructure

Short answer: treat the first two weeks as a forensic exercise, not a development sprint. Before anyone writes code, establish what you actually control — domains, DNS, source control, cloud accounts, databases, secrets, third-party services — and in what order you need to recover it. The dangerous cases are not missing code; they are assets registered to a person or an account you no longer have access to.

When a vendor leaves, the first job is finding out what you actually control.

Assume nothing about ownership until you verify it

The failure mode is almost never "the code is gone". It is one of these:

• The domain is registered in the vendor's account, and the renewal email goes to an address nobody reads.
• DNS is managed by the vendor's Cloudflare or registrar account, so you cannot change a record or issue a certificate.
• Source control is a repository inside the vendor's organisation, and your access was a team membership that has now been removed.
• The cloud account is in the vendor's name, with production data inside it.
• The only copy of some configuration lives in a former contractor's personal notes.
• Deployments depend on an API token that only one person had.

Each of these is recoverable, but some take days of negotiation and identity verification, so they need to be found on day one. Verify, do not assume: check the registrar record, the nameserver delegation, the repository owner, and the billing account for each service.

Build the asset map

Work through asset classes in a fixed order and record, for each one, what you verified rather than what you were told. This table is the spine of the recovery.

If you cannot produce evidence for a row, mark it unknown and chase it. An unknown is a risk, not a footnote.

Recover in the right order

Order matters because each step unlocks the next.

1. Domains and DNS. Confirm the registrar and the nameserver delegation. If the domain is in the vendor's account, request a transfer or a registrar-level change immediately, because it requires the vendor's cooperation or an ownership dispute process, and both take time.
2. Source control. Get admin rights on the repository organisation, or clone the full history to an organisation you control — including tags, branches, and CI configuration. History matters: it is often the only record of why something is the way it is.
3. Cloud and hosting accounts. Establish owner-level access under your own identity. Export the infrastructure inventory: instances, storage buckets, managed databases, queues, scheduled jobs, and their regions.
4. Secrets rotation. Assume every credential the vendor could have seen is compromised. Rotate in dependency order: database, then application secrets, then third-party API keys, then deploy tokens. Keep a list of what was rotated and when.
5. Environments. Rebuild staging and production definitions as code or as documented steps. Verify that you can restore the database from backup into an isolated environment and that the application starts.
6. Deployments. Re-establish a pipeline you own. The first goal is a trivial, reversible deploy — a text change on a page — not a feature release.
7. Monitoring and alerting. Route errors, uptime checks, and cost alerts to your own channels before you touch anything else.
8. Documentation. Write down the runbook while the knowledge is fresh: how to deploy, how to restore, who to call, what is still unknown.

Steps one through four are the critical path. Development work starts after step six. Once access is recovered, the work shifts from recovery to stabilisation, which is the phase our software project rescue plan covers.

Domains and DNS deserve their own plan

Domain recovery is the step most likely to be blocked by a third party, so start it first and track it daily. Practical notes:

• A registrar transfer requires the domain to be unlocked and the registrant contact to approve. If the registrant email belongs to the former vendor, you may need the registrar's ownership dispute process, which requires documentation: invoices, contracts, correspondence, or a trademark record.
• If the vendor will cooperate, the fastest path is a transfer with the auth code plus an immediate nameserver change to a DNS provider you control.
• Export the zone file before changing nameservers, and lower TTLs on records you plan to change.
• Watch email records specifically. Losing MX or SPF/DKIM configuration can silently break password resets and outbound mail — a failure that surfaces days later.
• Certificates renew automatically only if the DNS-01 challenge or HTTP-01 path still works. After a DNS move, verify issuance rather than waiting for an expiry.

Rotate credentials before you trust the code

It is tempting to get the system running first and clean up credentials later. That ordering is backwards. Until you rotate, every former team member retains access to production, and any malicious change they made is indistinguishable from yours.

Rotation checklist:

• Inventory every credential: environment variables, CI secrets, database users, service accounts, API keys, webhook signing secrets, SSH keys, and personal access tokens.
• Rotate in dependency order and verify the application after each group, so a failure is attributable.
• Revoke rather than rotate where the credential is no longer needed.
• Check for long-lived credentials that bypass your new controls: personal tokens in CI, deploy keys on repositories, and service accounts with static passwords.
• Review audit logs for the handover window — logins, permission changes, exports, and deletions — and preserve them.
• After rotation, confirm no unexpected process breaks in the following week; a silent integration failure is the usual symptom of a missed secret.

Run the legal and contractual track in parallel

Technical recovery and contractual recovery are different workstreams with different clocks. In parallel with the steps above:

• Read the original agreement for IP assignment, source-code ownership, and handover obligations. In most agreements the client owns the deliverables, but the practical question is access, not ownership.
• Send a written handover request listing the exact assets and access needed, with a deadline and a named contact.
• Preserve evidence: invoices, email threads, and repository metadata that establish the working relationship.
• If the vendor is unresponsive, involve counsel early on the domain and account questions, because registrar and cloud provider processes have their own evidence requirements.
• Notify the parties who depend on the system — customers, payment providers, email senders — only when there is a concrete reason, and keep the message factual.

What to document so it does not happen again

The recovery is also the specification for your next vendor relationship. Write down:

• An access register with named owners for every asset, reviewed quarterly.
• A rule that domains, cloud billing, and source-control organisations are always in the client's name, with vendor access granted as a revocable membership.
• An exit checklist in the contract: asset list, credential rotation, documentation, and a knowledge-transfer window.
• A backup policy you own and test, independent of any vendor's tooling.
• A single "bus factor" document listing the two people who can do each critical operation.

Limitations and assumptions

This sequence assumes you have a legal entity that can prove ownership of the accounts and a working relationship you can document; a project started informally by a founder's personal account takes longer to untangle and may need counsel. It assumes the code is not malicious. Where you suspect intentional harm — backdoors, exfiltration, sabotage — the order changes: isolate, preserve evidence, and involve security and legal specialists before rotating anything, because rotation destroys some forensic evidence. It also assumes you can afford a short freeze on feature work; teams that try to recover access and ship features in the same two weeks usually do both badly. Finally, nothing here replaces reading the actual contract, which is the only place your real rights are written down.

Working with CodeAustral

We take over inherited codebases and half-finished systems, starting with access, ownership, and a reproducible deploy before any feature work. If you are mid-recovery, send a short brief with what you have verified so far, or look at how we scope rescue work and we will map the critical path with you.

Frequently asked questions

The vendor is cooperating. Do we still need to rotate everything?

Yes. Rotation is not an accusation; it is the point at which you can state with confidence who has access. Even with full cooperation, you cannot verify which credentials were copied to personal machines, so treat them all as exposed and rotate in dependency order.

Can we keep using the vendor's cloud account for a while?

Only with a written plan to migrate and a hard date. Running production in an account you do not own means you cannot control billing, access, or data location, and every day increases the migration cost. If you must stay temporarily, get owner-level access under your identity and document the exit path.

What if the domain is registered to the former contractor personally?

Start the registrar's ownership dispute process immediately and in parallel ask the contractor to transfer it voluntarily. Gather invoices, contracts, and correspondence showing the domain was used for the business. This is the slowest recovery path in the list, which is why it belongs on day one.

How long does recovery usually take?

With cooperation, the critical path — domains, source control, cloud ownership, and credential rotation — is typically one to three weeks. Without cooperation, domain and account disputes can take considerably longer, so the practical approach is to secure what you can immediately and run the disputed items as a separate track.