PHP 8.2 end of life (31 December 2026): what breaks and what to do

If your application runs on PHP 8.2, official security support ends on 31 December 2026. "End of life" means the PHP project stops releasing new 8.2 versions, so security holes found after that date are not fixed in official PHP 8.2 releases. This affects any app on PHP 8.2: Laravel and Symfony projects, WordPress sites, and custom PHP code. The dates come from php.net's supported versions page.

What changes on the date (and what doesn't)

PHP 8.2 has been in security-only mode since 31 December 2024. On 31 December 2026 even those fixes stop.

What does not change:

• Your servers keep running. Nothing is switched off, and PHP 8.2 binaries keep working.
• Some operating systems and vendors keep patching their own PHP builds. Debian 12 ships PHP 8.2 as its system PHP, and Debian's security and LTS teams backport fixes to the packages they cover. Ubuntu Pro (ESM) does the same for the PHP versions Ubuntu ships, and commercial vendors such as HeroDevs sell extended support for older runtimes. These options exist; whether they fit depends on how you install PHP and whether you want to pay for them.

What does change:

• Official PHP 8.2 releases stop, so if you use the official Docker images or build from source, you get no more fixes.
• Composer packages drop PHP 8.2 support over time. New versions of your dependencies may require PHP 8.3 or newer.
• Security scans and compliance checklists (PCI DSS, SOC 2, client security reviews) often flag unsupported runtimes.

Which versions to move to

Version	Security support until	Notes
PHP 8.2	31 Dec 2026	Ends this year
PHP 8.3	31 Dec 2027	Buys one year
PHP 8.4	31 Dec 2028	Good default target
PHP 8.5	31 Dec 2029	Latest; check your packages support it

Source: php.net supported versions, cross-checked with endoflife.date/php.

I usually recommend PHP 8.4. It gives two more years of support, and most maintained packages already allow it. Go to PHP 8.5 if all your dependencies support it, so you don't face this again in 2028.

How to check what you run

Check the version in each place where PHP runs: the server, the Docker image, CI and local machines. They often differ.

# On the server or in the container
php -v

# Version used by the web server (PHP-FPM may differ from the CLI)
php-fpm -v    # or php-fpm8.2 -v on Debian/Ubuntu

# Which PHP your composer.json allows
grep -A3 '"require"' composer.json      # look for "php": "^8.2"
grep -A3 '"platform"' composer.json     # config.platform.php pins the version Composer resolves for

# Docker base image
grep -i '^FROM' Dockerfile              # e.g. FROM php:8.2-fpm

# CI images and matrices
grep -rn "php-version\|php:8" .github/ .gitlab-ci.yml 2>/dev/null

To see which packages block a newer PHP version, ask Composer:

composer why-not php 8.4

For a quick check without running anything, paste your composer.json or Dockerfile into the free stack health check. It runs in your browser and shows which runtimes and frameworks are past or near end of life.

Upgrade checklist

1. Inventory. List every app, server, container image, cron job and CI pipeline that runs PHP. Note the PHP version, framework version and PHP extensions each one uses (php -m).
2. Tests first. Run your test suite on PHP 8.2 and make it green. If there are few tests, add a small set covering the flows that make money: login, checkout, the main forms. Without them, you can't tell whether the upgrade broke something.
3. Turn on deprecation reporting. Run the tests and staging with error_reporting=E_ALL and read the log. Deprecations are the list of things to fix before they turn into errors in a later version.
4. Fix the deprecations for your target version:
   • PHP 8.3 (list): ++/-- on empty or non-numeric strings, calling get_class() or get_parent_class() with no arguments, assert_options(), one-argument ReflectionProperty::setValue().
   • PHP 8.4 (list): implicitly nullable parameters (function f(Foo $x = null) must become ?Foo $x = null), the E_STRICT constant, trigger_error() with E_USER_ERROR, mysqli_ping(), mysqli_kill() and mysqli_refresh(), several session.* settings such as session.sid_length and session.use_trans_sid, and lcg_value().
   • PHP 8.5 (list): the backtick shell operator, cast names like (integer) and (boolean), null as an array offset, and case labels ending in ;.
   • Rector can apply many of these changes automatically, including the explicit nullable fix. Review its diff like any other code.
5. Check removed extensions. PHP 8.4 moved IMAP, OCI8, PDO_OCI and PSpell out of core to PECL. If you use imap_* functions to read mailboxes, or connect to Oracle, you need to install those from PECL or replace them.
6. Update dependencies. Change "php" in composer.json (and config.platform.php, if set), run composer update, and upgrade or replace any package that does not allow the new version. Abandoned packages are the slowest part of most upgrades.
7. Framework notes. Laravel 13 requires PHP 8.3 or newer; Laravel 12 supports PHP 8.2 to 8.5 and gets security fixes until 24 February 2027. If you're on Laravel 12 or older, plan the Laravel upgrade alongside the PHP one. For WordPress, check every plugin and theme against the new PHP version on staging.
8. CI matrix. Run the tests on the current and target PHP versions until the switch, then drop 8.2.
9. Staging. Deploy to a staging server with the same PHP build, extensions and php.ini as production. Test queues, cron jobs, file uploads, email and payment webhooks, not just the pages.
10. Deploy with a rollback. Build a new server or image with the new PHP, switch traffic, and keep the old one ready to switch back. Watch error logs for a few days.

Common breakages

• Implicitly nullable parameters. public function handle(Request $request = null) gives a deprecation notice on PHP 8.4. It still runs, but noisy logs hide real errors, and some test setups fail on deprecations.
• IMAP and Oracle code. Code calling imap_open() fails with "Call to undefined function" on a stock PHP 8.4 image, because the extension is no longer bundled.
• Stricter built-in functions. On PHP 8.3, range() throws ValueError for a step of 0 and changed its result for some string arguments (PHP 8.3 incompatible changes). On PHP 8.4, round() throws for an invalid mode, and exit() with an invalid type throws TypeError (PHP 8.4 incompatible changes).
• PDO boolean attributes. On PHP 8.4, some PDO MySQL attributes such as ATTR_EMULATE_PREPARES now return bool instead of int. Strict comparisons against 1 stop matching.
• Composer conflicts. composer update refuses to resolve because one old package pins "php": "~8.2.0" or depends on a library that does.
• Dynamic properties. Deprecated since PHP 8.2 and still reported. Older code that sets undeclared properties on objects fills the logs until you declare the properties or add #[\AllowDynamicProperties].
• Config drift. The new server has different php.ini values (memory limit, upload size, OPcache) or is missing an extension like intl or gd, and something fails that tests never touch.

Cost and timeline

The honest answer is that it depends on two things: how much test coverage you have and how old your dependencies are. A small Laravel app with tests and maintained packages can move from PHP 8.2 to 8.4 in a few days. An app with no tests, abandoned packages, or IMAP or Oracle code takes longer, because each of those needs its own fix and its own check.

Start now rather than in late December. It leaves time for staging, for waiting on a package maintainer, and for a calm rollback if something goes wrong.

I do this as a fixed-price service: the End-of-Life Runtime Upgrade starts from $390 for one runtime, and the Laravel Upgrade starts from $390 for one version hop with tests. If you don't know how much work is hidden in the codebase, a codebase assessment gives you a written answer before you commit.

If PHP 8.2 is in your stack, send me your versions and I'll tell you what the move involves.