The developer behind your business system won’t pick up the phone. How do you take over the software?

To hand a business system over to another developer, you need four things in hand: the source code exactly as it actually runs, access to everything the system depends on, the complete data, and a description of how the system is run and what it is connected to. A backup alone is enough only when the system does little, nobody is building on it and it is not reachable from the internet.

The answer depends mainly on how heavily the business relies on the system and whether it can be reached from the internet. It also matters whether the accounts for the domain, the server and the connected services belong to the company or to the developer. And finally, the contract: who may modify the code is determined by what you once agreed with the developer.

A PHP security hole shows why a system without a maintainer can’t be left alone

The PHP project recently issued an official advisory about critical vulnerabilities that allow remote code execution. It urges users to update immediately. Any company website or system running on an outdated version of PHP that nobody looks after regularly may be at risk.

Remote code execution means an attacker can do practically anything on your server: read your customer database, delete data or send email in your name.

Updating, however, is not a single click. Older applications often don’t work on a newer PHP version without changes. Someone has to carry out the update, test it and fix whatever breaks.

If there is no such person, you have a problem. And it isn’t just about this vulnerability. The next one will come, whether in PHP, in the database or in the libraries the system uses. A system without a maintainer is not a finished product. It is an open risk.

Make an emergency backup before you touch anything

Before anyone starts updating or fixing things, you need a copy of everything that works today. If the intervention goes wrong, it is your only way back.

The emergency backup should include:

• the entire database as a dump from which the database can be recreated;
• uploaded files – documents, attachments, images, issued invoices;
• the source code exactly as it sits on the server, including third-party libraries;
• configuration files with the connection settings for the database, email and other services;
• a list of scheduled jobs that run on the server automatically (sending emails, overnight recalculations, downloading exchange rates);
• a note of which versions of PHP, the database and the operating system the system runs on.

Store the backup off the server, ideally in two places. It contains passwords and personal data, so keep it somewhere not everyone can get to.

A backup that nobody has tried to restore is just hope. Have a developer bring the system up from it on a test machine. Only then do you know you have everything.

If you have no access to the server at all, contact the hosting provider. They will deal with whoever the account is registered to. So prepare documents showing that the service was paid for and used by the company.

List all access credentials and transfer them to the company

The typical trap isn’t missing code. It’s an account registered to the developer’s personal email or paid with their card. Once they stop paying, the domain expires or the server disappears along with the data.

For each item, note who has access and whose name the account is in:

After the transfer, change all passwords. Store the new ones in a company password manager, not in one person’s head.

Try contacting the developer in writing, even if they haven’t responded so far. A short message with a specific list of what you need stands a better chance than a vague “please get in touch”. Sometimes it’s enough that the request is clear and won’t take much of their time.

Treat the code actually running on the server as the source of truth

The code the developer once handed you on a drive or in a repository may not match what is on the server. Changes were often made directly on the server and never made it anywhere else.

With PHP, this is an advantage. The code on the server is usually readable and a developer can work with it. The exception is code encrypted with a copy-protection tool. It is practically impossible to modify without the original developer, and such a system can only be kept running as is or replaced.

The second question is legal. Having the code in hand does not mean you may change it or pass it to another supplier. That depends on the contract and licence, or on whether the developer was an employee. If there is no contract or it is unclear, consult a lawyer before handing the system over.

Beyond the code, look for any documentation at all. Old emails, installation notes or the original specification will do. They help the new maintainer understand why something was built the way it was.

Backing up and leaving it alone is only enough for a small system off the internet

Not every abandoned system needs to be taken over. Sometimes it makes sense to freeze it: back it up regularly, restrict access and do nothing else.

That makes sense when everything on this list applies:

• the system does little and the business can manage without it for a few days;
• nobody is building anything new on it and it won’t change;
• it isn’t reachable from the internet, or only from the company network or over a secure connection;
• it doesn’t handle payments or sensitive customer data;
• you can get the data out of it if you ever shut it down.

A backup alone is not enough when:

• the system is reachable from the internet and runs on a PHP version that no longer receives security fixes;
• it takes orders, payments or customer data;
• you need to change anything in it, for example because of new accounting software or legislation;
• daily operations depend on it and an outage would bring work to a halt.

Freezing isn’t forever. Write down when you will revisit the decision, for example at the next serious security flaw or a change in operations.

Decide between maintenance and replacement only after a review, using four questions

Have the system reviewed by a developer who could maintain it. The output should be a short written summary: what the system does, what state it’s in, what the risks are and what they recommend. Anyone who promises to take over anything without a review doesn’t know what they’re getting into.

Then ask yourself four questions:

1. Is the code understandable? If a new maintainer can find their way around it, maintenance is usually feasible. If not, every fix will be expensive and risky.
2. How far is it from a supported PHP version? A small jump can be handled with modifications. A system built on a version many years old is often better rebuilt.
3. How much will you want to change? If the system just needs to keep running, maintenance is enough. If you want to extend it, you pay a legacy code tax on every change.
4. Does the system do something that standard off-the-shelf software can do? If the process is standard, a ready-made product may be a more sensible choice than a custom system.

Replacement doesn’t have to happen all at once. A new system can be built piece by piece alongside the old one, with data migrated gradually and the old one switched off part by part. That way the business never stops, not even for a day.

Even with a replacement, the same rule applies: back up and secure the old system first. It has to hold out until the new one is up and running.

Use the handover to make sure this doesn’t happen again

A takeover is an opportunity to fix what led to the problem. Whoever maintains the system, the company should always have in hand:

• all accounts registered to a company email address and paid for by the company;
• a code repository under a company account, where the maintainer commits every change;
• a brief description of how the system runs, how it is backed up and how it is restored;
• a contract that clearly states who may use and modify the code;
• an agreement on who monitors security advisories and how quickly they respond.

A second person who knows the system at least roughly is cheap insurance. They don’t need to be able to fix it. It’s enough that they know where everything is.

Once a year, check that access still works and the backup can be restored. It’s a quick job, and it pays off on the day someone once again doesn’t pick up the phone.

Sources

• Kritická díra v PHP (php2shell) – aktualizujte

Frequently asked questions

May another developer modify code written by someone else?

It depends on the contract and licence the company agreed with the developer, and on whether they were an employee or an external contractor. Simply having the code does not give you the right to modify it. If you don’t have a contract or it is unclear, have a lawyer assess the situation.

What if the server and domain run on the developer’s account?

Then transferring them to the company is the most urgent task, because only the developer has control over everything. Providers usually deal only with the account holder, so invoices and payment records showing that the company paid for the service will help. The provider’s support team will tell you the exact transfer procedure.

Is it enough to ask the hosting provider to upgrade the PHP version?

It may close the security hole, but an older application may not work on the newer version. You could end up with a system that is secure but broken. The more sensible approach is to make a backup and test the new version on a copy first.

How can I tell whether the new maintainer knows what they’re doing?

After the review, they will give you a written summary you can understand without a technical background: what the system does, what the risks are and what options you have. They will also tell you when a takeover isn’t worth it. Be wary of anyone who promises to take over the system before they’ve seen it.

What should I do if the developer eventually gets in touch?

Use it for a proper handover. Ask them to transfer the accounts to the company and to provide the current code, a description of how the system runs and, if needed, a paid hour explaining things to the new maintainer. Even if you resume working together, the accounts and code should remain the company’s property.