Your website, app or internal system is built on other people's software. An operating system, a programming language, a database, a framework, a content system, dozens of smaller libraries. Each of those layers is maintained by somebody else, and each has a date after which its makers stop fixing it.
That date passes silently, and usually without anybody noticing. Nothing breaks. The system keeps working exactly as it did the day before. What changes is that every weakness discovered from then on stays open permanently.
This guide explains what end of life actually means, which widely used versions have already expired, which expire in the next twelve months, and what your options are. Every date here was checked against the vendor's own official page in September 2026.
What does end of life actually mean?
End of life means the makers of a piece of software have stopped fixing it, while the software itself carries on running exactly as before. Security fixes stop, bug fixes stop, and support stops. Any weakness discovered after that date is never repaired.
Microsoft states this directly about Windows 10. After its support ended on 14 October 2025, computers running it "will still function", but Microsoft no longer provides technical support, software updates, or security updates and fixes [1].
That is the trap. Because nothing visibly changes, the date is easy to ignore. But the risk is not static. Security researchers and attackers continue to find weaknesses in every widely used piece of software. For supported versions, those weaknesses get fixed. For unsupported ones, the list of known ways in simply grows.
The UK's National Cyber Security Centre puts it plainly: weaknesses found in unsupported products will remain unpatched and will be exploitable by relatively low-skilled attackers [2].
Why your system has several expiry dates, not one
A typical business system sits on five or six layers of other people's software, each with its own support schedule, and the system is only as current as its oldest layer.
Take a website built in 2021. It might run on:
An operating system on the server.
A programming language such as PHP, Node.js, Python or .NET.
A database such as MySQL.
A framework or content system such as WordPress, Laravel or Angular.
Dozens of smaller libraries that handle payments, images, email, forms and so on.
Each of those was current in 2021. Each has moved on since. And each follows a different clock:
PHP supports each version for two years of active development followed by two years of security fixes only, about four years in total [3].
Node.js long-term support versions are maintained for about 30 months, and the project states production applications should only use its active or maintenance long-term support releases [4].
Microsoft .NET long-term support releases get three years of free support and patches, and standard releases get two [5].
Python versions are supported for about five years [6].
Angular versions are supported for roughly 18 to 24 months [7].
WordPress officially supports only its latest version [8].
Put those together and the conclusion is uncomfortable: a system built four or five years ago and never upgraded is almost certainly running at least one layer past its support date, and quite possibly several.
A worked example: a website built in 2021
Here is how a perfectly reasonable system, built well at the time and left alone since, looks when you check each layer against today's dates. The details are illustrative, but the pattern is a common one.
A business commissioned a customer portal in mid-2021. The developer made sound choices for that moment: PHP 8.0 for the application, MySQL 8.0 for the database, Node.js 14 to build the front end, and a popular framework version that was current that summer. It launched, it worked, and the maintenance contract covered fixing bugs.
Five years later, checked against the official pages:
PHP 8.0 is past end of life. The oldest PHP branch still receiving security fixes is 8.2, and that stops at the end of 2026 [3].
MySQL 8.0 reached end of life in April 2026, according to its own release notes [11].
Node.js 14 is long past end of life. Even Node.js 20, three major versions later, reached end of life in April 2026 [4].
The framework is almost certainly several major versions behind, with its own support long expired.
Nothing has broken. Customers log in, orders go through, reports run. From the owner's point of view, the system is fine.
From an attacker's point of view, it is a publicly reachable system running several layers that no longer receive security fixes. Every weakness published in any of those layers since their support ended is still open.
And the upgrade is now four or five steps at once on several layers, rather than one small step each year. That is the practical cost of leaving it: not a breach, necessarily, but a much larger and more expensive piece of work when something finally forces the issue.
Which versions have already expired
As of September 2026, several very widely used versions are already past their end of support. If your system uses any of them, it is running without security fixes today.
Windows 10 reached end of support on 14 October 2025 [1][9].
PHP 8.1 and every earlier version, including all of PHP 7, are no longer supported. The oldest branch still receiving security fixes is PHP 8.2 [3].
Node.js 20 reached end of life on 30 April 2026, and Node.js 18 before it on 30 April 2025 [4][10].
Python 3.9 reached end of life on 31 October 2025, and Python 2.7 on 1 January 2020 [6].
MySQL 8.0: its official release notes state that as of April 2026, with version 8.0.46, MySQL 8.0 reaches end of life, and encourage users to upgrade to MySQL 8.4 or a newer release [11].
Microsoft .NET 6 has been out of support since 12 November 2024, and .NET 7 since 14 May 2024 [5].
Angular 19 and earlier are no longer supported [7].
These are not obscure products. PHP powers a very large share of websites, including every WordPress site. MySQL sits under a great many business systems. Node.js runs a large proportion of modern web applications. If your system was built between about 2019 and 2022 and nobody has upgraded it since, the odds are high that something on this list applies to you.
What expires in the next twelve months
Seven widely used versions leave support between October 2026 and October 2027, and the time to plan for them is before the date, not after it.
| Date | What reaches end of support |
|---|---|
| October 2026 | Python 3.10 [6] |
| 10 November 2026 | Microsoft .NET 8 and .NET 9 [5] |
| 28 November 2026 | Angular 20 [7] |
| 31 December 2026 | PHP 8.2 security fixes end [3] |
| 30 April 2027 | Node.js 22 [4][10] |
| 12 October 2027 | Windows 10 consumer Extended Security Updates [1] |
Two points about this list.
Microsoft's .NET 8 is a long-term support release, which many businesses chose specifically because it was supported for longer. It still ends in November 2026. Long-term support means longer, not permanent.
PHP 8.2 matters to a great many WordPress sites, because hosting companies often left sites on whatever version was current when they were set up. If your host control panel shows PHP 8.2 or lower, it is worth planning the move now.
Apps: the stores decide for you
Mobile apps face harder deadlines than websites because Apple and Google enforce minimum requirements, and an app that falls behind can quietly stop reaching new customers.
Google Play. From 31 August 2026, new apps and app updates must target Android 16, which is API level 36, to be submitted [12]. For apps already published, Google states that existing apps must target Android 15, API level 35 or higher, to remain available to new users on devices running newer Android versions. Apps targeting Android 14 or lower will only be available on devices running the same or an older version of Android [12][13].
In plain terms, an app that has not been updated in a couple of years may already be invisible to anybody buying a new phone. Existing users keep it. New customers cannot find it.
Google allows developers to request an extension to 1 November 2026 if they need more time [12]. Google has raised the requirement repeatedly, so expect it to rise again.
Apple. Since 28 April 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later, using the version 26 software development kits [14].
The consequence businesses discover too late is that you cannot ship any update, however small, unless it meets the current requirements. If your app was last built years ago, fixing a single typo means first upgrading the build tools, the target level and possibly several libraries that no longer work with them. The fix takes an hour. The upgrade underneath it takes weeks.
Our guide on app store rejections covers the review side, and our guide on app maintenance costs covers budgeting for this every year.
WordPress, plugins and PHP
For a WordPress site, three things need to stay current: WordPress itself, the PHP version your host runs, and every plugin and theme you use. Keeping only the first one current is not enough.
WordPress itself. WordPress states that only its latest version is officially supported, and that its security team backports fixes to older versions as a courtesy [8]. As of late September 2026, WordPress describes only the most recent release in its 7.1 series as safe to use and actively maintained [15]. In 2025 it announced it would stop sending security updates to versions 4.1 through 4.6 altogether [16].
PHP. WordPress recommends PHP 8.3 or greater. It notes WordPress still works with PHP 7.4, but that version has reached its official end of life and may expose your site to security vulnerabilities [17].
Plugins and themes. These are frequently the weakest layer, because WordPress core has a dedicated security team while each plugin is maintained by whoever wrote it. A plugin whose author has stopped updating it is effectively end of life, regardless of what WordPress does.
Three habits cover most of the risk: keep WordPress on its latest version, keep PHP on a supported version, and keep the plugin list short. Remove anything you do not use, and replace anything that has not been updated in a long time. Our comparison of WordPress, Webflow and Next.js covers the platform choice more broadly.
Windows 10 in the office
Windows 10 reached end of support on 14 October 2025, and computers still running it should be upgraded or replaced on a planned timeline.
Microsoft offers Extended Security Updates to bridge the gap. For businesses, it prices them through volume licensing at 61 US dollars per device for the first year, with the price doubling each following year, for a maximum of three years [18]. The programme covers security updates only: no new features, no non-security fixes and no technical support. Devices must be on Windows 10 version 22H2 to receive them [18]. For consumers, Microsoft states extended security updates run until 12 October 2027 [1].
Extended support is a bridge, not a destination. It is deliberately priced to rise and deliberately time-limited. The right use of it is to buy the time to upgrade properly. A business that pays for a third year has usually just postponed the same decision by three years at increasing cost.
The same applies to other office software. Microsoft notes, for example, that support for Office 2021 and Office LTSC 2021 ends in October 2026 [1].
What the security agencies say
Government security agencies are unusually direct on this subject: the recommended fix for unsupported software is to stop using it.
The UK National Cyber Security Centre states that the only fully effective way to mitigate the risk is to stop using the obsolete product [2]. It recommends upgrading rather than continuing at risk, while acknowledging that immediate upgrade is not always feasible.
The US Cybersecurity and Infrastructure Security Agency lists the use of unsupported or end-of-life software in critical infrastructure on its list of bad practices, calling it dangerous and especially egregious in technologies accessible from the internet [19].
That last point matters for most businesses reading this. A website, an online store, a customer portal or a mobile app is accessible from the internet by definition. These are the systems where running unsupported software carries the most risk, and they are also the ones most likely to have been built a few years ago and left alone.
We looked for equivalent published guidance from the UAE Cyber Security Council and could not reach an official page to confirm its wording, so we have not quoted it. Our guide on cybersecurity for small businesses covers the UAE framework more broadly.
How to find out what your system runs on
Ask whoever built or maintains your system for a list of every layer and its current version. Anybody competent can produce it in an hour, and it is the single most useful document in this whole subject.
The list should cover:
The server operating system and its version.
The web server software.
The programming language and its version: PHP 8.3, Node.js 22, Python 3.12, and so on.
The database and its version.
The framework or content system and its version.
Major libraries and plugins, particularly anything that handles payments, logins or customer data.
For apps: the target Android API level and the Xcode version it was last built with.
Then add one column: the end-of-support date for each version, taken from the vendor's official page.
If nobody can produce this list, that is itself a significant finding. A system nobody can describe is a system nobody is keeping current. It is also a system that will be hard to hand to another supplier, which is a risk in its own right. Our guide on getting your data out covers why documentation matters beyond this one problem.
Why postponed upgrades cost more
Upgrades are cheapest when done one step at a time, and every step you skip makes the eventual upgrade larger, because versions build on each other.
Moving from one version to the next is usually a contained piece of work. The makers publish what changed, the changes are manageable, and most of the system carries on as before.
Moving four versions at once is different. You cross every breaking change in between. Libraries you depend on may not support the new version, or may have been abandoned altogether and need replacing. Code that relied on older behaviour needs rewriting. Testing has to cover much more.
Postponing an upgrade does not avoid its cost. It compounds it. That is why regular small upgrades are dramatically cheaper than occasional large ones, and why a system left alone for five years can reach the point where the upgrade looks like a rebuild.
This is a specific form of technical debt, and our guide on technical debt covers the wider idea.
What an upgrade project actually involves
A proper upgrade follows the same five steps whatever the technology: list the layers, copy the system, upgrade one thing at a time on the copy, test, then release. Knowing the steps helps you read a quote and spot one that skips something.
1. Inventory. The list described above: every layer, its version and its support date. This determines the order of work, because some layers depend on others. A newer framework may need a newer language version, which may need a newer operating system.
2. A copy of the system. Upgrades should never be done directly on the live system. A separate copy, usually called a staging environment, lets the work happen without customers seeing anything go wrong. If your system has no such copy, creating one is part of the job.
3. One layer at a time. Upgrading everything at once makes it impossible to tell which change caused which problem. Each layer is moved forward, the system is checked, and only then does the next layer move.
4. Testing. Every important thing the system does gets tried on the upgraded copy: logging in, taking a payment, sending an email, generating a report. Automated tests make this faster and more reliable where they exist, and our guide on software testing covers what they are. Where they do not exist, testing is manual and takes longer.
5. Release and watch. The upgraded version replaces the live one, ideally at a quiet time, with a way to roll back if something unexpected appears. The first few days afterwards deserve closer monitoring than usual.
What to look for in a quote: that it names which layers are being upgraded and to which versions, includes a staging copy, includes testing, and includes a rollback plan. A quote that says only "upgrade the system" leaves every one of those open to interpretation, and our guide on writing a software brief covers closing those gaps before work starts.
Your four options when something is past its date
When a layer of your system is past end of support, you can upgrade it, isolate it, pay for extended support, or replace the system, and upgrading is usually the right answer.
Upgrade. Move to a supported version. For most systems, most of the time, this is the correct and cheapest option, especially if it is done before the gap becomes large and before an outside deadline removes your choice of timing.
Isolate. If you genuinely cannot upgrade yet, reduce the exposure. The UK NCSC suggests keeping obsolete systems away from untrusted content, blocking them from sensitive data and services, segregating them from the rest of the network, and monitoring them [2]. This lowers the risk. It does not remove it, and it is not possible for a public website.
Pay for extended support. Some vendors sell time, as Microsoft does for Windows 10. Use it as a bridge with a fixed end, not as a plan.
Replace. When the gap is so large that the system would need rewriting anyway, or when the framework it was built on has no supported successor, replacement can be the honest answer. That is the exception rather than the rule. A supplier who proposes a full rebuild for version reasons should be able to explain why stepping forward is not possible. Our guide on whether to rebuild or fix covers that decision.
Accepting the risk is technically a fifth option. For a system that is completely isolated, holds nothing sensitive and cannot be reached from the internet, it can be reasonable for a time, provided somebody decides it deliberately and writes it down. For anything internet-facing or holding customer data, the agencies are clear.
Who is responsible: you, your supplier or your host?
Unless your contract says otherwise, keeping versions current is usually nobody's explicit job, which is exactly why it does not happen.
Your hosting company typically manages only what it runs. A managed host may patch the operating system and make newer PHP versions available, but it rarely switches your site to a newer version without permission, because doing so can break it. Check what your plan actually includes.
Your developer or agency may be contracted only to fix what breaks. Many maintenance agreements do not include routine version upgrades, which means versions age quietly until something forces a large project.
You own the decision to budget and schedule the work, even when somebody else does it.
Fix this in the contract. Ask for it to state who monitors support dates for each layer, how much notice you receive before a date passes, and whether routine upgrades are included in the monthly fee or quoted separately. Our guides on website maintenance and who to call when something breaks cover the wider agreement.
And name an owner inside the business. Whoever owns the system commercially should own the list, even if a supplier does the work. Without a named owner, each party assumes the other is watching, and the first reminder anybody receives is a rejected app update or a security incident.
Beyond security: the other costs of running old software
Security is the main reason to stay current, but not the only one: old versions also affect insurance, customer contracts, audits, hiring and performance.
Insurance and questionnaires. Cyber insurance applications and security questionnaires from larger customers commonly ask whether your systems are supported and patched. An honest answer that critical systems are end of life can affect cover or a contract.
Due diligence. Investors and buyers look at this directly. Our guide on technical due diligence covers what they examine.
Finding people to work on it. Developers are generally less keen to work on old versions, and the tools and help available for them shrink over time. A system on very old versions can become harder and more expensive to staff.
Features you cannot add. Newer libraries, payment integrations and services often require newer versions underneath. An old stack can quietly block improvements the business wants.
Performance. Newer versions of languages and databases are frequently faster. Upgrading can sometimes improve speed as a side effect, which our guide on why websites are slow touches on.
Making it routine
The businesses that handle this well are not doing anything clever; they keep a list of support dates, review it twice a year, and budget for upgrades as normal maintenance.
Keep the list. Every layer, its version and its end-of-support date, for every system you run, including the software staff use on their own machines.
Review it every six months, without fail. Check for anything that has passed its date and anything due in the next twelve months, and note any vendor that has changed or extended its schedule since the last review.
Put dates in the calendar, with a planning reminder three to six months ahead of each one.
Budget for it every year. Routine upgrades folded into a maintenance plan are a predictable monthly cost. Our maintenance guides give starting figures of around AED 150 per month for a small website and around AED 500 per month for an app. A large overdue upgrade is a project quoted by scope, and it is almost always the more expensive route.
For apps, treat the store update as a fixed yearly cost. Google has raised its target level repeatedly and Apple moves its build requirements regularly. Budget for at least one compatibility update per year regardless of whether you plan new features.
What to do this week
- Ask for the list. Every layer of your website, app or internal system, with its version.
- Compare it with the dates in this article, and with each vendor's official page for anything not covered here.
- Anything already past its date: ask for a plan and a quote.
- Anything due in the next twelve months: put it in the calendar now, with a reminder three months ahead.
- Check your maintenance contract for who is responsible for version upgrades.
- Name an owner inside the business for the list.
That is an hour of effort, and it replaces an unknown risk with a known one. It also gives you something concrete to take to a supplier, which turns a vague worry about old software into a specific, priced piece of work with a date attached.
If you would like somebody to do the first part for you, a codebase and dependency review that lists every layer of your system, its version, its support date and what upgrading involves starts from around AED 4,000 with us. No official body publishes rates for this kind of review, so these are our own figures. Upgrade work is quoted separately by scope. Final pricing depends on scope.
References
- Microsoft, Windows 10 support has ended on October 14, 2025
- UK National Cyber Security Centre, obsolete products
- PHP, supported versions
- Node.js, previous releases
- Microsoft, .NET and .NET Core support policy
- Python Developer's Guide, status of Python versions
- Angular, versioning and releases
- WordPress, security
- Microsoft, Windows 10 Home and Pro lifecycle
- Node.js Release Working Group, release schedule
- MySQL, MySQL 8.0 release notes
- Android Developers, meet Google Play's target API level requirement
- Google Play Console Help, target API level requirements
- Apple Developer, upcoming requirements
- WordPress, releases
- WordPress, security updates will cease for WordPress versions 4.1 through 4.6
- WordPress, requirements
- Microsoft, Extended Security Updates for Windows 10
- CISA, bad practices
- SKIMBOX, technical debt explained
- SKIMBOX, rebuild or fix a legacy system
- SKIMBOX, mobile app maintenance cost in Dubai
- SKIMBOX, website maintenance and AMC in Dubai
- SKIMBOX, app store rejections and review guidelines
Support dates were checked against each vendor's official page on 29 September 2026. Vendors occasionally extend or change their schedules, so confirm the current date on the official page before making a decision that depends on it.
