PHP 8.2 reaches end of life on December 31, 2026. After that date the PHP project publishes no more releases for the 8.2 branch, including fixes for security vulnerabilities. For a shared hosting provider or anyone running several sites, the target is not "the latest version" but a supported version your tenants' code actually runs on. In practice that means PHP 8.4, supported until the end of 2028, for most migrations. PHP 8.5, supported until the end of 2029, suits code that is already clean. The move should be planned as a staged, per-site migration starting in October, not a single switch on December 30.

The date also coincides with two other events that shape the plan. PHP 8.4 leaves active support on the same day and moves to security-only fixes. PHP 8.6 is scheduled for general availability on November 19, 2026, and was at its second release candidate in late September. The fourth quarter is therefore when hosts set their version policy for 2027.

The dates that actually matter

Since a 2024 policy change, each PHP branch receives two years of active support followed by two years of security-only fixes, with every phase ending on December 31. The current calendar, from the official php.net support page:

BranchReleasedActive support endsSecurity support ends8.2Dec 8, 2022Dec 31, 2024Dec 31, 20268.3Nov 23, 2023Dec 31, 2025Dec 31, 20278.4Nov 21, 2024Dec 31, 2026Dec 31, 20288.5Nov 20, 2025Dec 31, 2027Dec 31, 20298.6Scheduled Nov 19, 2026——

Two things follow from this table. First, migrating from 8.2 to 8.3 only buys twelve months: 8.3 reaches end of life at the end of 2027, and you would repeat the whole exercise next year. Second, 8.4 is the stable middle ground. It has been in production for almost two years, most frameworks, CMSs and extensions support it, and it is covered by security fixes for two more years. 8.5 gives an extra year of runway at the cost of slightly less ecosystem maturity. 8.6 should not be a production default until it has had a few point releases.

Upstream EOL is not the whole story on Debian and Ubuntu

This is the part most EOL coverage skips, and it changes the risk calculation for many servers.

The php.net date applies to PHP as distributed by the PHP project. Linux distributions often maintain their own packaged PHP versions longer by backporting security fixes. Debian 12 (bookworm) ships PHP 8.2 as its default version. Debian's long-term support effort continues to cover packages in bookworm after its regular security support ended in mid-2026, into 2028, and the packaged php8.2 receives backported fixes during that time where the LTS team supports the package. In the same way, Ubuntu maintains the PHP versions shipped in its LTS releases for those releases' support periods.

This leads to three very different situations that are often confused:

1. A distribution's own PHP package (for example php8.2 from Debian 12's standard repositories) continues to receive security backports from the distribution after upstream end of life. The server is not unpatched on January 1, as long as you install distribution updates and the package stays within the distribution's supported scope.

2. PHP from a third-party repository, the common route for running several PHP versions on one server, depends entirely on that repository's policy for EOL branches. Check what your repository provider publishes for branches past upstream EOL. Do not assume updates continue.

3. PHP compiled from source, or bundled with a control panel, stops receiving fixes on December 31 unless you maintain it yourself.

Most multi-version hosting setups fall into the second or third category. Even distribution-backported 8.2 carries a practical cost. Frameworks, CMS plugins and Composer packages drop support for EOL PHP versions on their own timelines, so a "patched" PHP 8.2 gradually turns into a platform on which current application code can no longer be installed. Backports buy time. They do not remove the migration.

Step one, find out who is actually on 8.2

On a multi-tenant server, the first task is inventory. With per-site PHP-FPM pools behind Apache, the PHP version of each vhost is usually visible in its handler configuration:

bash

# Vhosts routed to a PHP 8.2 FPM socket (Debian/Ubuntu layout)
grep -rl "php8.2-fpm" /etc/apache2/sites-enabled/

# FPM pools defined for 8.2
ls /etc/php/8.2/fpm/pool.d/

Paths vary by distribution and control panel, but the principle is the same everywhere: map each site to its FPM pool, and each pool to its PHP version. Also check CLI usage, which is easy to forget. Cron jobs and deployment scripts often call a specific binary such as /usr/bin/php8.2 directly. They keep running after a site's web handler has moved, and they break when the old version is finally removed.

For each site on 8.2, record three things: the application and its version (a WordPress core release, a Laravel major version, a custom codebase), the loaded PHP extensions it depends on, and the owner to contact. These determine the effort far more than the PHP version jump itself.

What breaks between 8.2 and 8.4 or 8.5

Upgrading PHP is rarely about new features. It is about deprecations that turn into warnings in logs, removed functionality and unbundled extensions. The changes that most often affect hosting tenants:

Implicitly nullable parameter types are deprecated in PHP 8.4. A signature like function save(Model $model = null) now emits a deprecation. The fix is an explicit nullable type, ?Model $model = null. The deprecation does not break execution, but older plugins and libraries contain huge numbers of such signatures. On sites that display errors, the flood of deprecation notices can break pages or fill logs. Production sites should log errors, not display them, and this is a good moment to check that.

