PHP 8.2 End of Life: What UK Businesses and Agencies Need to Do Before 31 December 2026

What “end of life” actually means

Every PHP version gets two years of active support (bug and security fixes) followed by two years of security-only support. When that ends, the PHP project stops releasing fixes for that version altogether.

PHP 8.2 was released in December 2022. Its active support ended on 31 December 2024, and its security support ends on 31 December 2026. After that date, any newly discovered vulnerability in PHP 8.2 stays unfixed in official releases.

Source: the official PHP supported versions page.

Why it matters for UK businesses and agencies

• Security. PHP runs directly on the internet-facing side of your application. An unpatched runtime is one of the first things attackers and automated scanners look for.
• Compliance. Cyber Essentials requires software to be supported and receiving security updates. PCI DSS requires known vulnerabilities to be patched. Client security questionnaires increasingly ask which PHP version you run.
• Hosting pressure. Managed hosts and control panels routinely retire end-of-life versions or charge for extended support. A forced upgrade on the host’s timetable, not yours, is how untested sites break.
• Dependencies moving on. Frameworks and Composer packages drop old PHP versions in new releases (Symfony 8 already requires PHP 8.4). Staying on 8.2 means you gradually stop receiving their security fixes too.

For agencies, the risk multiplies: a dozen client sites on PHP 8.2 means a dozen upgrades landing in the same quarter, usually on top of the pre-Christmas rush.

First, check what you’re really running

Don’t trust a single php -v. The command line and the web server often run different PHP versions, and a server can have several versions installed side by side.

# The CLI and the web server can run different PHP versions: check both
php -v
ls /run/php/                 # PHP-FPM sockets, e.g. php8.2-fpm.sock

You can also check your hosting control panel, or temporarily create a page that calls phpinfo() (and delete it straight afterwards).

What breaks between PHP 8.2 and PHP 8.5

The good news: PHP 8.2 to 8.5 is a much smaller jump than PHP 7.x to 8.x. Most changes are deprecations, which log warnings but keep working. They still matter, because deprecations become errors in the next major version, and noisy logs hide real problems.

PHP 8.3

Very few breaking changes. It adds typed class constants, json_validate() and the #[\Override] attribute. Calling get_class() or get_parent_class() without arguments is deprecated.

PHP 8.4

The change you’re most likely to hit: implicitly nullable parameters are deprecated. It’s extremely common in older code, and Rector fixes it automatically:

// Deprecated since PHP 8.4: implicitly nullable parameter
function send(Message $message = null) { /* ... */ }

// Fixed: make the null explicit
function send(?Message $message = null) { /* ... */ }

Also in 8.4:

• The IMAP, OCI8, PDO_OCI and Pspell extensions were removed from PHP core and moved to PECL. If your app reads mailboxes with imap_* functions or talks to Oracle, plan for this early.
• The E_STRICT constant and calling trigger_error() with E_USER_ERROR are deprecated.
• The session.sid_length and session.sid_bits_per_character settings are deprecated.

PHP 8.5

• The backtick operator (`ls -la` as a shortcut for shell_exec()) is deprecated.
• Non-standard cast names such as (integer), (boolean), (double) and (binary) are deprecated. Use (int), (bool), (float) and (string).
• Ending a case statement with a semicolon instead of a colon is deprecated.

On the plus side, 8.5 brings the pipe operator (|>), array_first() and array_last(), the #[\NoDiscard] attribute and a new standards-compliant URI extension.

Where upgrades really go wrong

In our experience it’s rarely PHP itself. It’s the things around it:

• Dependencies pinned to old versions, or abandoned packages that will never support PHP 8.5
• Removed extensions that only surface when a rarely used feature runs
• WordPress plugins and themes that are no longer maintained
• No tests, so nobody notices the broken checkout or failed import until a customer does
• Deprecation warnings you already have, such as dynamic properties (deprecated since 8.2), that were ignored and will turn into errors later

A practical upgrade plan

1. Inventory everything

List every application and site, its PHP version, framework and version, hosting, and who owns it. Agencies: include the client sites nobody has touched in years. They’re usually the risky ones.

2. Check your dependencies

Composer can tell you exactly what stands in the way:

# Which packages block PHP 8.5?
composer why-not php 8.5

# What is out of date among your direct dependencies?
composer outdated --direct

Anything abandoned needs a replacement plan now. It’s the part most likely to blow a timeline.

3. Run static analysis against PHP 8.5

PHPStan can analyse your code as if it were running on the target version, before you change anything:

# phpstan.neon
parameters:
    level: 5
    phpVersion: 80500
    paths:
        - src

Then let Rector apply the mechanical changes. Set "php": "^8.5" in composer.json and it picks the right upgrade rules automatically:

<?php
// rector.php
use Rector\Config\RectorConfig;

return RectorConfig::configure()
    ->withPaths([__DIR__ . '/src'])
    ->withPhpSets(); // uses the PHP version in composer.json ("php": "^8.5")

vendor/bin/rector process --dry-run   # review the proposed changes first
vendor/bin/rector process             # then apply them, one commit at a time

Review Rector’s changes in small commits. Automated doesn’t mean unreviewed.

4. Get tests around what matters

If you don’t have tests, don’t try to write a full suite. Write characterisation tests for the critical paths (login, checkout, key forms, APIs, imports and exports) that record what the application does today. Then run them on both versions in CI:

# .github/workflows/tests.yml
jobs:
  tests:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        php: ['8.2', '8.5']
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with:
          php-version: ${{ matrix.php }}
      - run: composer install --no-progress
      - run: vendor/bin/phpunit

5. Stage it, then switch production with a way back

Deploy to a staging environment on PHP 8.5 and compare behaviour and error logs with production. On your own servers, you can install PHP 8.5 alongside 8.2 and switch each site’s PHP-FPM pool individually. Rolling back is then a one-line config change, not an emergency.

A realistic timeline

Frequently asked questions

Will my website stop working on 1 January 2027?

No. PHP 8.2 keeps running after its end-of-life date. What stops is security fixes from the PHP project, so any vulnerability found after that date stays open. In practice, many hosting providers also start moving customers off end-of-life versions, sometimes with little notice, which is when untested sites break.

My Linux distribution still patches PHP 8.2. Am I safe?

Partly. Distributions such as Debian backport security fixes to the PHP version they ship for the life of that distribution release. That buys time, but your Composer dependencies, frameworks and plugins will keep dropping support for PHP 8.2, so you will fall behind on their security fixes instead.

Should I upgrade to PHP 8.4 or PHP 8.5?

For most applications, go straight to PHP 8.5. It receives security support until 31 December 2029, a year longer than 8.4, and the extra work to go from 8.4 to 8.5 is usually small. Only stop at 8.4 if a critical dependency does not support 8.5 yet.

How long does a PHP 8.2 to 8.5 upgrade take?

A small, well-maintained application can take a few days. Large or untested codebases, or ones with abandoned dependencies, can take several weeks. A short audit of your dependencies and a Rector dry run gives a realistic estimate before you commit.