PHP versions: support and safe upgrades

Updating the runtime environment is part of maintaining a project. It helps us receive fixes, stay compatible with libraries and prepare future changes without rushing. The team needs a clear timeline: how long the chosen version will receive support and when another upgrade will be needed.

Start with the official PHP support table. It helps us choose a branch and plan updates. Moving to PHP 8.5 makes sense if the application, dependencies and hosting support it. A supported and tested PHP 8.4 environment can also be a suitable foundation.

What version support means

PHP maintains several branches. Each has its own support period.

• Active support: the PHP project fixes bugs and vulnerabilities and releases updates.
• Security fixes: active support has ended; the branch receives fixes for critical security issues as needed.
• End of life, EOL: the PHP project no longer supports the branch. Plan a migration before continuing to rely on it.

PHP's general policy provides about two years of active support and two more years of security fixes. Check the exact date for the branch in the table. It matters more than an estimate based on the version's age.

The dates were checked against PHP.net on 14 October 2026. Open the source again before choosing a version: this article's table also needs to be kept current.

The 8.4 branch and a specific 8.4.x release are different choices. Support through the end of 2028 applies to the branch. To receive available fixes, install its current releases. An old 8.4.0 installation does not become secure simply because the 8.4 branch is still supported.

Support for PHP 7.4, the last PHP 7 branch, ended on 28 November 2022. Earlier 7.x branches are also no longer supported by the PHP project. An operating-system or hosting provider may offer separate support under its own terms. Do not assume that this extends PHP support without the provider's confirmation.

How we chose PHP 8.4

In 2025, we migrated key projects from PHP 7.x, older CentOS versions and BitrixEnv 7.x to Rocky Linux 9, BitrixEnv 9.x and PHP 8.4. We used the same PHP.net table to choose the branch.

It gave us a clear planning horizon: security fixes for PHP 8.4 are scheduled through 31 December 2028. This helps us distribute the work in advance and prepare the next migration. Updates within the chosen branch are still necessary.

In October 2026, following news of critical PHP vulnerabilities, we promptly moved to PHP 8.5. Security fixes for this branch are scheduled through 31 December 2029.

We will consider the next stable branch, PHP 8.6 or newer, once it is released, if it suits the projects. This is a provisional plan. The final choice will depend on application compatibility, infrastructure support and verification results.

PHP's table defines support dates for PHP. It does not promise support for the whole stack through the same date. Rocky Linux, BitrixEnv, Bitrix, the web server and libraries have their own terms and timelines. We check these separately.

Why keep software current

A supported environment lets us receive fixes and use current documentation. It reduces dependence on old libraries that no longer receive new releases. Delaying updates gradually increases the work required for the next migration: several layers must change together, and the team must resolve accumulated incompatibilities.

A new version alone does not guarantee security or reliability. We also need correct settings, limited permissions, backups and application checks. Scheduled updates must account for the risk of change and the project's criticality.

Readiness means that the required scenarios work after the upgrade. If the site opens but data exchange has stopped, the upgrade is not yet successful.

Where SRE and DevOps help

SRE is engineering work focused on service reliability. For an upgrade, this means clear criteria: what must keep working, which errors are unacceptable and what would make us restore the previous version.

DevOps skills help connect code with its environment: manage settings, repeat builds, check dependencies and release changes in an agreed order. Developers need to understand which PHP serves the site, which extensions the application requires and where to find errors. Infrastructure specialists need the project's important user scenarios and dependencies.

Before upgrading, agree on four things:

1. Environment: versions of PHP, the operating system, application, extensions and libraries.
2. Verification criteria: which user actions and integrations must work.
3. Recovery: who restores the previous environment, where the backup is and how to recover data.
4. Monitoring after release: errors, availability, response time and completion of important operations.

A repeatable release and a tested recovery method help the team manage change. These practices do not require a dedicated SRE or DevOps role. On shared hosting, the provider handles part of the work, so clarify responsibilities in advance.

Find out which PHP is running

On shared hosting, start with the control panel. Check the domain's PHP version and enabled extensions. Ask the provider which settings and logs are available. This does not require access to Bash.

If the team has a terminal on a test server or computer, run:

php -v
php -m

The first command shows the version. The second lists extensions. If several versions are installed, specify the path to the required PHP executable. Command-line PHP and the version serving the site may differ and read different settings. Do not leave a public phpinfo() page online: it reveals environment details.

For a multilingual site, check UTF-8 handling and the required extensions. For example, a Markdown parser may use mbstring when calculating indentation that contains tabs. A missing extension may cause an error in only one material.

Check the code and real scenarios

When moving from PHP 8.3 to 8.5, review the changes in both 8.4 and 8.5. PHP warns that incompatibilities must be checked before changing the version in production.

If a terminal is available, check syntax from the project root:

rg --files -g '*.php' -0 | xargs -0 -n 1 php -l

This command requires rg and xargs. It lists PHP files and checks their syntax with the selected PHP version. It does not run user scenarios. Without console access, use an available test copy and checks the provider can perform.

In the test environment, enable E_ALL and error logging. Display errors only in an environment closed to visitors. Check the project's pages, background processing and integrations. Open RSS and the sitemap too: a PHP warning inside XML can corrupt the document.

Fix deprecated constructs based on the check results. For example, declare nullable parameters explicitly:

function loadTitle(?string $title = null): string
{
    return $title ?? 'Untitled';
}

In PHP 8.5, prefer the standard casts (int), (bool), (float) and (string). Do not use the deprecated alternatives (integer), (boolean), (double) and (binary) in new code. Do not hide warnings with @; find the cause and check the change with real input data.

Preserve protection and prepare rollback

Strict types do not replace input validation and escaping. A URL parameter can be an array instead of a string. Check its type, then find the record in the known catalogue. Do not pass a user-supplied path to include.

For text in HTML, specify the encoding:

function escapeHtml(string $text): string
{
    return htmlspecialchars($text, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
}

JSON, URLs and other contexts need their own encoding methods. Process Markdown containing third-party HTML in safe mode.

Back up files, settings and data if the project uses a database. Test recovery on a test copy. After an operating-system or data-structure update, restoring files may not be enough. Agree on the rollback method beforehand.

After release, repeat the key scenarios and check the error log. Disable error display for visitors. A run under the chosen PHP version confirms compatibility; reliability also depends on the service working and being recoverable after a failure.

Sources

• PHP: branch support dates.
• PHP: end-of-life branches.
• Migrating to PHP 8.4.
• Migrating to PHP 8.5.
• PHP command-line options.
• Errors and security.
• HTML escaping.
• Google SRE: repeatable software releases.
• PSR-12 coding style.

The migrations to PHP 8.4 in 2025 and to PHP 8.5 in 2026, and the plan for the next branch, reflect our team's experience. The checks and recommendations in the later sections are guidance, not a record of steps performed during those migrations.