Many websites keep running on whatever PHP version they launched with. The site loads, orders come in, and the owner sees no reason to change anything. But every PHP version has a lifespan, and once it reaches end of life (EOL) it stops receiving security fixes. Here is what that actually means and how to plan a safe upgrade.
How the PHP support cycle works
A new major PHP version ships every year, usually in November. Each version first gets active support, with bug and security fixes, followed by a security-only period. Under a decision adopted in 2024, the two periods together last about four years and end on 31 December. The table shows the status as of November 2026; check the supported versions page on the official PHP site before deciding, as dates can be adjusted.
| Version | Status | Security fixes |
|---|---|---|
| 7.4 | Unsupported | Ended November 2022 |
| 8.0 | Unsupported | Ended November 2023 |
| 8.1 | Unsupported | Ended 31 Dec 2025 |
| 8.2 | Security only | Until 31 Dec 2026 |
| 8.3 | Security only | Until 31 Dec 2027 |
| 8.4 | Active | Until 31 Dec 2028 |
| 8.5 | Active | Until 31 Dec 2029 |
The real risks
The main risk is vulnerabilities that will never be patched for your version. New PHP flaws are usually published, and automated scanners probe sites for exactly those flaws, so a site becomes a target without its owner doing anything. The second risk is CMS lock-in: new releases of WordPress, Joomla and other systems drop old PHP, so you cannot update the CMS, and plugin vulnerabilities are fixed only in versions you cannot install. Third, older versions are slower; the PHP 8 series brought internal optimisations and a JIT compiler, and many sites speed up from a version switch alone. Over time, hosts also find it harder to keep extensions for old versions compatible with new databases and crypto libraries.
Example: a school site in Namangan
A private school site, misol.uz, was built on Joomla 3 in 2018 and runs on PHP 7.4. Joomla 3 itself is no longer supported, so simply switching PHP to 8.3 would break the site. The right approach is to copy the site to a test subdomain, migrate Joomla to a current major version, replace extensions and the template, raise the PHP version there, and only then move the result to the live site. That may take more than a day, so plan ahead.
An upgrade plan
- Record PHP, CMS and plugin versions and whether there is custom code.
- Pick a target: at least 8.3, ideally 8.4.
- Back up files and the database.
- Create a staging copy running the target version.
- Update the CMS, theme and plugins and replace incompatible ones.
- Check the error log and fix what you find.
- Upgrade the live site during low traffic and monitor for a few days.
# mysql_* removed in PHP 7.0; create_function and each removed in PHP 8.0
grep -rnE "mysql_(connect|query|fetch)|create_function\(|[^a-zA-Z_]each\(" \
--include=*.php ~/www/misol.uz | grep -v "/vendor/"
# Syntax check with the new version (path depends on the server)
find ~/www/misol.uz -name "*.php" -not -path "*/vendor/*" \
-exec /opt/php83/bin/php -l {} \; | grep -v "No syntax errors"An empty result is a good sign but not a guarantee; the lint step catches only syntax errors, and runtime problems show up only by actually using the staging site. A well-maintained WordPress site often upgrades in minutes, while a neglected CMS or old custom code can take days. On sayt.uz hosting the PHP version is set per site, so you can prepare on a staging subdomain while the live site stays put. Treat the old version as temporary and set a firm deadline, ideally well before your current version drops out of security support, so the work never has to be rushed.