"Our software developer retired." A practical survival plan
When the developer who built your system retires, the system does not stop working. It stops being safe to change. The survival plan has four steps: secure access and licences, test a restore before you trust your backups, write down what the system actually does, then choose an exit on your timetable rather than the clock's. Panic-buying a replacement in week one is the most expensive mistake available.
The phone call usually comes after the leaving do. The developer who built the system that runs your business has retired, and somebody has just asked a question nobody else can answer. Nothing is broken. Everything is suddenly fragile.
This note is the plan I wish every business in that position had pinned to the wall. It costs almost nothing to follow and it converts a slow-motion emergency into a managed project.
Week one: secure what you have
Before anything else, gather the keys. None of this needs a developer.
- Passwords and accounts. Administrator logins for the system, the database, the server it runs on, and any hosting or remote-access accounts in the developer’s name.
- Source code. Find out where it lives: a folder on the server, a zip in an email, a repository somewhere. Copy it somewhere safe. If you cannot find it, write that down too; it changes your options and you need to know early.
- Licences and installers. The original installation media, licence keys and any dongles. Dead platforms cannot be re-bought; the installer you have may be the only one left.
- The machine itself. If the system runs on one ageing PC in the corner, take a full disk image of it now. That machine is currently your single point of failure.
If the developer is still reachable, one paid handover day is worth more than any document. Ask for it warmly and soon.
Week two: test a restore, not a backup
Businesses in this position almost always believe they have backups. Far fewer have ever restored one.
A backup you have never restored is a hope, not a backup. Pick a spare machine, restore last night’s backup onto it, and try to open the system. If that works, do it again with a backup from last month. Write down how long it took and what was missing.
This is the single highest-value hour on this list. If the restore fails, you have just learned the most important fact about your business, while there is still time to fix it.
Weeks three and four: write down what it actually does
Not the manual. What it actually does. Sit with the people who use it daily and capture:
- What goes in: orders, deliveries, timesheets, whatever feeds it.
- What comes out: invoices, reports, labels, the month-end run.
- Which screens each person actually uses, and in what order.
- The folklore: the field that must never be left blank, the report that only works on Tuesdays, the sequence everyone knows but nobody wrote down.
Two or three pages of honest notes will do. This document makes every future conversation cheaper, whoever you end up working with.
Do not panic-buy a replacement
The most expensive mistake available in month one is signing for an off-the-shelf package because it feels decisive. Decades of your business rules live in the old system. A package fits the average business; yours has just proven it is not average, because it has run on bespoke software for twenty years.
Buy time instead. Time comes from the steps above, and from knowing how much of it you have.
How much time do you have?
| Signal | What it means | Urgency |
|---|---|---|
| Developer still reachable | Handover and questions are possible | Use it now, kindly |
| Restore test passed | Disaster is recoverable | Calm: plan in months |
| Source code in hand | Every exit option stays open | Calm: plan in months |
| Data exportable to anything | The records can outlive the platform | Calm: plan in months |
| Developer unreachable, no source | Behaviour must be rebuilt from the running system | Elevated: start the audit |
| One machine, no tested restore | A power cut could end the system | Emergency: image it this week |
Score yourself honestly. Most businesses land in the middle: safe today, narrowing options every year.
Choosing the exit
Once the system is secured, documented and restorable, you can choose an exit like a buyer instead of a hostage. The realistic options are to stay and contain the risk, refactor within the old platform, replace with a package, or rewrite as a modern web application. The right answer depends on the system, which is why we compare all four honestly for each platform we rescue; see the Legacy Rescue practice for how that comparison works, or go straight to the facts for DataFlex, Visual FoxPro or Clipper and dBase.
Whichever way you go, insist on a parallel run: the old system stays live until the new one has proven itself, record for record. Downtime is a choice, and the correct choice is no.
If you want the first step done for you, the free Legacy Risk Audit is a 30 minute call plus a written one-page risk summary. You will know where you stand, whatever you decide to do next.