What to do when the company that built your software disappears

One day you ask for a small change in your application and nobody replies. The email bounces, the phone number does not exist, or the person who handled it no longer works there. The software still runs, but suddenly there is nobody to touch it. It is a more common situation than it seems: the company that built it closed down, changed direction, or simply stopped treating you as a priority client.

The instinctive reaction —"we have to rebuild the whole thing"— is almost never the right first decision. Before that there are steps that reduce the risk without spending the budget of a new project. This is what to do, and in what order.

Step 1: audit what you actually have

You cannot decide anything until you know what is there. And "what is there" is not just the code: it is everything needed to keep that code alive.

• The source code. Do you have it, in a repository you can access, or does it live only on the server where it runs? Is it complete, or is the configuration, the deployment scripts or the database migrations missing?
• The dependencies. Every application relies on third-party libraries and frameworks. It is worth taking an inventory of which ones it uses and in what version, because old versions stop receiving security patches and block any later update.
• The infrastructure. Where it is hosted, which external services it uses (payment gateways, email sending, third-party APIs), which certificates expire and when.
• The knowledge. Is there documentation of the architecture and the deployment, or was it all in the head of the person who programmed it? Almost always the latter.

The output of this phase is a report: the real state of the project and risks ordered by severity. Without that map, any later decision is a gamble.

Step 2: recover control of the code and the accounts

This step is as important as the previous one and is often forgotten. If the supplier disappeared, some of the keys to your own software are probably in their name:

• The domain and its DNS.
• The hosting or cloud account where the application runs.
• The code repository.
• The accounts for external services (transactional email, analytics, payment gateway).
• The certificates and the database access credentials.

Make a list of all those assets and of whose name they are in. Anything under an account you do not control is a single point of failure: the day that account expires or is cancelled, your software goes down and there is nothing you can do. Recovering ownership —transferring the domain, migrating hosting to an account of your own, inviting a new administrator to the repository— is a priority and can often be done even if the supplier does not cooperate, following each platform's procedures.

Step 3: stabilise before evolving

With the map done and the accounts recovered, the temptation is to ask straight away for the improvements you have wanted for months. It is too early. First you have to stabilise: deal with the urgent so the project stops being fragile.

Stabilising means, in practice:

• Updating the dependencies with known vulnerabilities, starting with those exposed to the internet.
• Plugging the obvious breaking points: processes with no error handling, scheduled tasks that fail silently, backups that did not exist or were not being verified.
• Documenting the deployment, so publishing a change stops being a risky operation only one person knew how to do.
• Adding some safety net —automated tests on the critical logic— so the code can be touched without crossing your fingers.

Only when the project is stable does it make sense to talk about new features again. Evolving on an unstable base multiplies the cost of every change.

Step 4: decide whether a rewrite is worth it

Sometimes the audit concludes that the code is in such a bad state that maintaining it costs more than rebuilding it. That is a legitimate decision, but it is worth making with data, not out of frustration. Signs a rewrite may be worth it:

• The base technology is discontinued and there is no realistic upgrade path.
• Every small change systematically breaks three things somewhere else.
• The cost of stabilising and maintaining, projected over two or three years, approaches that of a new build.

And signs it is not worth it yet:

• The software covers the business process well and the problem is only maintenance.
• Much of the logic is correct and reusable, even if the wrapper is dated.
• There is no time or budget to stop the operation while it is rebuilt.

When a rewrite is the option, it is almost always done in phases, reusing what works and replacing module by module, not switching off the old system overnight.

The order matters

Audit, recover accounts, stabilise and, only then, decide whether to evolve or rewrite. Skipping steps —especially starting with "let's rebuild it"— is what turns a contained problem into an expensive project.

If you are in this situation and want a concrete assessment of your case, this is exactly what the software rescue service covers: project audit, recovery of control, stabilisation and, from there, evolution and maintenance with a technical lead who stays.

---

Related reading

• Software maintenance: what it includes and how often you need it — What ongoing maintenance actually involves, which is where an already-stabilised project should end up.
• How much custom software costs — Useful price references if the audit concludes that rebuilding in phases is worth it.