Your Software Vendor Ended Support. What Are a Public Body's Options?

It usually arrives as a letter. The vendor has been acquired, or is "sunsetting" the product, or will support only the newest version from next year. Sometimes there is no letter at all: the support line stops answering and the company's website goes quiet.

For a public body this lands badly, because the system usually supports a service residents notice when it stops: permits, bylaw enforcement, bookings, licensing, billing. The instinct is to start a replacement immediately. That is often the most expensive possible response, and rarely the most urgent one.

First: what "end of support" actually means

A system does not stop working on the day support ends. What changes is that risk starts accumulating:

• Security patches stop, so any vulnerability found from now on stays unpatched.
• The software is no longer tested against new versions of the operating system, database or browser, so routine upgrades elsewhere can break it.
• When something does break, there is nobody contractually obliged to fix it.

That is serious, but it is usually a slope, not a cliff, and you have time to make a considered decision if you use it. The exception is anything the vendor hosts for you or activates remotely with a licence key, which can stop on a date. Check that first.

The first two weeks: secure what you own

Before deciding anything, make sure you are not losing options you currently have.

1. Export your data. Get a complete, current export of the records in a usable format, and confirm you can read it without the vendor's software. This is the single most important step.
2. Read your agreement. Look for licence terms that survive the end of support and any right to the source code. If there is a software escrow agreement, check exactly which release conditions it lists, whether ending support for your version counts, and when the deposit was last updated or verified.
3. Inventory the dependencies. Which servers, databases, operating systems and integrations does the system rely on, and which of those are themselves out of support?
4. Capture what people know. Write down the workarounds and the "never do this" rules that the two or three regular users carry in their heads. This knowledge is the first thing lost when someone retires.
5. Check your backups. Not that they run. That a restore actually works.

The realistic options

1. Negotiate extended support

An acquiring company will sometimes sell extended support for the old version, at a price. Worth asking, especially for a short bridge while you plan. Get the end date in writing.

2. Move support to a third party

For widely used commercial products, independent firms sometimes offer support for versions the original vendor has dropped. Check what they can actually do without the source code.

3. Stabilise and extend it

If the system's core still works and its problems are specific, a set of targeted fixes can buy a few more years: moving it onto a supported server and database, closing the known security gaps, replacing a failing integration, documenting it properly. This is often far cheaper than replacement and avoids retraining staff and a wholesale data conversion. It is most practical when you have the source code or the product can still be configured, and when the data is reachable.

4. Plan a replacement

Sometimes this is the honest answer: the technology underneath cannot be secured, nobody can change it, or the work it supports has moved on. Even then, it is usually worth extending the old system for the year or more a proper replacement takes, rather than rushing a replacement under pressure.

How to choose between them

The right option depends on the system's condition, and that is a question of evidence, not opinion. The most direct way to get the evidence is an application condition assessment: a short, fixed-price, read-only review of the system that tells you in writing how much working life it has left, which problems are genuinely dangerous, and what it would cost to extend it, or to replace it if that is the honest answer.

That report also does something useful politically. It turns a vendor's letter, which is easy for a budget committee to defer, into a documented risk with priced options, which is much harder to ignore.

What we would do in your position

Secure the data this week. Read the agreement this month. Then get the system's condition on paper before committing to any path, including ours.

Bluestone's assessment is fixed at $6,500, $9,750 or $14,500 depending on how tangled the system is, and it is read-only: nothing in the running system changes. If extension is the answer, that work is priced as a ceiling that cannot move upward. If replacement is the answer, the report says so. How you buy it is set by your own purchasing bylaw or policy; check your threshold with your procurement office.

If your vendor letter has already arrived, send us a note with the product name and roughly how your organization uses it, and we will tell you in the first reply whether an assessment is worth doing.