End of PHP 8.2 support: migrate to PHP 8.4 or 8.5 before 2027

PHP 8.2 support ends on 31 December 2026: from that date, the PHP project will no longer fix any vulnerabilities. If your Symfony, Laravel, WordPress, Drupal or PrestaShop applications still run on 8.2, here is the version to target, the compatibility points to check, the tools to use and a tested migration method, with the FrankenPHP option.

PHP 8.2: what happens on 31 December 2026

Each PHP branch gets two years of active support, then two years of security fixes only. For PHP 8.2, released on 8 December 2022, active support ended on 31 December 2024 and security fixes stop on 31 December 2026, according to php.net. As of 19 September 2026, the latest release is 8.2.33, from 30 July 2026.

The PHP 8.6 schedule provides for four release candidates between 24 September and 5 November 2026. At the time of publication, 8.6 is therefore not yet stable.

Why staying on an end-of-life version is a risk

Security. A vulnerability found in 2027 in the PHP engine or a standard extension will not be fixed in 8.2. Your exposure depends on your code, but you lose the simplest lever: applying a fix.

Dependencies. Frameworks and libraries drop end-of-life PHP versions. Staying on 8.2 means eventually condemning yourself to dependency versions that no longer receive fixes themselves.

Compliance. The Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers of products with digital elements to handle vulnerabilities in their components, including open source ones, throughout the support period. Its reporting obligations have applied since 11 September 2026, the rest from 11 December 2027 (European Commission). A software vendor shipping software built on a runtime with no fixes will struggle to meet these commitments; we detail these obligations in our article on the Cyber Resilience Act. For a custom website or application, what mainly applies is the general obligation to secure personal data (Article 32 of the GDPR).

Contracts. If you are a service provider, check your application maintenance (TMA) contracts: a “security maintenance” commitment is hard to honour on a platform that nobody fixes any more. It is better to plan the upgrade than to discover it during a customer audit.

Which version to target: 8.4 or 8.5?

Our rule: target the most recent version that all your dependencies officially support. Jumping straight from 8.2 to 8.4 or 8.5 works perfectly well; there is no need to go through each intermediate version in production.

Framework and CMS compatibility

Sources: Symfony, Laravel, WordPress, Drupal, PrestaShop.

Two cases deserve particular attention. Laravel 11 combines two end-of-life dates: the framework’s and, soon, PHP 8.2’s. Drupal 10 reaches end of life on 9 December 2026, three weeks before PHP 8.2: migrating to Drupal 11 and PHP 8.3 minimum is one and the same project. For WordPress, the core keeps up; it is the plugins and themes that decide.

What breaks in practice

To 8.3: few breaking changes. The new features (typed class constants, json_validate()) are optional.

To 8.4 (official list):

• implicitly nullable parameters (string $x = null) are deprecated: write ?string $x = null instead;
• exit() and die() behave like functions and throw a TypeError on an invalid type;
• the E_STRICT constant is deprecated;
• the IMAP, OCI8, PDO_OCI and pspell extensions are no longer bundled with PHP and move to PECL: a blocking point for applications that read mailboxes over IMAP;
• many functions now throw ValueError or TypeError on invalid arguments.

To 8.5 (deprecations): the backtick operator, non-canonical cast names ((integer), (boolean)), case terminated by a semicolon, null as an array key, __sleep() and __wakeup(), curl_close() and imagedestroy(), among others. Deprecations, not errors: they will break in PHP 9, not now.

Migration tools

To simulate dependency resolution on the target version without changing machine, declare the platform in a dedicated branch:

composer config platform.php 8.4.0
composer update --dry-run
composer why-not php 8.4

Each package flagged must be updated, replaced or, as a last resort, forked. This is often where the real cost of the migration hides.

Minimal Rector configuration:

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

return RectorConfig::configure()
    ->withPaths([__DIR__ . '/src', __DIR__ . '/tests'])
    ->withPhpSets(php84: true);

Start by running vendor/bin/rector process --dry-run, review the diff, then apply in batches. For PHPStan:

parameters:
    level: 6
    paths: [src, tests]
    phpVersion: 80400

Step-by-step migration method

• Take inventory. PHP versions per environment, loaded extensions (php -m), Composer dependencies, CMS modules and extensions, scheduled tasks, workers. This is the first step of a migration audit.
• Choose the target with the compatibility table, dependency by dependency.
• Add the target to the CI without blocking: a matrix that tests the current version and the target.

strategy:
  matrix:
    php: ['8.2', '8.4']
steps:
  - uses: actions/checkout@v4
  - uses: shivammathur/setup-php@v2
    with:
      php-version: ${{ matrix.php }}
  - run: composer install --no-progress
  - run: vendor/bin/phpunit

• Log deprecations in pre-production (error_reporting = E_ALL, dedicated channel: LOG_DEPRECATIONS_CHANNEL on Laravel, Monolog’s deprecation channel on Symfony).
• Update the blocking dependencies, then run Rector and PHPStan.
• Test following the plan below.
• Switch over gradually: one instance or site first, watch errors and performance, then roll out. Keep the old image ready for a quick rollback.
• Clean up: remove 8.2 from the CI, update the documentation and the maintenance contract.

FrankenPHP: change runtime during the migration?

FrankenPHP is a PHP application server written in Go, built on Caddy; its repository is hosted in the PHP project’s GitHub organisation. Its worker mode loads the application once and keeps it in memory between requests.

In the EXP-02 sheet of the iones lab, we developed the same orders API (6 endpoints, 2 million PostgreSQL rows, 4 vCPUs) in four languages. Results that are useful for deciding:

An honest reading: the worker-mode gain is real when application start-up is heavy; it disappears when the database is the bottleneck. Our decision after EXP-02: FrankenPHP for new PHP projects and for migrations from PHP-FPM.

Implementation with Symfony 7.4 or later, which natively supports worker mode:

docker run -e FRANKENPHP_CONFIG="worker ./public/index.php" \
  -v $PWD:/app -p 80:80 -p 443:443 -p 443:443/udp dunglas/frankenphp

With Laravel, via Octane: composer require laravel/octane, then php artisan octane:install --server=frankenphp. Octane restarts each worker after 500 requests by default, adjustable with --max-requests.

Two pitfalls: shared state (static properties, singletons that keep the previous request or user) and memory leaks, hidden until now by PHP-FPM. Do the version migration first and the runtime change afterwards: two changes at once make diagnosis harder.

Test plan

Frequently asked questions

PHP 8.2 at end of life: plan the migration now

Less than three months remain before PHP 8.2 support ends. The path is known: inventory, choosing the target according to your dependencies, CI on two versions, Rector and PHPStan, tests of the critical journeys, gradual switchover. Take the opportunity to evaluate FrankenPHP, once the migration has stabilised.

Do you manage a portfolio of PHP applications, directly or for your agency clients? Our team carries out the audit, migration and maintenance, including under white label. Let’s talk about your migration plan: reply within 48 to 72 hours.