Our software vendor has gone into administration. Will our system stop working?

Not by itself. Installed software keeps running regardless of what happens to the company behind it; the immediate risk is losing the ability to reinstall, fix or move it. If the vendor hosts the system for you, act faster: hosted servers can be switched off when the bills stop being paid, so export your data first.

Can we get the source code when a vendor goes bust?

Only if your contract gives you a route to it, usually a source-code escrow clause naming an agent and listing insolvency as a release event. Check the contract before phoning anyone. Without escrow, the code is an asset of the insolvent company and may be sold with the rest.

Who owns our data if the vendor no longer exists?

The data about your business is, in practice and usually in contract, yours. Ownership is rarely the problem; access is. Copy the database, find its passwords and test that a restore works while the people who can help are still reachable.

How long can we keep running software from a failed vendor?

Often years: the software does not know anything has happened. But every Windows or server update is now a gamble nobody will fix if it goes wrong, so isolate the machine, freeze its environment and treat the time this buys as planning time rather than a solution.

Can Proctor Digital help if our vendor has just gone under?

Yes. We rescue UK businesses from exactly this position: assets secured, risk contained, then the system rebuilt as a modern web application with the old one running in parallel throughout. The free Legacy Risk Audit is the first step: a 30-minute call and a written one-page risk summary of where you stand.

Vendor Gone Bust? A Survival Guide

The letter says administration, the email bounces, or the support line just rings out. However the news arrives, the position is the same: the software your business depends on now belongs to a company that has stopped existing. Here is the survival guide, in the order the jobs need doing.

The answer in one paragraph

Your system does not stop working the day the vendor does. Software is admirably loyal: it has no idea its maker has gone, and it will start on Monday exactly as it did on Friday. What has changed is that nobody can patch it, fix it or reinstall it any more, and the files and people who could help you are dispersing right now, which is why the response runs at two speeds. Fast: spend the first 48 hours securing every asset you might one day need, while it can still be secured. Slow: spend the first month establishing what you own and who can help, then contain the risk and plan the exit without drama. We have seen this sequence more than once, and the businesses that come through cleanly treat day one as evidence gathering, not panic.

The first 48 hours

Five jobs. None needs a board decision, and each one gets harder with every week that passes.

Secure the installers and licence keys. Copy setup files, install media and licence certificates somewhere safe that is not the machine the system runs on. If the software validates its licence over the internet, write down exactly what it connects to: the hosting bill for that server is no longer being paid.
Export or copy the database, and find its passwords. Take a proper backup of the data files or database server, then hunt down the credentials, which usually live in a configuration file beside the application or in a former engineer’s handover notes. A copy you cannot open is not a copy.
Image any machine the system uniquely depends on. If one PC or server is special, take a full disk image rather than a file copy: the installation, its settings and its drivers may be unrepeatable now.
Test a restore. A backup is a theory until you have restored it, ideally onto different hardware, and while whoever set the backups up is still answering the phone.
Screenshot or print the critical reports. If the system one day refuses to start, month-end still arrives. Capture the reports the business lives by in the most reliable format available: paper.

One reordering. If the vendor hosted the system for you, data export moves to the top and today is not too soon. Administrators exist to turn a company into money for its creditors; keeping your service running is nobody’s job now.

The asset map

Most of what you need already exists somewhere. The problem is that nobody has ever needed to know where.

Asset	Where it usually lives	Who can get it
Installers and setup media	The server’s disk, a CD in a drawer, your IT supplier’s archive	Your IT support; a former vendor engineer
Licence keys and certificates	Onboarding emails, old invoices, a label on the machine	Whoever holds the accounts inbox
The database	The application server, or the vendor’s hosting	Your IT support; the administrator, if hosted
Database and admin passwords	Configuration files beside the application, handover notes	IT support; former vendor staff
The contract and its schedules	The filing cabinet, the solicitor who reviewed it	Accounts; whoever signed it
Source code	A software escrow agent, if a clause names one	The escrow agent, on proof of a release event
Knowledge of how it works	Former vendor staff and your own longest-serving users	You, by asking soon

The first month

Start with the contract, and read it for three things. First, a source-code escrow clause: if one names an agent and lists insolvency as a release event, you may be entitled to the source code, and the claim should start promptly and in writing. Second, data-export and termination rights. Third, what you actually own against what you merely licensed: a perpetual licence changes your position; a subscription that died with the vendor changes it the other way. Knowing all this before speaking to the administrator matters, because the administrator may be selling the product, the customer list or both to another firm, and you want to be a party with rights rather than a name on a spreadsheet.

Then people. Former staff and contractors who knew the system are the closest thing to documentation most of these products ever had. Find them before their memory of your setup fades; a paid day of a former engineer’s time can save weeks later.

Then your own memory. Document workflows now, while staff can still say why the odd steps exist. And if your vendor was really one developer rather than a company, the same playbook applies with a gentler letter; we wrote that scenario up in our software developer retired.

The signs, before the letter arrives

This section is for readers whose vendor is still trading. Insolvency rarely arrives unannounced; from the outside, we have seen the same sequence more than once.

Support slows: tickets that took a day take a fortnight, and every reply comes from the same one person.
Releases stop: the version you run stops moving, and the roadmap stops mentioning dates.
Key staff leave: the engineer who knew your account resurfaces as a freelancer.
The website goes stale: no news for a year or more, pages describing products no longer sold.
Renewal invoices arrive from a different company name: products get sold quietly between firms, and a changed name on the invoice is often how customers find out.

None of these proves anything on its own. Two or three together are a reason to run the first-48-hours list above while it is still easy, and to check the vendor’s filing history at Companies House while you are at it.

Containment versus exit

The system did not die with the vendor, but it is now frozen in time and the environment around it is not. Every Windows update is now a gamble with nobody to call if it loses; so is every new printer, every antivirus change and every well-meant IT tidy-up. Containment means deliberately stopping the world around the system: hold operating system updates on that machine, take it off the open internet, let nothing else share the box, and put a note on it saying why. Cyber Essentials expects unsupported software to be removed or isolated, so containment is not just prudence; it is what your next audit will ask for anyway.

Containment buys time; it does not buy a future. The quiet costs of running frozen software, the workarounds, the single point of failure, the key person risk, accumulate the way we set out in the true cost of keeping a DOS-era system alive. The exit is a rebuild of what the business actually needs, usually smaller than what the old system did, delivered while the old system is still running so that nothing depends on a leap of faith.

What to do about it, calmly

The order matters more than the speed: 48 hours of securing, a month of establishing rights and finding people, then a decision made on evidence rather than adrenaline. The staged route from there, audit to parallel running to cutover, is set out in the rescue roadmap. If you would rather start with an outside eye, the free Legacy Risk Audit is built for exactly this position: a 30-minute call and a one-page written risk summary covering what you have, what is exposed and what order to do things in. Vendors fail; with the assets secured and a calm plan, your business does not have to follow.

Your software vendor has gone bust. Now what?