What to do when the person who built your software has gone — and no one dares touch it
There’s a particular kind of quiet dread that settles over a business when it realises no one understands its own software any more.
Maybe the developer who built it moved on years ago. Maybe it was an agency that has since folded, or a long-serving member of staff who retired — in one case, I was called into, someone who had sadly died. However it happened, the result is the same: the system that runs your business is still running it, but it has become a black box. It works, mostly. But nobody dares change anything, because nobody is quite sure what will happen if they do.
If that’s your business, you are not careless, and you are not alone. It’s one of the most common situations I’m called in to deal with.
Why it happens to good businesses
It’s rarely the result of bad decisions. It’s the natural by-product of a business that’s been busy getting on with the actual job. A piece of software gets built to solve a real problem, it does the job well, and so it quietly becomes load-bearing. The people who understood it move on. The documentation never quite kept pace with reality. And one day you look up, and the knowledge has left the building.
Success, not neglect, is usually how a system ends up orphaned.
It feels worse than it is
From the inside, this feels like a slow-motion emergency — one failed server or one botched change away from a very bad week. From the outside, with a few decades of having seen it before, it’s almost always more recoverable than it feels.
The business logic you’re afraid of losing is still there, running every day. The task isn’t to perform magic; it’s to patiently get that knowledge back out of the machine and into the open, and to make the fragile parts safe while we do it.
What not to do first
The instinct, understandably, is to want it gone — to rebuild the whole thing from scratch: clean, modern, understood. Resist that instinct, at least until you’ve done the groundwork.
An orphaned system is precisely the worst candidate for a from-scratch rebuild, because all those years of forgotten business rules and hard-won edge-cases are exactly what you’d be throwing away — only to rediscover them, one painful incident at a time, while the business waits. A panicked rebuild is how a manageable problem becomes an expensive one. (Sometimes a full rebuild genuinely is the right answer — but that’s a conclusion to reach with evidence, not in a panic.)
A calmer way through
There’s a well-trodden path through this, and it isn’t dramatic. Roughly, it goes like this:
- Make it safe. Before anything else, reduce the immediate risk — proper backups, a safe place to test changes, and a clear-eyed list of what would actually hurt the business if it failed. This step alone takes most of the fear out of the situation.
- Get the knowledge back. Patiently work out what the system really does, and why — not only from the code, but from the people who use it every day. Much of the “lost” knowledge is still in their heads; it just needs capturing before they also move on.
- Decide from knowledge, not panic. Only now, with a real picture, is it sensible to weigh the options: stabilise and keep, evolve gradually, or — occasionally, when it’s genuinely right — rebuild. Whatever you choose is sound, because it’s informed.
- Move forward in steps. Modernise deliberately, a piece at a time, retiring the risky parts safely and adding what the business actually needs. No big bang, no betting the company on it.
The part that isn’t about code
There’s a side to this that has little to do with software. An orphaned system usually has anxious people around it — the staff who have quietly built workarounds to keep it limping along, the owner who lies awake about it. Part of the job, and the part I happen to care most about, is steadying those people: making the situation feel understood and manageable again.
An earlier career in healthcare taught me that the human side of a frightening problem matters at least as much as the technical one. Get that right, and the technology tends to become the straightforward part.
Where to start
If any of this sounds like your business, the first step isn’t a big, frightening project. It’s simply getting a clear, honest picture of where you stand — what’s fragile, what’s recoverable, and what it would actually take to put things right.
That’s exactly what a short Discovery & Roadmap is for: a fixed-price look under the bonnet and a plan you can act on with confidence. No drama, and no obligation to go any further.
The dread of an orphaned system comes almost entirely from not knowing. Replace the not-knowing with a plan, and it stops being a crisis and becomes a project — a manageable one.
