Accurate as of 23 October 2026. Software support dates, regulations, enforcement decisions and prices change. Please check the official sources linked in this article before you make decisions. This article is general information, not legal, financial or professional advice.
TL;DR
Every business system is built on parts that expire. PHP 8.2, a version many web-based business apps still run on, stops receiving security fixes on 31 December 2026.
When a version expires, newly found security holes stay open. In June 2024, a critical PHP flaw that ransomware groups exploited was fixed for supported versions only. PHP 8.0, 7 and 5 got no patch.
In Singapore this is a PDPA issue, not just an IT one. The PDPC has penalised organisations for outdated and unsupported software, and responsibility stays with the business even when a vendor runs the system.
With custom software, platform upgrades are your project and your bill, and they usually arrive in lumps. With SaaS, the vendor upgrades one shared platform for every customer and the cost sits inside the subscription.
Custom is still the right answer for some businesses. Use the Expiry-Date Count and the 5-Year Cost Worksheet below to decide on numbers, not gut feel.
The email that every system owner eventually gets
It arrives on an ordinary Tuesday. It is from the company that built your system years ago. The subject line says something like “Mandatory platform upgrade: quotation attached.”
You open it. Nothing new is being added. No new screens, no new reports. After the work is done, the system will look exactly the same as it does today. And the quotation is not small.
Your first thought is the one almost every owner has: “It’s working fine. Why am I paying to stand still?”
It is a fair question. The honest answer is that your system has been ageing the whole time. Not the part you see, but the parts underneath it. For custom-built software, the bill for keeping those parts alive was always going to land on your desk. It just was not in the original proposal.
We build both kinds of system at Zetta Solution: customised software for businesses whose processes are genuinely unique, and AveriWorks, a cloud ERP subscription. So this is not an article about custom software being bad. It is about a cost that is easy to miss when you compare a one-off build price against a monthly fee.
What does “end of life” mean for business software?
End of life (EOL) is the date a software maker stops releasing fixes for a version, including security fixes. Your software does not stop working on that date. It simply stops being repaired. Any security hole discovered afterwards stays open permanently, unless you move to a newer version.
The catch is that a business system is not one piece of software. It is a stack of parts, and each part has its own clock:
The programming language the system is written in, such as PHP.
The framework developers build on top of that language.
The database that stores your customers, invoices and stock.
The operating system and web server the whole thing runs on.
Dozens of smaller libraries for things like PDF generation, email and payments.
When any one of those parts reaches end of life, the system is running on an expired foundation, even if every screen still works perfectly.
PHP as a worked example
PHP is one of the most widely used languages for web-based business software, which makes its calendar a useful example. According to the official PHP supported-versions page, each release branch gets two years of full support, then two more years of critical security fixes only. After that, it reaches end of life.
PHP version | First released | Security fixes until | Status on 23 Oct 2026 |
|---|---|---|---|
8.5 | 20 Nov 2025 | 31 Dec 2029 | Fully supported |
8.4 | 21 Nov 2024 | 31 Dec 2028 | Fully supported |
8.3 | 23 Nov 2023 | 31 Dec 2027 | Security fixes only |
8.2 | 8 Dec 2022 | 31 Dec 2026 | Security fixes only. Ends in about 10 weeks |
8.1 | 25 Nov 2021 | 31 Dec 2025 | End of life |
8.0 | - | 26 Nov 2023 | End of life |
7.4 | - | 28 Nov 2022 | End of life |
5.6 | - | 31 Dec 2018 | End of life |
Sources: PHP supported versions and PHP unsupported branches. Dates checked 23 October 2026.
The PHP project itself is blunt about older releases. Its end-of-life page warns that using them may expose you to security vulnerabilities that have been fixed in newer versions.
What actually happens after a version expires?
Here is a real example of the gap end of life creates.
In June 2024, security researchers disclosed a critical flaw in PHP, tracked as CVE-2024-4577, that could let an attacker run their own code on an affected server. Belgium’s national cyber security centre rated it 9.8 out of 10 on the standard severity scale and later reported that a ransomware group was actively exploiting it.
The PHP team released fixes quickly, in versions 8.3.8, 8.2.20 and 8.1.29. But Hong Kong’s computer emergency response team, HKCERT, noted plainly that PHP 8.0, PHP 7 and PHP 5 were end of life, so no patch was available for them.
To be fair and precise: that particular flaw affected PHP running on Windows in a specific configuration, so not every PHP system was exposed. The pattern is what matters. Supported versions got a fix within days. Expired versions got nothing, and never will.
Who pays for platform upgrades? With custom software, you do. The code is yours, so keeping it compatible with supported versions is your project, usually quoted separately when the time comes. With SaaS, the vendor upgrades one shared platform for all customers and builds that cost into the subscription. |
Why this is a business risk in Singapore, not just an IT one
The PDPA expects you to keep systems patched
Under the Personal Data Protection Act, organisations must make reasonable security arrangements to protect the personal data they hold. That includes your customers’ names, contact details and payment information sitting in your business system.
The PDPC has been explicit about what “reasonable” looks like. In its 8 January 2026 decisions, it issued financial penalties to four organisations. The failures it listed included inadequate patch management and using outdated or unsupported software, and the incidents affected more than 1 million individuals in total. Its first key takeaway for organisations: apply timely software and system updates.
“Our vendor handles it” is not a defence
This is the part many owners miss. Outsourcing your system does not outsource your responsibility.
In a 2022 decision, the PDPC found a retailer had not scheduled software updates, its operating system and anti-virus were outdated, and it had not set data protection requirements with its POS vendor. The Commission held that the organisation bore full responsibility for the missing updates and patches.
In a 2023 decision, a patch released in May 2019 had never been installed. The organisation had no process to manage patches and had not asked its IT vendor to apply it.
In both cases, the vendor’s role did not move the obligation off the business.
Cyber readiness is becoming a business credential
This month’s Singapore International Cyber Week put the issue front and centre. Singapore launched its Cybersecurity Strategy 2026 at the opening ceremony on 13 October. The next day, Senior Minister of State Tan Kiat How told businesses that almost nine in ten organisations surveyed in CSA’s Cybersecurity Health Report 2025 encountered at least one cybersecurity incident in 2025.
His list of fundamentals started with keeping systems patched. He also noted that GovTech will require government vendors managing critical systems and sensitive government data to meet Cyber Essentials and/or Cyber Trust mark requirements by end 2027, and announced a new Cyber Incident Helpline for businesses.
CSA’s Cyber Essentials mark, the baseline certification aimed at smaller organisations, assesses software updates as one of its controls. A system sitting on an expired version is hard to square with that, whoever built it.
Why upgrading custom software costs real money
If upgrading were a button, nobody would write articles about it. In custom software, it is a project, for five reasons.
Code written for an old version can break on a new one. Each major version changes or removes features. PHP publishes a separate migration guide for every version jump because the changes are real.
Everything around the language moves too. The framework, libraries, database drivers and server often need upgrading at the same time, each with its own breaking changes.
Every customisation has to be retested. The more bespoke the system, the more screens, reports and integrations someone has to check, including your own staff during user testing.
Skipped upgrades compound. Jumping several versions at once is a much bigger project than moving one step at a time, which is why long-delayed upgrades produce the biggest quotations.
Regulatory change is the same kind of work. When rules change, such as Singapore’s move to GST InvoiceNow, a custom system needs a change request you fund. A SaaS product ships it as an update for everyone.
None of this is a sign of bad developers. It is simply how software ages. Research has long shown that keeping software running costs more than building it. A classic study by Lientz and Swanson found that at least 50% of total life cycle cost goes to maintenance, and the International Software Benchmarking Standards Group notes it is generally believed to be 65 to 85 percent of an application’s total ownership cost.
In other words, the build price you compared against a SaaS subscription was probably the smaller part of what the system will cost you.
Custom software vs SaaS: side by side
| Custom-built software | SaaS (cloud subscription) |
|---|---|---|
Upfront cost | Build fee, often significant | Low or none; monthly or annual subscription |
Platform upgrades (language, framework, database) | Your project, usually quoted when needed | Vendor’s job, included in the subscription |
Security patches | Applied when you or your vendor schedule them | Applied centrally for all customers |
Regulatory changes | Change request you fund | Shipped as a product update |
Cost pattern | Lumpy and hard to predict | Predictable |
Fit to your process | Built around exactly how you work | You adapt to a standard flow, within its settings |
Control over roadmap | Full | Limited; the vendor decides |
Main dependency | Whoever understands your code | The vendor; check data export before you sign |
Best for | Processes that are genuinely your competitive edge | Standard accounting, sales, purchasing and inventory |
Bottom line: if most of what your system does is standard business administration, paying to own and upgrade that code is usually a cost without a benefit. If the system is your edge, owning it can be worth every dollar, as long as you budget for upgrades from day one.
When custom software is still the right call
We would be doing you a disservice if we pretended SaaS fits everyone. Custom software still makes sense when:
The process is your competitive advantage. If the way you quote, schedule or fulfil is what wins you business, forcing it into a standard flow can cost more than any upgrade.
You need deep integrations with machines, specialised equipment, partner systems or legacy platforms that no off-the-shelf product supports.
Your volumes or structure are unusual, such as many entities, unusual billing models or industry-specific rules.
If that is you, go in with eyes open. Ask for an end-of-life roadmap for every layer of the stack, put a platform-upgrade clause in the contract that says who pays and when, and set aside an annual budget for it.
And SaaS is not automatically safe
A subscription moves the work to the vendor, but you still have to choose the vendor well. In January 2026, the PDPC penalised an HR SaaS provider S$17,500 for breaching its protection obligation, and noted that SaaS providers should have the technical expertise to keep up with evolving threats. Before you sign with any SaaS vendor, ask how often they patch, where your data is hosted, whether you can export it, and what security certifications they hold.
The middle path
Many businesses do best with a hybrid: a standard SaaS platform for the core (accounting, sales, purchasing, inventory) and a small piece of custom work only where they are genuinely different. The smaller the custom part, the smaller every future upgrade bill.
The Expiry-Date Count: a 5-minute exercise
Before you compare prices, count how many expiry dates your system will cross in the next five years. Each one is a likely upgrade project.
List the layers. Ask your developer or IT vendor for the exact versions of the language, framework, database and operating system your system runs on.
Look up each end-of-life date on the maker’s official site, such as php.net for PHP.
Count the dates that fall within the next five years. Each is a probable upgrade.
Flag anything already past its date. That is your priority, because you are running on an expired foundation today.
Here is why this matters even for a brand-new build. A system launched today on PHP 8.4 loses security support on 31 December 2028. Start on the newest version, 8.5, and the date is 31 December 2029. Either way, a custom system built this month will need at least one major language upgrade within five years, before you count the framework, database or server.
The 5-Year Cost Worksheet
Fill this in with real quotations, not estimates. If a custom vendor cannot quote the upgrade lines in writing, that tells you something too.
Cost line (5 years) | Custom-built | SaaS |
|---|---|---|
Initial build or setup | Build fee | Onboarding and data migration |
Hosting, backups, SSL | Hosting fees × 5 years | Usually included |
Support or maintenance retainer | Annual fee × 5 | Usually included |
Platform upgrades | Number from your Expiry-Date Count × cost per upgrade | Included |
Staff time for testing each upgrade | Hours × staff cost | Minimal; the vendor tests |
Regulatory changes | Change request quotations | Included in product updates |
Security reviews and patching | Penetration tests, patch scheduling | Vendor-run; ask for evidence |
Subscription | - | Monthly fee × 60 |
Extra users and add-ons | Change requests | Published add-on pricing |
Training and process change | Usually low | Time to adapt workflows |
Exit cost | Handover to a new developer | Data export and migration |
Total | S$ ____ | S$ ____ |
8 questions to ask about the system you have today
If you already run a custom system, you do not need to panic or rebuild. You need answers. Take these to your developer or IT vendor this week:
Which exact versions of the language, framework, database and operating system does our system run on?
When does each of those reach end of life?
Is anything already past its end-of-life date?
Who is responsible for platform upgrades under our contract, and who pays?
When was the last security patch applied, and who checks for new ones?
Can you give us a written upgrade roadmap for the next three years?
How much of our system is genuinely unique to us, and how much is standard accounting, sales or inventory?
If you stopped supporting us tomorrow, could another developer take over the code?
How to read your answers: if you cannot answer questions 1 to 3 with confidence, start there. If question 4 has no written answer, that is the conversation to have before the next quotation arrives. And if question 7 reveals that most of your system is standard, it may be time to look at whether you need to own that code at all. We covered the move from older desktop software in our guide to legacy accounting software and GST InvoiceNow.
Frequently asked questions
Does my software stop working when PHP reaches end of life?
No. Your system keeps running exactly as before. What stops is the supply of fixes. Any security flaw found after the end-of-life date will not be patched for that version, so the risk grows over time rather than all at once.
Is PHP 8.2 still safe to use?
PHP 8.2 receives critical security fixes until 31 December 2026, according to php.net. After that it is end of life. If your system runs on 8.2, plan the move to a supported version, such as 8.4 or 8.5, now rather than in January.
Is SaaS always cheaper than custom software?
Not always. For standard business processes over five years, SaaS is often cheaper once upgrades, hosting and support are counted. For highly unique processes, custom can be worth more than it costs. Use the 5-Year Cost Worksheet above with real quotations to compare your own case.
How often does custom software need a major upgrade?
It depends on the stack, but each PHP version now gets about four years of support in total. So a custom PHP system should expect a major language upgrade every few years, plus separate upgrades for its framework, database and server, each on their own timeline.
My system is only used internally. Do I still need to upgrade?
The risk may be lower, but it is not zero. Internal systems can still be reached through compromised staff devices or other weak points on your network, and PDPA obligations apply to personal data wherever it is stored. Unsupported software is the kind of gap the PDPC has repeatedly flagged.
What happens to my data if I leave a SaaS provider?
That depends on the provider, which is why you should ask before you sign. Check whether you can export your full records in a usable format, how long they keep your data after you leave, and whether there is any lock-in period or penalty.
Want platform upgrades to be someone else’s job? AveriWorks is a cloud ERP built for Singapore businesses: accounting, sales, purchasing, inventory and GST InvoiceNow on one platform that we keep updated for every customer. Platform upgrades and security patches are part of the subscription, not a separate quotation.
Every company runs on its own isolated database with two-factor authentication and a full audit trail. You can change plans at any time, with no lock-in. Start free or compare plans. Prices as listed on 23 October 2026. And if your processes genuinely do not fit a standard flow, Zetta Solution, the team behind AveriWorks, also builds customised systems. Tell us what you need and we will tell you honestly which route fits, including what the upgrades will cost. |
Sources
PHP Group, Supported Versions, checked 23 October 2026.
PHP Group, Unsupported Branches, checked 23 October 2026.
HKCERT, PHP Multiple Vulnerabilities, 11 June 2024.
Centre for Cybersecurity Belgium, Warning: PHP Remote Code Execution, Patch Immediately!, 10 June 2024 (updated 13 June 2024).
PDPC, New Commission’s Decisions and Undertaking on 8 January 2026.
PDPC, Decision: Southaven Boutique Pte Ltd, 2022.
PDPC, Decision: Tokyo Century Leasing, 2023.
Baker McKenzie, Singapore: PDPC fines several organizations, January 2026.
CSA, Opening Remarks by SMS Tan Kiat How at the SICW SG Cyber Safe for Enterprises Event, 14 October 2026.
CSA, Singapore Launches Cybersecurity Strategy 2026, 13 October 2026.
TÜV SÜD, CSA Cyber Essentials mark certification.
ISBSG, Lessons Learned from the ISBSG Maintenance & Support Dataset.
University of Washington CSEP 503, Total life cycle cost (citing Lientz and Swanson).
AveriWorks, Pricing, checked 23 October 2026.