It happens more often than you’d think. The system works, the business runs on it, and the one person who understands it is gone. New job, burnout, a falling-out, sometimes just silence.
The good news: the system didn’t get worse overnight. It runs today exactly like it ran last week. What you’ve lost isn’t the software. It’s the knowledge and the keys. Both can be recovered, in that order. I’ve inherited systems in this state, so this is the checklist I’d give a friend.
First, secure the keys
Before anything technical, make a list of every account the system depends on, and make sure you control each one. The usual list:
- The domain name and the DNS settings.
- The hosting or the server itself.
- The database.
- The code. If it lives in GitHub, GitLab or similar, get owner access.
- Third-party services: payment provider, email sender, SMS provider, backups.
If the developer left on good terms, this is one polite email. If not, do it through the providers. Either way, do it now, not when something breaks. A system you can’t log into isn’t yours, whatever the invoice said.
Second, get a backup you’ve actually tested
Ask where the backups are, or make one today: the database and the code, copied somewhere the old server can’t touch.
Then test it. Restore the backup somewhere and check the data is really in it. An untested backup is a hope, not a backup. This one step turns most disasters into inconveniences.
Third, freeze big changes
For the next little while, the goal is stability, not progress. Keep the lights on. Renew the domain and the server. Don’t let anyone “quickly rewrite” anything yet.
Rewrites proposed in week one are almost always wrong, because nobody understands the old system yet. Which brings me to the real work.
Fourth, map it before touching it
Whoever takes over should spend their first days reading, not writing. What talks to what. Where the data lives. What runs on a schedule. What breaks if it stops. When I take on an existing system, I write this map down before I change a line, the same way I map every state of a feature before I build one. Surprises should happen on paper, not in production.
You’ll know it’s going well if the new person asks lots of questions and changes almost nothing at first. Be worried if it’s the other way around.
Fifth, make every change small and reversible
Once changes start, they should ship as small, numbered releases with a changelog you can read, so any change can be traced and rolled back. That discipline matters double on an inherited system, where the edge cases are still being discovered.
The lasting fix is an owner, not a fixer
Here’s the uncomfortable part. If you only replace the person, you’ll be back in this spot in a few years. The deeper problem is that the system’s history lived in one head.
So whoever comes next, ask them to leave a paper trail: decisions written down, changelogs, documentation that survives them. That’s what I mean by ownership: not just someone who can fix the system, but someone who makes sure it’s never again a mystery only one person can read. Developers leave for perfectly normal reasons. The system should be able to survive it.
The checklist, short version
- Control every account: domain, server, database, code, third parties.
- Make a backup and restore it once to prove it works.
- Freeze big changes; keep the lights on.
- Map the system before changing it.
- Small, reversible releases with changelogs.
- Insist on written history, so this never depends on one head again.
None of this needs to be rushed, and none of it needs panic. A working system buys you time. Use the time to make sure you actually own it.