PHP Version Migration Center

This center organizes PHP runtime upgrades the way production teams actually ship them: inventory first, remove dead APIs, climb a tested version ladder, then harden Composer and CI. It is not a marketing timeline of “new features”—it is a routing desk for maintainers who inherited FPM pools still pinned to abandoned branches.

Supported PHP branches (verified 2026-08-09)

Per php.net/supported-versions.php, currently supported release lines are:

• PHP 8.2 — security support until 2026-12-31
• PHP 8.3 — security support until 2027-12-31
• PHP 8.4 — active support until 2026-12-31
• PHP 8.5 — active support until 2027-12-31

PHP 5.x, 7.x, 8.0, and 8.1 are end of life. Treat them as incident risk, not “stable enough.” Do not invent undocumented branches beyond what php.net publishes.

Choose a migration path

• PHP 5 → modern PHP (flagship) — mysql_*, mcrypt, ereg, each, create_function, charset, testing
• PHP 5 → PHP 7 and PHP 5 → PHP 8
• PHP 7 → PHP 8 (deep) · checklist · 7.4 → 8.x
• Incremental 8.x steps: 8.0→8.1, 8.1→8.2, 8.2→8.3, 8.3→8.4, 8.4→8.5
• Removed functions hub · Deprecated features hub
• Compatibility tables · Determine runtime version · Legacy audit

Tools before you rewrite architecture

Run scanners early so fatals are not discovered on the production cutover night:

• PHP Version Compatibility Checker
• PHP Deprecated Checker

Pair findings with the PHP Errors encyclopedia when CI surfaces signatures such as mysql_connect removed or dynamic property deprecations.

Recommended sequencing

1. Freeze a reproducible inventory (SAPI, extensions, Composer platform, cron entry points).
2. Eliminate removed APIs that hard-fail on the next major.
3. Raise CI to the target minor with E_ALL and fail on deprecations in staging.
4. Soak under load, then cut FPM/CLI images together so CLI workers do not lag the web pool.