research/end-of-life-software-in-plain-english
End-of-Life Software in Plain English: How to Find Out When Your Software Stops Getting Fixes
Original Research • November 4, 2026 • 11 minute read
Executive Summary
Software does not wear out, but it does expire. Every product your business depends on has a date after which its maker stops fixing security problems in it. That date is called end of life, or EOL.
Nothing visible happens on the day. Your website loads, your app runs and your phone works. The change is that the next serious flaw anyone finds will not get a repair, and the people who look for flaws know which versions have been dropped.
The good news is that the dates are public, and finding them is a one-hour job. This article shows what the dates mean, where to look for four common products (PHP, Node.js, WordPress and iOS), and how to turn the answers into a short upgrade plan. Dates in this article are as of November 3, 2026.
You cannot avoid end of life, but you can make sure it never arrives as a surprise.
What does end of life actually mean?
Software makers do not support every version forever. They support the newest ones and let older ones fall away. Most follow some form of three stages:
- Active support. Bugs and security problems are fixed, and new releases arrive often.
- Security-only support. Only serious security fixes are released. Ordinary bugs stay.
- End of life. No more fixes of any kind from the maker.
Different makers use different words for these stages. PHP calls them “active support” and “security support”. Node.js calls its stages “Current”, “Active LTS” and “Maintenance”. (LTS stands for long-term support.) The meaning is close enough that one question works for all of them: until what date will the maker fix security problems in the exact version I run?
Why does it matter if nothing breaks?
Because the risk is not in the software you have today. It is in the flaw nobody has found yet.
When a flaw is found in a supported version, the maker ships a fix and you install it. When the same flaw is found in an end-of-life version, there is no fix to install. You can upgrade, which may be a large job done under pressure, or you can hope.
We wrote about what that looked like in practice in The October 2026 PHP Emergency. Sites on a supported PHP branch installed one patch. Sites on PHP 8.1 or older had no official release to install. Their owners faced an emergency upgrade across every change they had skipped.
Our own history points the same way. We built custom content management systems for graphic designers and creative firms, and kept them on quarterly preventive maintenance with an annual review. Those sites came through similar, smaller security events without trouble. The reason was not luck. Nothing they ran was far behind, so a fix was always available.
Where do I find the dates for the software I use?
Each product has an official page, and a few reference sites collect the dates in one place. Here is what we looked at for this article.
PHP
PHP powers most WordPress sites and a great deal of older custom software. The project publishes a supported versions page, and its data gives each branch an active-support end date followed by a later security-support end date.
As of November 3, 2026, the community-maintained endoflife.date data shows these end dates:
| PHP branch | Active support ends | Security support ends | Status today |
|---|---|---|---|
| 8.5 | December 31, 2027 | December 31, 2029 | Supported |
| 8.4 | December 31, 2026 | December 31, 2028 | Security fixes only soon |
| 8.3 | December 31, 2025 | December 31, 2027 | Security fixes only |
| 8.2 | December 31, 2024 | December 31, 2026 | Ends in about two months |
| 8.1 | November 25, 2023 | December 31, 2025 | Ended |
| 8.0 | November 26, 2022 | November 26, 2023 | Ended |
| 7.4 | November 28, 2021 | November 28, 2022 | Ended |
The row that deserves attention is PHP 8.2. It is still getting security fixes, and the last of them is due at the end of this year. If your site runs 8.2, the upgrade belongs in this quarter’s plan, not next year’s.
Node.js
Node.js is the runtime behind many modern websites and web apps. Its release schedule is published in the nodejs/Release repository, and the project explains the stages on its previous releases page. Only the even-numbered versions become long-term support releases, and those are the ones businesses should run.
| Node.js version | Entered long-term support | Maintenance begins | Ends |
|---|---|---|---|
| 20 (“Iron”) | October 24, 2023 | October 22, 2024 | April 30, 2026 (ended) |
| 22 (“Jod”) | October 29, 2024 | October 21, 2025 | April 30, 2027 |
| 24 (“Krypton”) | October 28, 2025 | October 20, 2026 | April 30, 2028 |
| 26 (“Lithium”) | October 28, 2026 | October 20, 2027 | April 30, 2029 |
Version 20 reached its end on April 30, 2026. Anything still on it has been without fixes for six months. Version 22 is in its maintenance stage now, with about six months left.
WordPress
WordPress is different, and it is the one most small businesses use. Unlike PHP and Node.js, WordPress does not publish a fixed support calendar for each version. The project’s supported versions page describes its policy, and the endoflife.date data marks every release since 6.4 as having no announced end date, with a note that one is announced when it happens.
What the data does show is useful. On October 28, 2026, WordPress shipped new patch releases for branches 6.4 through 7.1, so the project is currently backporting fixes to a long list of older versions. That does not mean old versions are a safe place to stay. Which old branches get a backport is the project’s call, so we advise running the newest release and keeping automatic minor updates switched on.
The part to check on a WordPress site is the PHP version underneath it. The WordPress 7.1 listing shows it works with PHP 7.4 through 8.5, but that only tells you what WordPress tolerates. Whether PHP itself still gets fixes is a separate question, answered by the PHP table above.
Plugins and themes are the other half. Each one has its own maker and its own habits. A plugin that has not been updated in two years has, in effect, reached end of life even if nobody announced it.
iOS and iPhone apps
Apple does not publish an end-of-life calendar. The endoflife.date iOS page tracks releases and marks a version as ended when Apple stops shipping updates for it. As of November 3, 2026, its data lists iOS 27 (released September 14, 2026) as current, iOS 26 and 18 still receiving updates, and iOS 17 as ended on May 13, 2025. The page also notes that Apple usually supports only the latest release and occasionally backports critical fixes to older ones.
If you publish an app, this matters in two ways. Your customers’ phones age on their own schedule, so the oldest iOS version your app supports is a decision to revisit each year. Apple also sets its own minimum tool requirements for App Store submissions; we did not check those for this article, so look at Apple’s developer pages before you plan a release.
What should I put on my list?
An inventory sounds heavy. It is not. For a small business it usually fits on one page. Start with whatever your customers touch, and then add what sits underneath.
| What to list | Where to find the version | Who knows |
|---|---|---|
| Website platform (WordPress, Shopify, custom) | The admin dashboard footer or About screen | Your developer or agency |
| PHP version | Hosting control panel, or WordPress Site Health | Your host |
| Node.js or other runtime | Your developer’s deployment settings | Your developer |
| Plugins and themes | The Plugins screen, sorted by last updated | You or your agency |
| Hosting plan and operating system | Hosting account, or ask support | Your host |
| Mobile app and its minimum phone version | App Store Connect or Google Play Console | Your app developer |
| Third-party services you call (payments, email, maps) | Their developer notices | Whoever integrated them |
Write down, for each line, the exact version and the date its security support ends. If you cannot find a date, write “unknown”. An unknown date is a finding too, because it means no one is watching that item.
How do I turn dates into a plan?
A simple traffic-light rule works well, and it keeps the plan from becoming an emergency list.
- Red: already ended. Schedule the upgrade now. Until it is done, ask your host or developer whether any extra protection is available, such as a web application firewall rule, and treat that as a stopgap only.
- Amber: ends within twelve months. Put it on the calendar for the next quarterly maintenance visit, with a named person and a date.
- Green: more than twelve months left. Note the end date and re-check it next quarter.
Applied to the tables above, a business running PHP 8.2 and Node.js 22 has two amber items, and PHP 8.2 is the closer one. A business on PHP 8.1 and Node.js 20 has two red items and a conversation to start this week.
A few habits keep the list from going stale:
- Re-check every quarter. Dates can move, and new versions arrive. A quarterly pass catches both.
- Upgrade one step at a time. Moving from PHP 8.2 to 8.3 is a smaller job than 7.4 to 8.5. Small steps are easier to test and to undo.
- Test on a copy first. Run the upgrade on a staging copy of the site, click through checkout, forms and logins, and only then touch the live one.
- Take a backup you have tested restoring. An upgrade that goes wrong is the situation backups are for.
- Ask vendors for their end-of-support dates in writing. If your agency or software supplier cannot tell you, that is worth knowing.
What if I can’t upgrade yet?
Sometimes the software depends on something that cannot move. A custom plugin may only work on an old PHP, or a vendor may not support the newer version yet. That happens, and the answer is not to ignore it. It is to shrink the risk while you work on the fix:
- Find out exactly what blocks the upgrade, and put a date on removing the blocker.
- Ask your host whether they offer paid extended support or patched builds for the old version. Some do. Confirm what is actually included.
- Reduce exposure: keep the old system off the public internet if it does not need to be there, limit who can log in, and turn on logging so you would notice a problem.
- Plan the replacement as a project with an owner, not as a someday task.
None of this makes an unsupported version safe. It buys time, and the time needs a purpose.
Where an audit fits
If you read the table above and could not fill in half of it, that is common and fixable. Our Audit Sprint is a fixed-price review that maps what you run, who owns it and when each part needs attention, and ends with a written plan. If you already know what you run and just want it kept current, our Care Plans cover regular maintenance. Both are described on their pages, and you do not need either to use the list in this article.
Conclusion
End of life is a calendar problem, not a technology problem. The dates are public, the tools to look them up are free, and the worst outcomes come from not looking.
This week, do three things. Write down the exact versions of PHP, your runtime and your website platform. Look up each end date. Mark each item red, amber or green and put a date next to every amber one. Then repeat the check every quarter.
Sources
Opened and read for this article on November 3, 2026:
- PHP project, release branch data (the source behind the supported versions page), and the supported versions page it describes. The page itself was not reachable from our environment, so the dates in the PHP table come from the endoflife.date data below.
- endoflife.date PHP data, which lists each branch’s release, active-support and security-support dates.
- Node.js project, release schedule and previous releases page.
- endoflife.date WordPress data, including release dates, supported PHP ranges and the October 28, 2026 patch releases.
- endoflife.date iOS data, including the note on Apple’s support practice.
Related reading
- The October 2026 PHP Emergency: Why Staying Current Always Costs Less
- Reading a Security Advisory in the First Hours
- Your Website Is a Business Asset
Frequently asked questions
What does end of life mean for software?
End of life is the date after which the people who make a piece of software stop releasing fixes for it, including security fixes. The software keeps running. What changes is that any flaw found afterward stays open. Attackers read the same public announcements as everyone else, so they know exactly which older versions are no longer being repaired.
How do I find out which PHP version my website uses?
Ask your host or developer, or look in your hosting control panel, where the PHP version is usually shown in a settings page. WordPress also reports it under Tools, then Site Health, then Info, then Server. Write the exact version down, such as 8.2, and then look up its end date on the PHP project's supported versions page.
Is Node.js end of life the same as PHP end of life?
The idea is the same, but the schedules differ. Node.js publishes a release schedule where each even-numbered version gets about 30 months of support, ending in April of a given year. PHP gives each branch a date for general fixes and a later date for security fixes only. Look up each product on its own schedule.
My site works fine on an old version. Why upgrade?
Working fine and being safe are different things. An unsupported version runs normally until someone finds a flaw in it, and from then on there is no official fix. The cost of upgrading is smallest when you do it on a calm quarter, one step at a time, instead of in the week a serious flaw is announced.
How often should I check software end-of-life dates?
Check every quarter, and plan the larger upgrades once a year. A quarterly check takes under an hour if you keep a simple list of what you run and when each item stops being supported. Anything expiring within twelve months goes on the plan; anything expiring within six months gets a date on the calendar.