Your system still works. So why is it a risk?

When a system has run quietly for three years, the natural thought is: it works, so leave it alone.

That is fair for the part you paid for. The code your developer wrote in 2023 is the same code today. But your system doesn’t run on its own. It sits on other software: the language it is written in, the database that holds your records, the operating system of the server or PC, and the certificate that puts the padlock on your website. Each of those comes with an end date.

What an end date means

Every one of those parts gets security fixes for a fixed period, published years in advance. When the period ends, new security holes are still found, but nobody fixes them. The system keeps working exactly as before. It just stops being protected.

PHP, a language many business systems are written in, puts it plainly: anyone on a version past its end of life should upgrade as soon as possible, because they may be exposed to security holes that will never be fixed.^⁠[1]

What has already expired, and what is next

These are common under business systems built in the last few years:

If your system went live before 2023 and nobody has upgraded what sits under it, there is a good chance at least one row applies to you.

Why it matters when nothing is broken

This is how most break-ins start now. Verizon’s 2026 breach report found that 31% of breaches began with attackers exploiting a software weakness, more than with stolen passwords.^⁠[7] Old versions are an easy target, because once a hole is announced, the details are public and the fix never comes.

A leak has a deadline in Malaysia. Under the Personal Data Protection Commissioner’s guideline, a breach likely to cause significant harm, or one affecting more than 1,000 people, must be reported to the Commissioner within 72 hours.^⁠[8] If a vendor runs the system for you, the guideline expects your contract to make them tell you promptly.^⁠[8]

Certificates now expire twice a year. When one lapses, browsers warn visitors that your site isn’t secure, and apps that talk to your server can stop working. If renewal depends on someone’s calendar reminder, it will be missed sooner or later. At 200 days, it now has to happen about twice a year, and from March 2027 nearly four times.

Upgrades get bigger the longer they wait. Moving one version at a time is routine work. Jumping several versions at once means dealing with years of changes in one go, usually with the system live and the original developer long gone.

How to find out where you stand

Ask your developer or vendor for one page that lists:

1. Every part the system runs on, with its version. The language and framework (for example PHP and Laravel), the database, the server’s operating system, and any office PCs the system depends on.
2. The end-of-support date for each one.
3. How the website certificates renew. Automatically, or by hand?
4. Who receives the warning emails for the domain, the certificates and the cloud account.
5. When security updates were last applied.

If nobody can produce this page within a week, that tells you something too.

What to do with the list

• Anything already past its date: plan the upgrade now. Start with whatever faces the internet or holds customer data.
• Anything ending within 12 months: book the work before the date, not after it.
• Certificates: make renewal automatic, so it doesn’t depend on anyone remembering.
• Make it someone’s job. One named person reviews the list every quarter, inside your company or at your vendor. Write it into the agreement if it is the vendor, along with how fast they must tell you about a breach.

Our view

Software doesn’t wear out like a machine. What ages is everything around it, and that happens on dates that are published years ahead.

So systems rarely get into trouble because the end dates were secret. They get into trouble because watching the dates was nobody’s job. The original project ended, the developer moved on, and the system kept working, so nobody asked. Fixing that is less about technology than about giving one person the list and the responsibility.

Common questions

Our system is only used inside the office. Is it still a risk?

Less exposed, but not safe. Many internal systems are still reachable from outside, through remote access or an app, and almost all of them hold customer or staff data. Treat “internal” as a reason to check, not a reason to skip.

Doesn’t our hosting company handle updates?

Ask them exactly what they update. Hosting often covers the server underneath. The language your code is written in, its framework and sometimes the database usually need your developer, because upgrading them means changing and testing your code.

How often should we check?

Review the list every quarter, and plan one round of upgrades a year. Most end dates are announced long before they arrive, so a quarterly look means nothing should surprise you.

How we can help

If nobody can tell you what your system runs on, a System Review for RM5,000 gives you that list, the risks and a plan, within 10 business days of getting access and talking to your team. A contained upgrade can then be a fixed-price Fix Sprint. If you would rather someone owned all of this month after month, that is part of Managed Delivery with technical ownership.