What happens to your software when your developer retires?

Building on IT · 8 October 2026 · 6 min read

A common arrangement, and a fragile one

The pattern is familiar. Twenty years ago a local developer, or a two-person software house, built a system for your business. It has been quietly extended ever since: a change here, a report there, a fix when something broke. The relationship has been good, the invoices small, and nobody has had to think about it. That is precisely the problem. The arrangement works until the day it doesn't, and that day tends to arrive with little warning.

The exposure is not that the software will suddenly stop. It is that the next time something needs changing, there will be nobody to ask. And something always needs changing: a new tax rule, a new customer requirement, a Windows update that breaks a component, a certificate that expires.

If your developer is still around: act now

This is by far the better position to be in, and the steps are not onerous. Most good developers will welcome them.

1. Get the source code, and confirm you own it. Check your original agreement. If ownership is unclear, agree it now, in writing. Ask for the current code, not the version from the last big release.
2. Get everything else that makes it run. Database scripts, configuration files, third-party components and their licence keys, hosting and domain logins, the deployment steps. Ask for a written description of how a change gets from the developer's PC to your live system.
3. Ask for a handover document. It need not be long. What the system is built with, how it is structured, where the awkward parts are, what is on the to-do list. Two or three pages from the person who knows it is worth more than any amount of reverse engineering later.
4. Introduce a second pair of hands. Have another developer spend a day or two with the current one, looking through the system together. The cost is modest and it converts a single point of failure into a known quantity.
5. Put it all somewhere safe. A source-code repository you control, with a copy of the handover document in it, and a note in your business continuity plan of where it is.

If your developer has already gone

The situation is more awkward but rarely as bad as it feels. The first job is an honest inventory, and it is best done by someone who has seen this before.

• The database. In almost every case this is recoverable and workable, whatever else has been lost. It is also where most of the value lies: the structure reflects years of how your business actually operates.
• The application. Source code may be on the old developer's machine, in an old email, in a repository someone has the login for, or genuinely gone. If it exists it can usually be picked up; if not, compiled applications can often be understood well enough to keep running and to plan a replacement around.
• The hosting. Who is paying for the server, the domain, the SSL certificate? Are the logins known? Expiring hosting is the most common way an orphaned system actually goes down, and it is the easiest thing to fix.
• The dependencies. Third-party components, reporting tools, old versions of Windows or SQL Server. Some will be unsupported; the question is which of those are actually risks and which merely look like it.

From that inventory comes a short written note: what you have, what is at immediate risk, what to do first and roughly what it will cost. For most systems the first steps are small: secure the hosting, take a reliable backup, document what exists, fix the one or two things people have been working around. Everything else can follow at the business's pace.

What not to do

Resist the instinct to treat the loss of a developer as the trigger for a full replacement. A system that still does the job is an asset; the risk is around it, not in it. A replacement project started in a panic is expensive, slow, and tends to lose the details that made the original fit the work. Stabilise first, then decide what, if anything, to replace, and do that in stages while the original keeps running.

The one thing to do today

Whichever position you are in, find out where the source code is and who owns it. If you cannot answer that question within ten minutes, it is the first thing to fix.

← More articles