The vendor has disappeared and the system is still running: how to take it over

Short answer: if the vendor has stopped answering, check the access first: server, domain, code repository, the accounts for the payment service, the mail sender and the bot. While the system is running you have time, and any single event can take it away: a domain left unrenewed, an expired certificate, a server that falls over. Then take a full backup and write down what exists. A new developer will need a few weeks to find their way around somebody else’s code, and those weeks are better started before anything urgent comes up.

Step one: access

Make a list of everything the system stands on, and for each item check who owns it and whether you can get in.

• The domain. Whose name it is registered in and when it expires. This is the most common way to lose a working system.
• The server or cloud account. Whose account it is, who pays for it, whether you hold a password or a key.
• The code. Where the repository is and whether you have access to it.
• The services. Payment provider, email delivery, SMS, the bot account, the developer account in app stores.

Anything registered to your company can be recovered through the provider’s support with documents. Anything held in the vendor’s name, or in their personal account, is hard to retrieve without them.

Step two: the backup

If you still have server access, take a full copy of the database and the files, or better a snapshot of the whole server, and keep it yourself. If the code is not in a repository, the server copy may be the only place it exists.

Check when automated backups last ran and where they are stored. It often turns out they were being written to the same server, or were not running at all.

Step three: try to come to terms

A vendor who has stopped answering has not necessarily vanished. A studio may have closed, a developer may have changed jobs. An email with a specific list of what you need handed over, and an offer to pay for that work, tends to do better than demands.

If there is a contract, read what it says about handing over the code and the rights to it. What should have been in it is covered in what to put in a development contract.

Step four: the new vendor

A new developer starts with an audit: deploying the system on a test server from the code and the backup, checking whether the code matches what is actually running, and describing how it all works. For a mid-sized system that is a few weeks.

Do not ask for changes straight away. A change inside code nobody understands breaks the parts that worked. Let the first tasks be backups, monitoring and security updates.

Expect the new vendor to propose rewriting something. Sometimes that is right, but it is a decision for after the audit. At a first meeting there is far too little to go on.

If there is no code at all

If there is neither a repository nor server access, what remains is the running system as seen from outside. It can be described screen by screen and data by data, and built again. The data is exported through the interface or the reports while those are still available. How that move works is covered in migrating data from an old system.

Common questions

What does handing a system to a new vendor cost? The audit and the redeployment usually come to about what a month of support for that system costs. After that it is supported as normal; the proportions are in what support after launch costs.

Can a domain registered to the developer be recovered? Through the registrar, without the owner’s consent, almost never. If it is registered to a private individual, the options are to negotiate or to register a new one.

How do we avoid ending up here again? Register the domain, the server and the accounts to the company, keep the code in your own repository, and once a quarter check that a backup actually restores.

The rule

While the system is still running, check the domain, the server and the code, and keep a copy yourself. Everything else can be done calmly; without that, any failure turns into an emergency.