Your website looks fine. Pages load, enquiries arrive. Underneath, the PHP version it runs on may have stopped receiving security patches months ago — and the framework version even earlier. The only warnings go to an inbox nobody reads, until the host removes the old version and the site breaks in public.
That is the quiet risk: unsupported software accumulates unpatched vulnerabilities, loses compatibility, then fails suddenly, on someone else's deadline. The fix is rarely dramatic — but it must be planned before the deadline, not during it.
The short answer: if your PHP version is past security support, you are running unpatched software in public
Every PHP version has a published end-of-life date, after which no security fixes are released for it — ever. A vulnerability discovered after that date stays open on your server permanently. The same applies, on their own calendars, to your framework and CMS.
So the short answer is a checking task, not a panic. Find your versions (ten minutes, below), compare them with the official support calendars, and if anything is past security support, treat the upgrade as dated, staged, reversible maintenance. If the work uncovers a deeper framework problem, that is what our Laravel development services exist for; most sites checked early need only the planned upgrade.
How versions age: active support, security-only, end of life — and where to check yours today
PHP versions age in stages, published on php.net's Supported Versions page — the only calendar that matters here. A branch gets about two years of active support (bug and security fixes), then about two years of security support only. After that: end of life, unsupported and unpatched.
Checked against php.net on this article's drafting date: the newest branch is in active support; the two before it are in security-only support, one ending at the close of this year; every older branch is end of life. Frameworks follow the same pattern — Laravel's official policy provides bug fixes for 18 months and security fixes for two years per major release, so a framework major from three releases ago is already unsupported. Dates move yearly, so check php.net and your framework's official policy when you read this.
Find your numbers: PHP, framework, CMS and plugin versions in ten minutes
You need four numbers. First, the PHP version: WordPress shows it under Tools → Site Health → Info → Server, and most hosting panels display it under PHP settings. Second, the CMS version, in your admin dashboard. Third, the framework version if your site uses one — your developer or host can confirm it from the project files. Fourth, plugin versions, in the same dashboard, where abandoned items stand out by their "last updated" dates.
Write the four numbers down with today's date. That record turns every later conversation with a host or developer into a comparison against the support calendars.
What actually goes wrong: unpatched vulnerabilities, dropped plugin support, and the forced-upgrade break
Three failures follow. First, exposure: vulnerabilities in end-of-life PHP and frameworks are publicly documented and nobody patches them, so an old site gets easier to attack every month. WordPress.org's own requirements page warns that its legacy minimum versions have reached end of life and may expose a site to security vulnerabilities — a warning about the PHP underneath.
Second, abandonment: current plugin, theme and framework releases are built against supported versions, so updates stop being available or start failing, and new features require versions you do not have. Third, the forced-upgrade break: hosts retire end-of-life versions on their own schedule, and a jump of several versions at once, applied to untested code, turns a routine server change into a public outage. Our WordPress, Webflow and custom comparison covers different platforms, but this risk applies to every PHP-based one.
PHP and framework versions move together — why you cannot always upgrade one without the other
Owners ask why they cannot "just upgrade the PHP". Because each framework release supports a defined range of PHP versions, published in its official documentation: an old major may not run on current PHP, while the current release requires recent PHP.
So the upgrade is a coupled ladder. PHP, framework, CMS and plugins move in an order where every step leaves the site working: CMS and plugins first, then framework and PHP in tested steps, sometimes one major at a time. Jumping several majors in one night concentrates every breaking change into one failure nobody can localise.
The safe upgrade runbook: backup, staging, compatibility scan, staged rollout, rollback plan (checklist)
Planned upgrades follow a runbook — the runbook, not bravery, makes them safe:
- Back up first, and test the restore. A backup you have never restored is a hope, not a backup.
- Clone to staging. Build a staging copy on the target version; the live site stays untouched while you learn what breaks.
- Scan compatibility. Check compatibility notes and the official PHP migration guides for changed functions your code may use.
- Click through on staging. Test the journeys that make money: forms, checkout, logins, search, both languages — not just the homepage.
- Roll out in a quiet window, in steps. Step through major versions; keep the old version available where the host allows switching back.
- Write the rollback plan first. Who restores what, in what order, and how you will know within minutes that a rollback is required.
Afterwards, a technical SEO audit confirms nothing public changed, and our Core Web Vitals launch checklist gives the performance checks to re-run.
If the host deadline is already here: emergency triage that keeps the site up
If the host's removal date is days away, triage in this order. Take the full backup today. Ask the host, in writing, for the exact deadline and target version, and whether a short extension exists — a few weeks bought cheaply converts an emergency into a planned upgrade.
Then run the runbook compressed: staging clone, fix only what blocks the money journeys, accept cosmetic breakage temporarily. If the stack cannot run on any supported PHP version — it happens with abandoned frameworks — the honest answer is a holding page or reduced static version of the key pages while a rebuild is scoped. Tell customers proactively if anything will be briefly unavailable.
Upgrade, patch-and-hold, or rebuild? Decision criteria by site age and stack
Three honest options exist. Upgrade in place when the CMS and framework are within reach of supported versions — a step or two up the ladder, with plugins still maintained. That describes most sites checked early, and it is the cheapest safe outcome.
Patch-and-hold means paying for extended support that backports security patches to an end-of-life version. It is a legitimate bridge for a defined few months, but it is rent paid to stay on old software while compatibility keeps decaying. Never a strategy. Rebuild when the framework is abandoned or the ladder needs too many jumps at once; a scoped rebuild through custom web application development then costs less than repeated emergency surgery. Compare quotes against our pricing page.
Who owns versions after launch — so this never becomes an emergency again
Every emergency here has the same root cause: after launch, version upkeep was nobody's named job. Prevention is an assignment: one named person or provider checks the four numbers against the official calendars on a set rhythm and flags the next end-of-life date while it is still a year away.
That is what structured maintenance is for. WebStackRank's starter packages include three months of free maintenance covering health checks, updates and defect fixes — the point is that upkeep is owned from day one. Whatever you choose, put the version record into it, with the next end-of-life dates written down.
Common mistakes that turn a routine upgrade into an outage
The mistakes are consistent. Upgrading PHP on the live site first because "it is only a settings change". Skipping the backup, or keeping one that has never been restore-tested. Jumping several majors in one step, unable to tell which change broke the checkout. Testing only the homepage while forms and payments fail untested.
Others ignore the coupling — upgrading the framework without checking its PHP range, or the reverse. And the most expensive mistake: treating the host's first warning as spam. That warning is the cheapest version of this problem you will ever be offered.
FAQ
How do I check which PHP version my website uses?
In WordPress, go to Tools → Site Health → Info → Server, which lists the PHP version directly. Most hosting control panels also show it under PHP or server settings. For custom or framework sites, ask your developer or host — they can read it from the server in seconds.
Is it dangerous to run an end-of-life PHP version if the site still works?
Yes. "Still works" describes today, not safety: after end of life, no security fixes are released, so every newly discovered vulnerability stays open permanently. Working sites also lose plugin and framework updates, and hosts eventually remove the version, forcing an unplanned upgrade.
Will upgrading PHP break my website?
It can, if plugins, themes or custom code rely on functions changed or removed in the newer version — which is why the safe order is backup, staging clone, compatibility checks, then a staged rollout with a rollback plan. Tested this way, most upgrades complete without public impact.
Can I upgrade PHP without upgrading my framework or CMS?
Only within the range your framework and CMS officially support — each release documents the PHP versions it runs on. An old framework may not run on current PHP, and a current framework will not install on old PHP, so the two usually climb together in tested steps.
My host is forcing a PHP upgrade this month. What should I do first?
Back up everything today, then confirm the exact deadline and target version with the host in writing and ask about a short extension. Clone the site to staging on the target version, fix what blocks your key journeys first, and roll out with a tested rollback ready.
Get your stack assessed before the deadline (CTA)
If you do not know your four version numbers — or one is already past its support date — get the stack assessed while the upgrade is still a choice. Send us your versions, or ask us to find them, and we will tell you plainly whether you need an upgrade, a patch-and-hold, or a rebuild. Start with our Laravel development services; WebStackRank provides an itemised proposal within 24 business hours once the scope is agreed.
