How to hand off a codebase when your developer leaves

The short answer

A safe developer handoff comes down to four things, in priority order: access (you can get into everything without them), deployability (someone else can safely ship a change), recoverability (backups exist and restore), and knowledge (the undocumented decisions leave their head before they leave the building).

If the developer is still around and cooperative, this takes a week or two of structured work. If they’re already gone, it becomes archaeology — doable, but slower and riskier. Start now, whichever situation you’re in.

First, the mindset: assume goodwill, verify everything

Most departing developers aren’t hostile — they’re busy, checked out, or simply unaware of how much lives only in their head. The handoff process shouldn’t feel like an interrogation; it should feel like a checklist you work through together.

But verify rather than accept. “The backups run nightly” is a claim; a restored backup is a fact. “It’s all in the repo” is a claim; a fresh machine that can run the project is a fact. Every item below has a verification step for exactly this reason.

The access checklist

Work through this while the developer is still reachable. Missing access is the number-one thing that turns departures into emergencies.

• Source code — you have owner/admin rights on the repository host (GitHub, GitLab, Bitbucket), under an organization account you control rather than the developer’s personal account. Verify: log in yourself, clone the repo.
• Hosting and infrastructure — cloud console, server SSH keys, container registry, DNS management. Verify: log into each.
• Domain registration — in the business’s name, at a registrar the business controls. Developer-registered domains are a classic hostage situation, usually accidental.
• Databases — admin credentials, and knowledge of where they run.
• Third-party services — payment processors, email senders, APIs, monitoring, error trackers. Ask for a list of every service the system touches; then check the code’s config files for ones they forgot.
• Secrets and environment variables — where do production credentials live? If the answer is “in a file on my laptop,” fixing that is today’s task.
• Password manager transfer — everything above goes into a business-controlled vault, and the developer’s personal accounts come off the admin lists after transition.

The deployability checklist

The scariest moment after a departure is the first change nobody dares to ship.

• A written deploy runbook — the exact steps from “code change” to “live,” including the weird parts (“wait for the cache job,” “never deploy Fridays because of the billing run”). Have the developer write it, then have someone else follow it while the developer watches silently. Every step they’re forced to interject on is a gap in the doc.
• A development environment that builds from scratch — a new machine, following the README, reaches a running app. This surfaces the undocumented dependencies.
• Rollback steps — what do you do when a deploy goes wrong? If the answer has never been tested, test it.

The recoverability checklist

• Backups: what, where, how often — database, uploaded files, configuration.
• An actual test restore — this is non-negotiable and skipped by almost everyone. An untested backup is a hope. Restore to a scratch environment and confirm the app runs against it.
• Monitoring and alerts — what tells you the system is down, and who receives it? If the answer was “the developer noticed,” you now have a monitoring gap; close it with even a basic uptime check.

The knowledge extraction

Code shows what the system does. What leaves with the developer is why — and the whys are what make future changes safe.

Run one or two recorded sessions, walking through:

• The tour: overall architecture, in plain language — what are the parts, what talks to what.
• The bodies: “What parts of the system are you least proud of? What would you touch last?” Developers answer this question honestly and it’s pure gold.
• The landmines: known bugs, fragile areas, things with weird workarounds, that one customer whose account is special-cased.
• The rhythms: scheduled jobs, monthly billing runs, renewal dates for domains/certificates/services — the calendar of things that will fail silently in month three.
• The unfinished: half-done features, branches never merged, migrations half-applied.

Record the calls. Transcripts of two hours of candid walkthrough outperform most written documentation, because they capture the hesitations — “oh, and one thing about that module…”

The first 30 days after

• Change credentials the developer had personal access to (not out of distrust — out of hygiene, and for their protection as much as yours).
• Ship a small, low-risk change end-to-end early. Deployability decays fast; exercising it while the runbook is fresh keeps it real.
• Watch error logs and inboxes for the automated things nobody mentioned — they announce themselves by failing.
• Decide who owns the system now. “Nobody, for the moment” is how systems drift into rescue territory — an ongoing support arrangement is precisely this ownership, purchased in a predictable monthly form.

If they’re already gone

The checklist is the same; the method changes. Access recovery comes first (registrars, hosts, and platform support teams all have processes for business ownership recovery — slower than asking, but they work). Then the code itself becomes documentation: config files list the services, scheduled jobs reveal the rhythms, commit history tells you where the fragile parts are by how often they got patched.

This is a common starting point for rescue work — see this inherited-app case, where the developer was gone before anyone knew what the deploy steps were. Recoverable, but everything takes three times longer than it would have in a structured handoff.

FAQ

How long should a developer handoff take?

With a cooperative developer: one to two weeks alongside their normal notice period — mostly the verification steps and knowledge sessions. Without them: expect four to eight weeks of gradual reconstruction before the system is confidently changeable.

What if the departing developer is uncooperative or the split is hostile?

Prioritize ruthlessly: legal/contractual access to code and accounts first (your contract and local law usually support this), credentials rotated immediately after, knowledge extraction written off. The checklist still works — you just fill it in from the outside.

Should the new developer overlap with the old one?

If at all possible, yes — even a few paired sessions transform the handoff. The “someone else follows the runbook while they watch” test is the single highest-value hour of the entire process.

We can’t hire a replacement yet. What’s the minimum safe state?

Access secured, one test restore done, deploy runbook written, uptime monitoring pointed at someone’s phone. That’s a system that can idle safely for months. A Business Systems Audit can get you to that state quickly and tell you what can wait.

Facing a departure right now?

Whether the developer leaves in a month or left last quarter, the path is the same checklist. If you’d rather have someone run it with you — and stay on afterward as the person who answers — that’s what ongoing software support is for. Get in touch.