PHP 8.2 End of Life: Your Upgrade Plan Before 2027

· PHP, Development

Table of contents

PHP 8.2 reaches its end of life on December 31, 2026. After that date, the PHP project ships no more releases for the 8.2 branch, security fixes included. That gives you about two months. The October php2shell security release was a good reminder of what that means in practice: PHP 8.2.35 got the fix, PHP 8.1 did not. If that had happened in January, 8.2 would have been in the same position. Here is how I'm planning the move for the Laravel and Magento projects I maintain, and which version I'm targeting.

What end of life actually means

According to the official PHP supported versions page, every branch gets two years of active support, then security fixes only. The current timeline:

  • PHP 8.2: released December 8, 2022, security support until December 31, 2026.
  • PHP 8.3: released November 23, 2023, security support until December 31, 2027.
  • PHP 8.4: released November 21, 2024, active support until December 31, 2026, security support until December 31, 2028.
  • PHP 8.5: released November 20, 2025, active support until December 31, 2027, security support until December 31, 2029.

End of life does not mean your site stops working on January 1. It means the next critical vulnerability in the engine will not be fixed upstream. Some Linux distributions backport fixes for their own packaged PHP, so check what your OS vendor promises, but don't build your plan on it. And many hosting providers, PaaS platforms and Docker base images stop offering an EOL branch soon after.

Which version should you target?

My rule: skip straight to the newest version your framework supports, so you don't have to do this again in a year.

  • PHP 8.3 buys you only one more year (EOL end of 2027). I'd use it only if a dependency blocks anything newer.
  • PHP 8.4 is the safe default for most production apps today: security support until the end of 2028, and wide support across frameworks and extensions.
  • PHP 8.5 gives you the longest runway (end of 2029). If your framework and extensions support it, it's the best target. My PHP 8.5 upgrade guide covers what changes.

Laravel and Magento: check your framework first

The framework usually decides for you. From the Laravel support policy:

  • Laravel 11 (PHP 8.2 to 8.4) stopped receiving security fixes on March 12, 2026. If you are still on it, the PHP upgrade is a good moment to move the framework too.
  • Laravel 12 supports PHP 8.2 to 8.5, with security fixes until February 24, 2027.
  • Laravel 13 requires PHP 8.3 minimum and supports up to 8.5.

So moving off PHP 8.2 and upgrading Laravel 12 to 13 fit naturally together: do PHP first, then the framework.

For Magento and Adobe Commerce, the system requirements tie PHP to the release line: 2.4.6 lists PHP 8.1 and 8.2, 2.4.7 lists 8.2 and 8.3, and 2.4.8 lists 8.3 and 8.4. A store on 2.4.6 cannot leave PHP 8.2 without upgrading Magento itself, so that project needs to start now, not in December.

My upgrade checklist

Here is the order I follow, project by project:

  1. Inventory. List every server, container, CI job and cron host with its PHP version. The forgotten worker box is always the one still on 8.2.
  2. Static analysis first. Run Rector and PHPStan against the target version before touching any server:
composer require --dev rector/rector phpstan/phpstan
vendor/bin/rector process --dry-run
vendor/bin/phpstan analyse --level=6
  1. Composer platform check. Set the target version and see what breaks before you install anything:
composer config platform.php 8.4.0
composer update --dry-run
composer why-not php 8.4
  1. Extensions. Make sure every extension you use (redis, imagick, sodium, intl, the one-off PECL ones) exists for the new version in your OS or Docker image.
  2. Run the test suite on the new version in CI, alongside the old one, for a week. Deprecation notices are your to-do list.
  3. Staging, then production. Switch PHP-FPM, then restart queue workers, Horizon and schedulers: long-running processes keep the old binary until they restart.
  4. Remove the platform override in composer.json once production runs the new version, or pin it to the new one.

Plan the next one now

Notice that PHP 8.4 leaves active support on the same day 8.2 dies. Every December, one branch moves to security-only and another one reaches end of life. Put the dates in your calendar, and make "bump the PHP version" a yearly maintenance task instead of a fire drill. Docker makes this easier: the version lives in one FROM line that you can test in a branch.

Conclusion

PHP 8.2 end of life on December 31, 2026 is not a reason to panic, but it is a hard deadline for anything exposed to the internet. Check what your framework supports, target PHP 8.4 or 8.5, run Rector and your tests against it now, and roll it out before the holiday freeze. Two months is plenty for a Laravel app. For a Magento store still on 2.4.6, it's tight, so start this week.

© 2026 Addeos