In 30 seconds
- PHP 8.2 gets its last security patch no later than December 31, 2026. From January 1, 2027, any new flaw stays open.
- Your system doesn't shut down that day: it keeps running, but without fixes, and the next serious flaw, like PHP2Shell in October, won't get an official fix for 8.2.
- Start by confirming the exact version on every server. Today, the minimum safe release in the branch is 8.2.35.
- The recommended target is PHP 8.4, supported until the end of 2028. If some part of your system doesn't support it yet, PHP 8.3 is the shortest jump, supported until the end of 2027.
- Two months is enough for an up-to-date system, if you start now and avoid migrating during year-end close.
- If you cannot migrate before 12/31, third-party patches will keep you protected while you finish the migration.
PHP 8.2 reaches end of life on December 31, 2026. That leaves two months to move to PHP 8.3 or 8.4, and the deadline lands right on the holidays, peak season for many retailers and the year-end financial close. Aim to have the migration done before December.
PHP 8.2 was the go-to version through 2023 and 2024, and many systems were installed or upgraded on it. That's why it's still one of the most common versions on business servers. At DCisGlobal we see it often in assessments: the system works fine, nobody checked the date, and the deadline can now be counted in weeks.
What happens on December 31, 2026?
PHP 8.2 security support ends. Its active support, the phase that fixes general bugs, already ended on December 31, 2024. Since then it has only received security patches, and from 2027 it won't receive any.
| Version | Security support | What it means for the business |
|---|---|---|
| 8.1 | Ended 12/31/2025 | Get off it as soon as possible |
| 8.2 | Until 12/31/2026 | Migrate in the next two months |
| 8.3 | Until 12/31/2027 | The shortest jump, with a year of runway |
| 8.4 | Until 12/31/2028 | The recommended target |
| 8.5 | Until 12/31/2029 | The newest branch |
The date won't move. PHP publishes each branch's schedule when it ships, and the 8.2 schedule has been set since 2022.
What if you cannot migrate before December 31?
There will be patches after that date, but not official ones. Debian 12 keeps fixing its PHP 8.2 until 06/30/2028, and Red Hat Enterprise Linux 8 and 9 do so until May 2029. For other servers there are companies that publish patches for unsupported PHP versions, including as extensions for control panels such as cPanel and Plesk.
These patches fix security flaws without changing branches, so the code does not break. They let you get through year-end close without rushing and migrate calmly in 2027, not stay on 8.2 forever.
At DCisGlobal we can install the patch and keep it up to date while the migration is done.
Want the patch applied? Message us on WhatsApp and we will review your server.
What breaks, and what risk do you run?
Nothing breaks on January 1. Your website, online store or business system keeps working the same way. The problem is what comes after:
- Flaws that don't get fixed. The example is recent: on October 21, 2026, PHP released the fix for PHP2Shell, two critical flaws that let an attacker take over a server. It reached 8.2.35 because the branch was still supported. A similar flaw in 2027 would have no official fix for 8.2. We cover it in what PHP2Shell is and what to do.
- Your host changes the version on its own. Many providers retire unsupported versions or move them to a paid plan. If the switch happens without prior testing, your system can stop working overnight.
- The rest of the stack moves on. Plugins, modules, payment gateways and e-invoicing libraries keep raising their minimum PHP version. Staying on 8.2 ends up blocking updates you actually need.
- Audits and customers who ask. An unsupported version shows up in any security review, and more and more companies include it in their vendor requirements.
One caveat: if your server uses the PHP that ships with your Linux distribution (Debian 12, for example, ships 8.2), the distribution's maintainers may keep applying some patches on their own. Confirm it with whoever runs the server; don't assume it.
How do you check your PHP version?
It takes minutes, and it's worth doing on every server, not just the main one:
- Hosting control panel: almost all of them show each site's PHP version in the settings.
- On the server: the php -v command shows the exact version, for example 8.2.29. Watch out: the version your scheduled tasks use can differ from the one serving the website.
- In WordPress: Tools, Site Health, Info, Server section.
- In the site's response: some servers report it in a header such as "X-Powered-By: PHP/8.2.20". If you can see it from outside, so can anyone.
Once you have the version, the reading is simple. If it's 8.2 and below 8.2.35, update within the branch right away because of PHP2Shell. In parallel, plan the jump to 8.3 or 8.4 before year-end.
Not sure which version your system runs or how big the jump is? Send us the name of the system and we'll go through it with you. Check my PHP version
Which version should you move to: 8.3, 8.4 or 8.5?
The newest one that every part of your system supports: the framework or CMS, the plugins or modules, and the libraries that connect to third parties.
- PHP 8.4, the recommended target. It has active support until 12/31/2026 and security support until 12/31/2028. From 8.2 it's a two-version jump, but the changes are still limited.
- PHP 8.3, if some part of the stack doesn't support 8.4 yet. It's the smallest change, but it leaves one year of runway: its active support ended on 12/31/2025, and it gets security patches only until 12/31/2027. We go into detail in PHP 8.3 end of life: dates, risks and how to migrate.
- PHP 8.5, if your system is modern and up to date. It's the newest branch, supported until 12/31/2029. Confirm first that every dependency already supports it.
What changes when you move from PHP 8.2 to 8.3 and 8.4
Not much, compared with earlier jumps such as 7.4 to 8.0. The official php.net migration guides mostly document deprecations and specific adjustments:
- Incrementing empty or symbol-filled strings is deprecated (8.3). Using "++" on a string that is neither a number nor a mix of letters and digits now triggers notices. It shows up in old code that builds codes or sequences.
- Stricter date errors (8.3). The date functions now throw their own errors instead of plain warnings. Test anything that calculates due dates, bookings or periods.
- Parameters that accept null without declaring it (8.4). A very common way of writing functions is now deprecated. It doesn't stop anything, but it floods the logs with notices until it's fixed, and the fix is mechanical.
- Extensions no longer bundled (8.4). IMAP, OCI8, PDO_OCI and PSpell are no longer part of PHP and have to be installed separately. If your system reads email over IMAP or connects to an Oracle database, check this first.
- Passwords take a bit longer to hash (8.4). The default bcrypt cost for storing passwords went up from 10 to 12. It's more secure, and on tight servers you'll notice it at login.
As with other jumps, the big work usually isn't in PHP itself but around it: the framework, the CMS and the plugins that need their own updates.
How to migrate in two months without stopping the business
- This week, take inventory. The exact version on every server (production, staging and the ones nobody remembers), which system runs on each one and who maintains it.
- Dependencies. List the framework, CMS, plugins, modules and libraries, and check which ones have a version compatible with 8.4 or, at the very least, 8.3. That decides your target.
- A copy to test on. Set up the system on the new version in a staging environment, turn on deprecation notices and fix whatever shows up.
- Test what brings in revenue. Sales, payments, invoicing, integrations and scheduled tasks, with someone from your team who uses the system every day.
- Pick the date. Migrate in November or early December, away from the holidays, sales peaks and year-end close, with a backup and a clear rollback plan.
- Put the next jump on the calendar. With 8.4 your runway reaches the end of 2028. Plan the next upgrade ahead of time, not in the last week.
If the system is old or depends on abandoned components, two months may not be enough. In that case, first protect what's exposed, then build a phased plan. We explain how in how to upgrade PHP on unsupported systems.
How we solve it at DCisGlobal
Moving from 8.2 to 8.3 or 8.4 is usually a well-defined project, and we treat it that way: a technology assessment to set the target, a plan with cost per phase, migration in a staging environment and validation with your team before touching production.
If the server needs attention too, we can take it over with managed hosting. And to keep the system from falling behind again, support and maintenance puts PHP upgrades on the calendar.
If the migration cannot happen right away, we install an extended-support patch so the system stays protected in the meantime.
Further reading
- PHP 8.3 end of life: dates, risks and how to migrate.
- PHP 8.1 end of life: why PHP 8.3 is the next step.
- Upgrading PHP: the risk of running an unsupported system.
- PHP2Shell: what the critical PHP flaw is and what to do now.
- PHP 8.0: vulnerabilities and end of life.
- PHP 7.4: end of life and how to upgrade.
