What happens when your business software goes out of support?

Nothing visible happens, which is the problem. The software keeps running exactly as before, but the vendor stops issuing security fixes, so every flaw discovered afterwards stays open permanently. Unsupported systems are a specific finding in an Essential Eight assessment and an increasingly common question on insurance renewals.

The reason this is worth an article is that end of support is the least dramatic deadline in business technology. A licence expiring locks you out; a subscription lapsing sends emails. Support ending does precisely nothing on the day. The machine boots, the program opens, the invoices go out. The change is entirely in what happens next: from that date, when a researcher or an attacker finds a way in, no fix is coming. The gap between the software being fine and the software being a liability is invisible from the inside.

What actually accumulates is risk with a ratchet. Every month after support ends, the pool of known, published, permanently unpatched vulnerabilities grows. Attackers pay attention to end-of-support dates for exactly this reason, because the population of systems still running the old version is large, and it is a reliable target that never gets harder. This is why an unsupported operating system sitting in a consult room or a workshop is not a theoretical concern; it is a known-good route in.

The practical consequences reach beyond security, and they arrive in an inconvenient order. Other software stops supporting it: the accounting package's new version will not install, the browser will not update, the clinical or job-management system announces it now requires a newer platform. Your own vendors begin refusing to help, since supporting a customer on an unsupported base is a liability they do not want. And compliance obligations start biting, because the Essential Eight expects supported and patched systems, and a renewal questionnaire that asks the question directly leaves nowhere comfortable to stand.

So the job is to know before it happens, which requires an inventory with dates attached rather than a list of software. For every operating system, server platform, database, line-of-business application and significant utility, you want the version, the vendor's support end date, and who owns the decision. Most small businesses have never assembled this, and assembling it for the first time reliably surfaces something already past its date that nobody had thought about in years.

Then plan against those dates rather than against the calendar of crises. Anything already unsupported is urgent and should have a replacement plan with dates on it this quarter. Anything ending within twelve months belongs in the budget now, because migrations take longer than expected and the ones done under time pressure are the ones done badly. Anything further out gets reviewed annually. The point of the exercise is to convert a series of future emergencies into a schedule, which is both cheaper and considerably less stressful.

Where replacement genuinely cannot happen quickly, and sometimes it cannot, the answer is documented containment rather than silence. Isolate the system so it can reach as little of the network and the internet as possible. Restrict who can use it. Make sure it is backed up and that you have tested restoring it. Write down why the exception exists, who approved it and when it ends. That is a defensible position; an undocumented unsupported system is simply a gap that will be found by an assessor, an insurer or an attacker, and the order is not up to you.

Before assuming replacement is the only route, check what the vendor offers, because there is sometimes a middle path. Extended security updates, paid support arrangements and long-term-support releases exist for some products, and they buy genuine time at a genuine price. Treat any of them as a bridge with an end date rather than a destination, and put the replacement plan in place while the bridge is holding, since the one thing these arrangements reliably do is expire.

The honest caveat is that this is often a budget conversation wearing a technical costume, and pretending otherwise helps nobody. Replacing a core system is expensive and disruptive, which is exactly why it gets deferred until something forces it. The argument worth making internally is that the cost does not go away by waiting; it just gets paid later, at a worse moment, with less choice about how. If you want your software inventoried against vendor support dates so the decisions are visible, call 1800 456 567.