PHP Version Upgrades and Compatibility Help
A PHP upgrade moves your site to a newer PHP branch, for example from 8.1 to 8.3. We review what your plugins, theme and code need, test the site on the new version in a copy first, and switch the live site in a planned window, so that the move off an unsupported version does not take checkout, forms or logins down with it.
Looking for the October 2026 security patch rather than a version change? See PHP security updates and vulnerability fixes.
When a PHP upgrade becomes necessary
Four situations that usually start the conversation.
Your PHP branch is out of support
PHP 8.1 and older get no releases from the PHP project. PHP 8.2 stops receiving security fixes after December 31, 2026.
Your host is retiring a version
Hosts remove old PHP versions from their control panels on their own schedules, sometimes with short notice.
A plugin or framework needs a newer PHP
Newer releases of WordPress plugins, WooCommerce extensions and PHP frameworks raise their minimum PHP version.
A security fix exists only on newer branches
When a vulnerability is fixed upstream only on supported branches, staying put depends on a vendor backport being available.
Supported PHP versions
The PHP project supports four branches. These dates come from php.net’s supported versions page, checked .
| Branch | Support | October 2026 security release |
|---|---|---|
| PHP 8.5 | Active support until Dec 31, 2027; security fixes until Dec 31, 2029 | 8.5.12 |
| PHP 8.4 | Active support until Dec 31, 2026; security fixes until Dec 31, 2028 | 8.4.27 |
| PHP 8.3 | Security fixes only, until Dec 31, 2027 | 8.3.36 |
| PHP 8.2 | Security fixes only, until Dec 31, 2026 (end of life after that) | 8.2.35 |
| PHP 8.1 and older | No longer supported by the PHP project | No upstream release; vendor backports only |
PHP 8.1 and older no longer receive releases from the PHP project. The PHP security team published minimal source backports for 7.4, 8.0 and 8.1 for people who build PHP themselves; distributions and long-term-support vendors may ship their own backported packages.
What tends to break, and why
Each PHP branch removes or changes some behavior. The PHP manual publishes a migration guide for every version, and these are the categories that usually matter for business sites.
Removed or changed functions
Code calling a function that a newer PHP removed stops with a fatal error. PHP lists these changes in its official migration guides.
Stricter type and error handling
Situations older PHP tolerated with a warning can become errors, which shows up as blank pages or failed form submissions.
Deprecation notices
Not failures yet, but they flood logs and sometimes appear on screen if error display is on.
Abandoned plugins and libraries
Code nobody maintains is the most common blocker. It needs a replacement, a patch or a decision.
Extensions not available for the new version
A PHP extension your code depends on may not be installed or built for the target version on your host.
On WordPress, see how WordPress, plugins and PHP versions relate. If an application cannot move yet, the planning guide compares options for older applications.
How an upgrade proceeds
The live site does not change until the staging test passes and you agree the window.
Step 1: Inventory
Current PHP branch and build, host, control panel, extensions in use, and every plugin, theme, library and custom module.
Step 2: Compatibility review
Static compatibility checks against the target version, a read of the official migration notes, and each plugin’s stated PHP support.
Step 3: Staging test
The site runs on the target PHP in a copy, where errors and deprecations are logged and the agreed business checks are run.
Step 4: Fixes
Update, replace or patch whatever failed. Anything that needs a decision, such as dropping a plugin, comes back to you first.
Step 5: Planned cutover
Backup confirmed, change window agreed, version switched, PHP workers restarted, checks repeated on the live site.
Step 6: Written summary
Before and after versions, what changed, what was tested, and anything left to watch.
Timing depends on the version gap, the number of plugins and custom modules, and how quickly staging and hosting access can be arranged. We give a plan after the inventory. We do not promise zero downtime.
Start with the inventory.
Request PHP Security HelpWhat you receive
- An inventory of the PHP build, extensions, plugins, themes and custom code
- A compatibility findings list with the fix or decision for each item
- Staging test results, including the business checks we agreed
- The live cutover in an agreed window, with workers restarted and checks repeated
- A written summary of before and after versions and anything still open
Quoted separately when needed: a full conversion to custom code, hosting migrations and ongoing monitoring. If the application would be better rebuilt than upgraded, we say so in the findings; see how we migrate sites to custom code.
Common questions
Which PHP version should we move to?
Usually the newest branch your host offers that all your plugins, themes and code support, and at least one that still receives security fixes. As of October 2026 that means PHP 8.3, 8.4 or 8.5; 8.2 is supported only until December 31, 2026. The compatibility review tells us which one is realistic for your site.
Is a security patch the same as a PHP upgrade?
No. A security patch moves you to a fixed build within the same branch, for example from an older 8.3 build to 8.3.36. An upgrade moves you to a different branch, for example from 8.1 to 8.3. Upgrades change language behavior and need more compatibility work. For the October 2026 vulnerabilities, see the PHP security update service.
Our host offers an older PHP version that still works. Can we stay on it?
Only if someone is still shipping security fixes for it. Some Linux distributions and long-term-support vendors backport fixes to older branches, so an old version number is not automatically unpatched. Ask your host who maintains the build and whether it includes current fixes. If nobody does, plan the upgrade.
Can you upgrade a custom application, not just WordPress?
Yes. Custom applications take more review because there is no plugin directory listing compatibility. We review the code and its dependencies, test in a copy and set out the fixes. If parts of the application need rewriting, we say so and scope that separately.
What if the upgrade breaks something on the live site?
The staging test is there so that is rare, and the backup and change plan cover it if it happens. Switching back to an older PHP version is a short-term fallback only when that version is still patched. If it is not, the safer route is to fix the failure while access to the site is restricted.
How is pricing determined?
By the size of the version gap, how many plugins, themes and custom modules are involved, how many sites, and how much testing your business functions need. We quote after the inventory and before any change.
Planning a move off an old PHP version?
Tell us the site, the current PHP version if you know it, and any deadline from your host. We will review the scope and discuss the next step.
Prefer to talk first? Book a Free Call, or phone (530) 553-8883.