Our developer left and nobody knows our system

It usually starts with something small. An invoice email stops going out, a report shows the wrong numbers, or the hosting company sends a warning nobody understands. You go to ask the person who built the system and remember they left in the spring. Nobody else has ever looked inside it.

This happens to a lot of businesses, and it’s fixable. The system hasn’t got any worse since they left. What you’ve lost is the one person who knew how to look after it, so the job now is to get that knowledge back before something breaks.

First, make sure you still have the keys

Before anything else, check that the business, and not a former employee, controls everything the system depends on. Make a list and confirm you can log in to each of these yourself:

• the hosting account or servers the system runs on
• the domain name and its DNS settings
• the code itself, usually in GitHub, GitLab or Bitbucket
• the database, and wherever the backups are kept
• any paid services it uses, such as email sending, payments or maps

If any of these are in the former developer’s personal name or on their personal card, move them to a company account now, while they’re still reachable and willing to help. This is the step most often skipped, and the one that hurts most when a domain or hosting plan quietly expires.

Check the backups actually work

Most systems have backups. Fewer have backups anyone has ever restored. Ask whoever you bring in to restore the latest backup to a separate copy and confirm the system starts. If it doesn’t, you’ve found your most urgent job.

Don’t change anything big yet

When nobody understands a system, the temptation is to replace it. Hold off for now. A system that has run your business for years contains a lot of decisions nobody wrote down: discounts for particular customers, a workaround for a supplier, a rule added after a mistake. A rushed rewrite tends to lose those, and you find out when a customer complains.

For now the aim is to keep it running, then decide calmly whether to keep it, upgrade it or replace it.

Finding someone to take it over

Many developers prefer building new things to looking after someone else’s older work, so finding help can take a while. When you talk to people, ask:

1. Have you taken over a system you didn’t build before? What did you do in the first month?
2. How will you learn how ours works without breaking it?
3. What will we get in writing at the end, so we’re never in this position again?

A good answer starts with reading and documenting before changing anything. Be cautious of anyone who wants to rewrite it before they’ve seen the code.

Make sure it doesn’t happen again

Whoever takes over, the useful outcome is a short written record: what the system does, where it runs, how to deploy a change and how to restore it. With that in place, the next handover takes days instead of months. Why this kind of risk builds up quietly is worth reading too.

If your developer has left and you're not sure where to start, reach out to us. We'll find out how your system works, write it down, keep it running, and tell you plainly whether it needs more than that.