Several extensions were unbundled in PHP 8.4. IMAP, Pspell, OCI8 and PDO_OCI were removed from the PHP core distribution and moved to PECL. IMAP matters most for hosting: webmail clients, ticketing systems and applications that read mailboxes often use it. If a tenant needs it, it has to be installed separately. Check the extension list of every 8.2 site before switching.

PHP 8.5 changes two things that directly concern hosting operators. The disable_classes INI directive has been removed. If your hardening relied on it, it no longer works in 8.5, and your security review must use other mechanisms: pool isolation, open_basedir where appropriate, and disable_functions. PHP 8.5 also adds a max_memory_limit INI directive that caps how high scripts can raise memory_limit at runtime. It is useful for a shared host that wants to allow tenants some flexibility without letting one script take all the memory. PHP 8.5 also introduces a new batch of deprecations, including the backtick operator as an alias of shell_exec() and the non-canonical cast names such as (boolean) and (integer).

The authoritative source for everything else is the official migration guide for each version between your source and target. Moving from 8.2 to 8.4 means reading both the 8.3 and 8.4 guides. Moving to 8.5 adds a third.

Scan code before switching versions

For custom code and themes, static analysis finds most problems before any tenant sees an error.

PHP_CodeSniffer with the PHPCompatibility standard checks code against a target PHP version range. Check that the version of the standard you install covers your target PHP version, since support for the newest releases lags behind them:

bash

composer require --dev squizlabs/php_codesniffer phpcompatibility/php-compatibility
vendor/bin/phpcs -p src/ --standard=PHPCompatibility --runtime-set testVersion 8.4-

Rector goes further and can rewrite code automatically, for example turning implicit nullable parameters into explicit ones:

php

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

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

Run it with vendor/bin/rector process --dry-run first, review the diff, and only then apply the changes. Automated rewrites of application code need the same review as any other change.

For Composer projects, also update the platform setting in composer.json so that dependency resolution targets the new version, and run composer update in a staging environment. A package that does not yet support the target PHP version will block resolution there rather than failing in production.

For third-party CMS installations, static scanning of the plugin directory is less useful than checking each plugin's declared compatibility and changelog. Old, abandoned plugins are the main source of failures, and they are also the main security risk.

Run old and new side by side, then move site by site

The safest migration switches one site at a time, with the ability to switch back. On Apache with PHP-FPM, that means running both versions side by side and changing each vhost's handler individually:

apache

<VirtualHost *:443>
    ServerName example.com
    DocumentRoot /var/www/example.com/public

    <FilesMatch \.php$>
        SetHandler "proxy:unix:/run/php/php8.4-fpm-example.sock|fcgi://localhost"
    </FilesMatch>
</VirtualHost>

Each site gets its own pool, running as its own system user, on the target version. Switching back means pointing the handler at the old socket and reloading Apache, which takes seconds. Keep the 8.2 pool configurations until each site has run cleanly on the new version for a few weeks.

Pool configuration is also something to migrate deliberately rather than copy blindly. Settings such as memory_limit, upload_max_filesize and disable_functions defined per pool or per site must be moved to the new version's pool files. Missing a customised setting is a classic source of "the upgrade broke my uploads" tickets.

A realistic order for a multi-tenant server:

1. October: inventory, notify tenants, deploy the target version alongside 8.2, and move your own internal sites first.

2. Early November: move sites that passed scanning with no issues, in small batches, watching error logs for the first 24–48 hours after each batch.

3. Late November and December: handle the sites that needed code changes, and set a firm date after which remaining 8.2 sites are switched by default, with clear notice.

4. After the switch: keep 8.2 installed but unused for a short rollback window, then remove it.

Telling tenants, and what not to promise

Tenants mostly need to know three things: the date, what might break, and what they have to do. The last point is the one that is usually missing. "Your site will be moved to PHP 8.4" is less useful than "your site uses plugin X, whose installed version does not support PHP 8.4; update it before November 15".

Two warnings. First, do not promise that the upgrade is invisible. Deprecation-heavy code and missing extensions will surface somewhere. Second, do not offer indefinite extensions on 8.2 without being honest about what it means. Some hosts sell paid "extended support" for EOL PHP versions. That can be a legitimate bridge if the underlying binaries really receive backported security fixes. It is a false sense of security if they don't.

AI-generated code and the version question

A growing share of the sites on shared hosting now includes code written with AI assistants: small plugins, custom forms, integration scripts. In a PHP migration, this code has a specific weakness. Models trained on years of PHP code can reproduce patterns that were normal in older versions, such as implicitly nullable parameters or dynamic properties on classes, deprecated since PHP 8.2. The code works when it is written and then produces deprecations or failures on the next version. Scan it like any other custom code. When a tenant asks an assistant to fix a compatibility problem, it helps to state the target PHP version explicitly in the prompt.

After December 31

Once 8.2 is gone from the servers, the same cycle begins again. PHP 8.3 reaches end of life on December 31, 2027. Hosts that settle on 8.4 in this migration will face their next deadline at the end of 2028, and those that move to 8.5 at the end of 2029. The inventory scripts, scanning pipeline and side-by-side pool layout built for this migration are what make the next one routine rather than urgent.