The developer who built your system is gone

The danger is not where you are looking for it

The first thought is usually the source code: we don't have the code, so we have nothing. In practice the code is rarely what brings a company down. Businesses do not fail because they cannot add a button. They fail because one morning they lose access.

The domain lapses because it was registered to a former contractor's private address and the renewal notice went to them. Hosting stops because the card it was paid from expired. The only person who knows the administrator password is off sick. In all of these the system still technically exists, and you do not have it.

So the order is not: let us find a developer. The order is: let us first take back control of what we already have. And before anything else, find out whether the backup has ever been restored.

The inventory to do this week

This needs no developer and you can do it yourself. The goal is a single sheet of paper that answers each of these:

• Where does the system physically run? A server in your office, a rented machine, somebody's account at a hosting company?
• Who pays for the domain, hosting, certificates and licences, and from whose card? In whose name and e-mail are they registered?
• Does the source code exist and where? Is it really the version currently running?
• Which database, which version, and where does the data live?
• Who holds administrator access, and where is it written down?
• Is there a backup, where does it go, and does anyone check that it ran?
• What connects to the system: the bank, tax filing, a web shop, scales, barcode scanners?

Take ownership back before you call a developer

This is the cheapest and most urgent part of the work, and none of it requires anyone to understand the code:

1. Move the domain and hosting onto accounts in the company's name, with a company e-mail and the company card. Turn automatic renewal on.
2. Get the passwords out of individual heads and off scraps of paper, into a password manager the company owns.
3. Keep your own copy of the source code and the data, independent of any outside contractor.
4. Check who formally owns the code under the contract. If there is no contract, settle that before it matters.

After those four steps your position is materially different, even though not a line of code has changed. You no longer depend on the goodwill of somebody who does not reply.

A backup you have never restored is not a backup

Almost every firm says it has backups. Very few have ever tried to restore one. Those are two entirely different things, and the difference surfaces at the worst possible moment.

• A copy on the same server or the same disk is not a backup. A disk failure or ransomware takes the original and the copy together.
• A copy of the database is not enough. You also need the files, the configuration, and the knowledge of how the system is started at all.
• A backup nobody checks quietly stops working, and that is usually discovered months later.

The only honest test is to restore it onto a separate environment and measure how long that took. That number is your real recovery time. If you do not know it, your recovery plan is a hope.

What if the source code really is gone

Before concluding it is gone, look properly. Code often turns up in old correspondence, on a USB stick, or on the server itself. For systems written in languages that are not compiled, such as PHP or Python, what runs on the server is the source.

If it is a compiled application and the code is genuinely missing, the position is harder but not hopeless. The important thing is to be clear about what is actually valuable here: in the large majority of cases it is your data, not the code. Data can be taken out of the database whether or not anyone can change the program.

The realistic path then is not to rewrite everything, but to wrap it gradually. The old system keeps doing what it does, the new one is built beside it and takes over piece by piece. A full rewrite is the most expensive and riskiest option, and honestly it is chosen out of anger more often than for technical reasons.

What an orderly takeover looks like

When somebody takes over a system they do not know, the first month should deliver no new features at all. It should deliver control:

1. Observation. The system goes under version control even if it never was, and nothing changes until its behaviour is understood.
2. Standing it up in a test environment. If it cannot be built from scratch on another machine, nobody actually controls it.
3. A minimal runbook: how it starts, how it is restored, how a change is released. Three pages is enough.
4. The first change must be small and easy to undo. Its purpose is not benefit but proof that the whole chain works.

STARTING
  where it runs, how it starts, what it depends on

RECOVERY
  where the backup is pulled from
  restore steps, measured duration
  when it was last tested successfully

CHANGES
  how a new version is released
  how the previous one is put back

ACCESS
  who holds which account, where passwords live

The test of whether the takeover worked is simple: can you stand the whole system up on a new machine, from the backup and the code, without the person who built it. While the answer is no, the takeover is still in progress.

Replacing is not always the answer

After a bad experience there is a strong urge to throw it all out and build again. Sometimes that is right. More often it is not.

Keep and maintain it if the system does its job, the business logic in it is correct, and the only thing that changed is the people around it. That system carries years of corrected mistakes and exceptions nobody remembers any more, and every one of them will reappear in a new system, one at a time.

Replace it if the platform no longer receives security patches, if the data model actively stops you doing what the business needs, or if literally nobody can start it. Even then, the replacement runs alongside the old system rather than cutting over in a single night.