Migrating Off PHP 7: A Practical Upgrade Path to 8.x

Last updated: July 16, 2026  ·  Covers PHP 7.0–7.4 and upgrade targets 8.2–8.5

Every release in the PHP 7 line is long dead. PHP 7.4 — the final and most widely deployed 7.x version — stopped receiving security patches on November 28, 2022. Earlier 7.x releases went even sooner: 7.3 on December 6, 2021, 7.2 on November 30, 2020, 7.1 on December 1, 2019, and 7.0 on January 10, 2019. An application serving traffic on PHP 7 in 2026 is running a runtime that has been unpatched for more than three years. This guide is the practical path out.

Current Status: What Stopped and When

EOL means no security fixes from the PHP project: vulnerabilities disclosed in the interpreter, its bundled extensions, or its standard library after the date above are never patched in that line. Full details per version are on our PHP lifecycle page.

Who Is Affected

PHP 7 lingers in predictable places: legacy WordPress, Drupal, and Magento installs pinned by old plugins or themes; internal tools and intranets nobody owns; shared-hosting accounts where the PHP version was set once in a control panel and never revisited; and older framework applications (Laravel 5/6-era, Symfony 3/4-era, CodeIgniter 3) whose framework version itself requires PHP 7. In that last case the migration is really two migrations — framework and runtime — and the framework is usually the bigger one.

Migration Paths, Ranked by Effort

Path 1 — Straight interpreter upgrade (small or well-typed codebases)

For modern, tested codebases with maintained dependencies, moving from 7.4 to 8.3+ is often days of work: bump the version constraint, run the test suite, fix what static analysis flags, update the handful of packages that need it. You do not need to pass through 8.0/8.1/8.2 at runtime — fix the breaking changes in code and jump to the target.

Path 2 — Staged code modernization (typical legacy applications)

For larger legacy codebases, run the migration as a pipeline: static analysis (PHPStan or Psalm) to find PHP 8 incompatibilities, automated refactoring (Rector has dedicated PHP 7→8 rule sets) to fix the mechanical ones, then manual work on the genuinely dynamic corners. Keep the application running on 7.4 in production while CI runs the suite against the 8.x target, and cut over when green.

Path 3 — Re-platform the application (when the framework is the blocker)

If the application sits on a framework or CMS version that cannot run on PHP 8, upgrading PHP means upgrading the platform: to a current Laravel/Symfony release, a current Drupal, or a rebuilt WordPress theme/plugin stack. This is a project measured in weeks-to-months, and sometimes the honest comparison is against rebuilding the application on a current stack rather than dragging the old one forward.

Path 4 — Extended support as a bridge

Where none of the above can land before an audit or a deadline, paid patching for EOL PHP exists — see below.

Step-by-Step Migration Checklist

1. Inventory PHP versions everywhere — servers, containers, CI images, cron hosts, and that one box running the queue worker. php -v lies less than documentation does.
2. Pick the target: PHP 8.3 or newer. Confirm your framework, CMS, and every Composer dependency declare support for it.
3. Audit dependencies. composer outdated and each package's constraints tell you which libraries need upgrades and which are abandoned and need replacing. Do the same for PECL extensions.
4. Run static analysis against the target version and burn down the incompatibility list; let Rector handle the mechanical rewrites.
5. Fix tests first, code second. A green suite on 7.4 is your safety net; get it green on 8.x in CI before any production change.
6. Stage the cutover. Deploy 8.x to staging with production-like traffic, watch error logs for TypeErrors and deprecation notices, then roll production host-by-host with a rollback path.
7. Remove the old runtime. Uninstall PHP 7 packages after cutover so nothing silently falls back to it.

Common Pitfalls (What Actually Breaks)

• Silent logic changes in comparisons. PHP 8 changed string-to-number comparison semantics (0 == "foo" is no longer true). This doesn't throw — it quietly changes which branch runs. It is the sneakiest class of PHP 7→8 bug, findable only by tests and analysis, not by error logs.
• Warnings promoted to errors. Code that "worked" on 7.4 while emitting warnings — undefined array keys feeding into loose checks, invalid arguments to internal functions — now throws.
• Abandoned dependencies. The blocker is rarely your code; it's the unmaintained Composer package or PECL extension three levels down that never declared PHP 8 support. Find these in week one, not week six.
• Removed functions and features. Long-deprecated pieces of the 7.x era are gone in 8.x — grep for them before the interpreter finds them for you at runtime.
• The 8.2 dead end. Teams that upgrade to the oldest still-supported version land on PHP 8.2 — which is EOL on December 31, 2026. Aim past it.

If You Can't Migrate Yet

Some applications genuinely cannot move on this year's budget — usually because the real cost is a framework or CMS rewrite. Two bridges exist. Commercial extended-support vendors ship security patches for EOL PHP versions, including 7.4, as a paid service; we compare them on our extended support vendors page. Separately, some Linux distributions backport PHP security fixes within their own OS support windows — check what your distribution actually covers rather than assuming. Either way, treat the bridge as scheduled time with an exit date, and spend it executing Path 2 or 3.

Frequently Asked Questions

Related Resources

• PHP lifecycle data on endoflife.ai
• PHP 7.4 EOL details
• PHP End of Life Guide
• Extended support vendors, compared
• EOL Watch — end-of-life news and deadline coverage