It usually happens quietly. The developer who built your system announces they’re leaving, the last week flies by, and then they’re gone. A week later someone asks for a small change, and it turns out nobody in the company knows where the code lives, what passwords are current, or even what the server is running on.
Panic is the natural reaction, but it’s also the most expensive one. Here’s a calm, methodical plan for handling this situation without making it worse.
Rule one: don’t let anyone “just rewrite it” right away
The most common mistake is calling in a new developer who looks at the nonexistent documentation, sighs, and suggests: “It’d be easier to build this from scratch.” That’s often true from their point of view, because understanding an existing system is slower for them than writing a new one. For you, it means months of work during which the old system still has to keep running, and a bill that dwarfs the actual problem several times over.
Before anyone writes a single new line of code, you need to understand what’s actually wrong with the existing system. Often the problem isn’t the code itself, it’s that nobody knows how to operate it.
What to find out first
Before any technical decision, you need to know where the system lives, who has access to it, where the code comes from, and what’s already documented. Go through this systematically, not from memory.
- Domain and DNS. Where is the domain registered, and under whose account? Who controls the DNS records?
- Hosting and servers. Where does the system physically run (AWS, a local host, the developer’s own server)? Who owns the account and who pays the bill?
- Source code. Is there version control (GitHub, GitLab or similar)? Is the last working version actually there, or is there code on the server that never made it into the repo?
- Database and backups. Where does the data live, and are there restorable backups?
- Third-party services. Payment provider, email sender, maps, analytics, API keys. Each of these is a separate account you need access to.
- Documentation (if any exists). Even a couple of pages of notes or a README beats nothing.
If some of this is unreachable because the developer isn’t responding, that’s a security issue, not just an inconvenience: someone outside the company still has access to your systems. That gets handled first, before any technical analysis.
A technical audit, without the panic
Once access is in hand, or at least mapped out, it’s time to have someone independent look the system over. A good audit doesn’t say “this is all a mess”, it gives you a concrete picture: what technology the system runs on, how old it is, where the biggest risks are (security holes, outdated dependencies, missing backups), and what’s actually working just fine.
The point of an audit like this isn’t to find someone to blame, it’s to give you facts to decide on instead of fear. Sometimes it turns out the system is technically sound and the only real problem was that nobody knew how to manage it. Sometimes the foundation genuinely is weak and needs planned modernization. Either answer beats not knowing.
Stabilize before you decide anything big
Before any major architecture decisions, it’s worth getting the system to a stable state: access under control, backups in place and tested, critical security fixes installed, someone watching whether the system is actually up. From that point on you’re no longer fighting fires, and you can calmly decide whether the system needs gradual modernization, a rebuild, or is actually good enough for your business as it stands.
- Is anything currently broken or leaking data? If so, that goes first.
- Are backups being made and can they be restored? If not, that’s next.
- Does anyone get notified if the system goes down? If not, add monitoring.
- Is access now limited to people you actually trust? Double-check it.
If your business is in exactly this situation, the first step isn’t hiring a new developer, it’s a clear picture of what you actually have. I do technical audits and code reviews as part of IT consulting. If you then need someone to keep an eye on IT and talk to developers on your behalf, see the part-time IT lead service.
Write to me with a short summary of what happened and what the system is, and we’ll figure out the fastest way to reach a stable state.