What PHP 8.2 end of life means in practice
Every PHP version follows a two-phase lifecycle: two years of active support (bug and security fixes), then two years of security-only support — four years total per version. PHP 8.2, released in November 2022, ended active support on December 31, 2024. Since January 1, 2025, only critical security patches have been published. On December 31, 2026, even that coverage stops. Vulnerabilities discovered after that date in the PHP 8.2 engine will receive no official patch. Your servers will keep running code, but with no safety net. CVEs published after the EOL date will remain exploitable indefinitely on unmigrated installations. This is the difference between a maintained runtime and an abandoned one — and the difference is invisible in your logs until an attack occurs.
Concrete risks after December 31, 2026
- Unpatched zero-day vulnerabilities — any vulnerability discovered in PHP 8.2 after EOL will remain exploitable indefinitely; attackers track these deadlines and wait.
- Growing framework incompatibility — Laravel 13 (Q1 2026) requires PHP 8.3 as a minimum and officially drops PHP 8.2; projects that have not migrated will be unable to upgrade the framework.
- Composer package pressure — package maintainers progressively stop declaring PHP 8.2 compatibility in their composer.json, causing blocks during dependency updates.
- Removal by hosting providers — some managed panels and hosting providers remove PHP 8.2 from active environments, forcing an unplanned emergency migration.
- Compliance audit risk — ISO 27001, PCI-DSS and SOC 2 frameworks flag the use of EOL runtimes as an unacceptable gap; an unmaintained version can block a certification.
- Loss of WordPress support — WordPress recommends PHP 8.3 as the minimum version in 2026; premium plugins progressively condition their support on PHP 8.3 or higher.
- Progressive behavioral divergence — PHP 8.3 and 8.4 correct internal behaviors and improve error messages; staying on 8.2 means missing these corrections and widening the gap with your team's development environments.
Inventorying your stack — mapping PHP 8.2 sites
The first challenge for an agency is not technical, it is cartographic. Before any migration, you need to know exactly how many sites are running on PHP 8.2 and under what server configuration. An incomplete inventory leads to forgotten sites that remain exposed after the EOL date. On each VPS, run php -v per virtual host or consult a temporary phpinfo.php file — delete it immediately after use. On cPanel or Plesk servers, the admin interface exposes the PHP version per domain. List each site in a spreadsheet with the following columns: domain, active PHP version, CMS or framework, CMS version, date of last dependency update, and criticality level (e-commerce, brochure, intranet). This map is the prerequisite for any planning: without it, you cannot prioritize or estimate the migration workload.
PHP 8.2, 8.3 and 8.4 — lifecycle, EOL and key features
Scroll the table
| Criteria | PHP 8.2 | PHP 8.3 | PHP 8.4 |
|---|---|---|---|
| Release date | November 2022 | November 2023 | November 21, 2024 |
| Active support end | December 31, 2024 | December 31, 2025 | December 31, 2026 |
| Security support end (EOL) | December 31, 2026 | December 31, 2027 | December 31, 2028 |
| Readonly classes | Yes | Yes | Yes |
| Typed class constants | Yes | Yes | Yes |
| Property hooks | No | No | Yes (major feature) |
| Asymmetric visibility | No | No | Yes |
| json_validate() | Yes | Yes | Yes |
| Laravel 12 compatibility | Yes | Yes | Yes |
| Laravel 13 compatibility | No | Yes | Yes |
| Symfony 7.x compatibility | Yes | Yes | Yes |
| Symfony 8.x compatibility | No | No | Yes (8.4 required) |
Testing compatibility before migrating
Migrating without prior testing is the primary cause of production incidents. Two complementary tools cover the bulk of static analysis. PHPCompatibility is a ruleset for PHP_CodeSniffer: it scans your source code and reports removed function calls, deprecated parameters and behavioral changes between versions. Install it via Composer (composer require --dev phpcompatibility/php-compatibility) and run it with the target --runtime-version=8.3. PHPStan, in turn, performs static type analysis: configured at level 5 or above, it detects dynamic properties (deprecated since PHP 8.2, fatal in 8.4), type incompatibilities and incorrect method signatures. The recommended approach is to run PHPStan first on the current codebase to establish a baseline, then switch the target PHP version to 8.3 or 8.4 in your phpstan.neon to identify gaps. These two static passes do not replace functional tests, but they let you prioritize files to fix before even opening a staging environment.
Migration checklist to PHP 8.3 or 8.4
Map your stack and establish the migration order
List all sites running PHP 8.2 with their CMS, framework and criticality level. Prioritize e-commerce sites and sensitive applications first; static brochure sites can be handled last.
Run static analysis with PHPCompatibility and PHPStan
Run
phpcs --standard=PHPCompatibility --runtime-version=8.3on the source directory. Fix removed function calls and undeclared dynamic properties before moving to the next step.Update Composer dependencies in an isolated environment
In a staging environment with PHP 8.3 or 8.4 active, run
composer updateand resolve version conflicts. Verify that each critical package declares compatibility with the target PHP version in itscomposer.json.Validate with the existing test suite
Run PHPUnit, Pest or end-to-end tests against the target PHP version. If the project lacks automated tests, document the critical paths tested manually (authentication, cart, forms, webhooks).
Update the CMS or framework if needed
WordPress: verify each plugin's compatibility with PHP 8.3. Laravel: if the project is still on Laravel 11, consider upgrading to Laravel 12 at the same time as the PHP migration. Symfony: Symfony 7.4 LTS is compatible with PHP 8.2 through 8.4 without changing the framework.
Switch the PHP version in production
On a VPS with PHP-FPM, update the virtual host nginx pool to point to the php8.3-fpm.sock or php8.4-fpm.sock socket. Reload nginx and PHP-FPM. On a managed host, change the version via the control panel or CLI.
Monitor error logs for 48 hours
Enable PHP logging (
log_errors = On,error_log = /var/log/php/error.log) and watch for notices, warnings and fatal errors for at least two business days after the switch.Update the inventory and notify the client
Update your mapping spreadsheet with the new PHP version and migration date. Send a closing note to the client confirming the upgrade — this traceability is useful during compliance audits.
On a VPS, PHP-FPM allows you to run multiple versions in parallel without conflict: each nginx virtual host points to a separate FPM socket (php8.2-fpm.sock, php8.3-fpm.sock, php8.4-fpm.sock). This architecture lets you migrate site by site, keeping projects not yet tested on PHP 8.2 while validated projects already run on 8.3 or 8.4. Typical nginx configuration: fastcgi_pass unix:/run/php/php8.3-fpm.sock;. Start with the least critical sites to refine your process and verify that your deployment scripts correctly handle PHP-FPM reload.
Frameworks and CMS — PHP 8.2 drop dates
Understanding your frameworks' schedules is essential for anticipating migration constraints. Laravel 12, released on February 24, 2025, supports PHP 8.2 to 8.5 and receives security fixes until February 24, 2027 — no urgency to upgrade the framework version. However, Laravel 13 (released Q1 2026) requires PHP 8.3 as a minimum: any application wishing to migrate to Laravel 13 must first move to PHP 8.3. Symfony 7.x (all versions from 7.0 to 7.4) requires PHP 8.2 minimum; the LTS version Symfony 7.4, released in November 2025, is supported until November 2029 — it is compatible with PHP 8.3 and 8.4. Symfony 8.x requires PHP 8.4 minimum. WordPress recommends PHP 8.3 as the minimum version in 2026, and premium plugins progressively condition their support on PHP 8.3 or higher. These milestones should appear in your migration plan: a framework constraint can trigger a PHP upgrade earlier than expected.
Automating version monitoring across your agency stack
A manual inventory ages quickly: clients add plugins, change deployment providers, or install new applications without notification. Automating version monitoring lets you stay informed without daily effort. Several complementary approaches exist. A simple cron script can query php -v over SSH on each server and write the result to a central report file — a tool like Ansible or Fabric allows parallelizing this collection across dozens of hosts. Server monitoring tools (Netdata, Munin, or specialized agents) expose the PHP version in their metrics and can trigger alerts if an unauthorized version appears. For stacks hosted on ServOrbit VPS instances, a per-VPS inventory endpoint lets you query the active PHP version on each FPM pool from a centralized dashboard. The goal is that discovering a site still on PHP 8.2 after December 31, 2026 triggers an automatic alert — not an annual audit.
Troubleshooting — 4 common migration errors
PHP 8.2 → 8.3/8.4 migrations follow recurring failure patterns. First, dynamic properties: since PHP 8.2, adding an undeclared property to a class is deprecated; in PHP 8.4, it is a fatal error. The symptom is a Creation of dynamic property Warning followed by unexpected behavior. The fix: declare all properties in the class or add the #[\AllowDynamicProperties] attribute for legacy classes. Second, missing PECL extensions: PHP 8.3 and 8.4 do not compile the same extensions by default depending on the distribution; extensions like imagick, redis or swoole must be explicitly reinstalled for the new version. Check with php8.3 -m | grep redis. Third, Composer version conflicts: a package declaring "php": "^8.2" may raise an incompatibility with another package declaring "php": "^8.3" if your composer.lock has not been regenerated — always rerun composer update from scratch in the staging environment. Fourth, deprecated ini directives: some directives like mbstring.func_overload have been removed; an uncleaned php.ini can produce warnings at PHP-FPM startup and mask real application errors.
Planning ahead to manage your client stack smoothly
For an agency managing dozens of sites, the PHP migration is a multi-site project to pilot several months in advance. Establish a plan by decreasing priority: e-commerce sites and critical management applications first, brochure sites last. Communicate to your clients the risks of staying on PHP 8.2 after December 31, 2026 — a dated memo explaining the security and compliance implications is usually enough to unlock the agreement and budget needed. Integrate PHP version upgrades into your annual maintenance contracts: a dedicated line avoids renegotiating each migration. For projects using Docker from the start, the migration reduces to changing a base image in the Dockerfile and rerunning tests — a half-day of work rather than a server intervention.
ServOrbit VPS with configurable PHP-FPM
On a ServOrbit VPS, multiple PHP-FPM versions coexist on the same machine and each virtual host points to the version of its choice. Upgrading is done by modifying a single line of nginx configuration and reloading PHP-FPM — no server restart, no interruption to other hosted sites. For agency stacks, a dedicated VPS per client or a shared VPS with PHP-FPM isolation per pool provides the flexibility to migrate site by site according to your schedule, without depending on a managed hosting provider's timeline. Centralized FPM pool management from the ServOrbit panel lets you see at a glance which PHP version is active on each domain — a prerequisite for keeping your inventory current and anticipating the next lifecycle deadlines.
