Your developer left: what to get handed over so the system isn't orphaned
·2 min read
Developers leave suddenly all the time. What to take back right away, what belongs in the documentation, and a simple way to tell whether the handover is complete.
A message I get a lot: "The developer who built our system has left. Nobody knows where the code is or how to log in to the server." The system still runs, but nobody dares touch it, and one small incident would bring the whole company to a halt.
The good news: most of these systems can be rescued. The less good news: the sooner the handover happens, the cheaper it is.
Get access back first
This is the urgent part, and it's much easier while the previous developer can still be reached. The minimum list:
- Domain name: the registrar account should be in the company's name, not the developer's personal account.
- Hosting, VPS, cloud: the admin account, plus a way to log in to the server (SSH or the hosting panel).
- Source code: the repository on GitHub, GitLab or Bitbucket. The company should own it, not just be invited as a member.
- Database: the address, an admin account, and the latest backup.
- Outside services: outgoing email, payment gateway, SMS, maps, AI APIs. Each has an account and a key.
- Cloudflare or DNS: who manages the domain's records.
Once you have it all, change the passwords and create new keys, especially if the departure wasn't a friendly one.
The minimum documentation
It doesn't have to be long. One file that answers a few questions is enough for someone new to start:
- What parts the system has, and where each one runs.
- How to deploy a new version, step by step.
- When backups run, where they are kept, and how to restore them.
- Recurring chores: renewing SSL and the domain, clearing logs, updating libraries.
- The "special" bits only the previous developer knew: a custom setting for one big client, a cron job that runs at midnight.
If the previous developer can't be reached, all of this has to be worked out backwards from the code and the server. It takes longer, but it can be done.
How to tell the handover is complete
The simplest test: ask someone else to deploy a small change and restore a backup into a test environment, using only the documentation. If they manage without asking anyone, the handover is complete. If they have to call the previous developer, it isn't.
Don't rush into a rewrite
When nobody understands the code, someone will soon suggest "tear it down and rebuild it". The old system may be hard to read, but it works, and it holds a lot of business rules that were never written down. It's usually better to stabilise it and document it first, then decide which parts really need replacing.
If you're in exactly this situation, a Health Check is the quick way to learn what the system contains, where the risks are and what to do first. I can also help take back and rotate access safely.
Sound like your system?
A 2–4 day Health Check tells you what to fix first and what can wait.
