"Our vendor has gone quiet": the four ways out

"Our software vendor has gone quiet." That sentence rarely arrives alone. It comes with a version that has not been patched in three years, a server nobody dares reboot, and a business calendar that has not moved an inch. The instinctive response is to start shopping for a replacement. It is almost always the wrong order: secure what you have first, then choose which door to leave by.

Four situations, one sentence

The same phrase covers four very different predicaments, and they do not call for the same first moves.

• The vendor has ceased trading — liquidation, struck off, no one left to call. Your maintenance contract is worth nothing, but your licences and technical access may well keep working for years.
• The vendor has been acquired. The product still exists, but it is in convergence maintenance: the buyer patches security only and steers customers towards its own platform, usually with a price rise attached.
• End of life has been announced. You have a date — which makes this the best of the four situations, because you can actually plan.
• The original developer has left. The most common case in organisations that had an in-house tool built ten years ago: the code exists somewhere, nobody knows how to build it, and the only documentation lived in one person's head.

The common factor is not technical. It is that the decision has left your hands. While the vendor still answered, the pace of change was negotiated. Now it is imposed — by a security advisory, by an operating system that goes out of support, by a bank changing a file format. You are no longer running a piece of software; you are waiting to find out what breaks first.

Before choosing anything: three things to do within a fortnight

None of these three depends on which way out you eventually pick, and all three become considerably more expensive once the system stops running.

1. 1

   Take back control of the data and the backups

   Get a complete export in a readable format, find out physically where the database lives, and confirm who holds the administrator credentials — including the hosting account and the domain name. Then restore a backup onto a separate machine and open the application. A backup that has never been restored is not a backup, it is a file.

2. 2

   Read what the contract actually says about ownership

   There is a world between a perpetual user licence and an assignment of economic rights: the first lets you use the software, the second lets you have it modified by someone else. If a source code escrow clause exists, check two things — that the deposit has been topped up recently, and that the contract defines a release event. An escrow deposit dating from 2016 releases you 2016's software.

3. 3

   Document what exists while somebody still remembers

   List the processes the system carries, its interfaces, its imports and exports, its printed outputs, its user accounts and above all its exceptions — the member handled differently since 2019, the scale that was patched by hand. This map is the only asset that is worth the same in all four exits.

Exit 1 — stay and secure

Replace nothing, and turn an abandoned piece of software into a managed asset: freeze a version, take the server off any open network, put verified backups in place, and have a third party take over corrective maintenance if the code is available. This exit is unfashionable and frequently correct.

It is the right answer when the software covers the need, when no regulatory or contractual change is expected in the next two years, and when the obsolescence is technical rather than functional. Budget a few thousand euros of hardening plus an annual corrective maintenance retainer. What you carry is a deferred risk, not a solved one: every year adds a layer of environment debt — unsupported operating system, end-of-life database — and the day an evolution becomes compulsory, the step is higher than it is today.

Exit 2 — move to an off-the-shelf product

This is the exit custom development studios present least enthusiastically, and it is the right answer in a good number of cases. If the process is genuinely standard — accounting, payroll, maintenance management, CRM, straightforward order-to-invoice — then your particular way of doing it is not an advantage, and paying to rebuild it is paying to preserve a habit.

• A documented data export you can run yourself, not a migration service quoted on the day you leave.
• The ability to reproduce your own rules through configuration — because the moment the answer is "that will need a specific development", you are back where you started, but inside someone else's product.
• The real first-year integration cost, which routinely exceeds the annual licence.
• A written reversibility commitment, with a deadline and a list of deliverables.

The risk you take on is not technical, it is organisational: you are changing your processes, not just your software, and the resistance shows up six months in. You are also not escaping dependency, you are trading it — for a more liquid dependency, on a vendor with a better chance of still existing in ten years.

Exit 3 — rewrite it as custom software

Rewriting is justified when the software carries a business mechanism that no packaged product models: tiered scales negotiated supplier by supplier, pro rata temporis on members who joined mid-year, a rebate base that excludes certain product families, an annual close with adjustments. A packaged product does not refuse those rules — it accommodates them through specific development, which puts you back into a captive position, this time with a licence to pay on top.

The cost is counted in hundreds of person-days, and the price is not the real risk. The real risk is the big bang: twelve to eighteen months with nothing in production, a specification that ages while it is being built, and users who see the tool for the first time at acceptance. If you choose this exit, buy two things in the contract — the source code and the documentation delivered, and a named project team.

Exit 4 — carve it up and replace it in batches

The hybrid: the old system stays in service and you take one complete process away from it at a time, the new system reading the old database during the transition. The first process goes live in weeks, not quarters, and each batch closes a piece of the risk. This is the arrangement we used for the Lyon buying group of more than 60 member companies whose management system we rebuilt: the declaration windows and the annual close could not be suspended for a cutover.

The total cost is comparable to a rewrite, spread over time. What you carry is the dual-running period: temporary interfaces, data in two places, and a permanent team working in two tools for several months. That cost is real and it is routinely denied in project plans. Budget it, name it, and give it an end date.

The comparison nobody puts in writing for you

If there is one thing to take away, it is this: the worst option is none of the four. It is staying exactly where you are without naming it — software nobody maintains, code nobody owns, a subject raised at every board meeting and settled at none. All four exits have a price. So does waiting, except that waiting never appears as a line in the budget.