PHP Migration & End-of-Life Modernization

A PHP application is rarely just PHP. It’s a specific framework version, a composer.json full of dependencies pinned to a runtime, a set of extensions the host was configured for, and years of code written against behavior that newer PHP no longer honors. That’s why “upgrade PHP” is never a flag flip — and why an application on an unsupported version is a problem you can’t apt upgrade your way out of.

How much runway your PHP version has left

The PHP project retires each branch on a published schedule, and several versions still in production are past the end of it:

Version	End of life	Status
PHP 7.4	November 28, 2022	End of life — no fixes
PHP 8.0	November 26, 2023	End of life — no fixes
PHP 8.1	December 31, 2025	End of life — no fixes
PHP 8.2	December 31, 2026	Security-only
PHP 8.3	December 31, 2027	Supported
PHP 8.4	December 31, 2028	Supported

Dates are from the PHP release schedule. Since March 2024 each branch gets roughly two years of active support and two of security-only fixes, ending on the last day of the calendar year. The line that matters is the same for each retired version: once a branch reaches end of life, no security fix will ever ship again for a vulnerability found the next day — and PHP’s are not hypothetical, with actively exploited CVEs disclosed against versions long past support. An application on PHP 7.x or 8.0 is not “old but fine” — it’s running on a runtime the project has stopped defending.

What end of life actually means for a PHP app

The runtime raises the stakes over an ordinary dependency, for three reasons.

• It’s almost always internet-facing. PHP overwhelmingly runs web applications, which means an unpatched interpreter sits directly in the path of untrusted traffic — exactly where an unfixable vulnerability does the most damage.
• It collides with compliance. PCI DSS, SOC 2, and HIPAA all expect systems in scope to be patchable. An unsupported PHP in a regulated request path is a finding waiting to be written, and “we run a WAF” rarely satisfies an assessor on its own.
• It drags the whole stack. The framework, the libraries, and often the extensions are pinned to the PHP version. Staying on an old runtime freezes everything above it, so the technical debt compounds across the entire application.

The migration options

There is no single right move; there’s a right move for your application, and it turns on how far behind it is and what it’s pinned to.

• Step up to the next supported version where the gap is small. Moving from PHP 8.0 to 8.2 or 8.3 is the cheapest path when the framework and dependencies have compatible releases and the breaking changes are few. Often the honest answer for a well-maintained codebase.
• Upgrade the stack in lockstep. When the application is on a framework version that itself has aged out, the PHP move and the framework move have to happen together — more involved, because the breaking changes stack, but unavoidable.
• Re-platform the parts that fight the move. Where code leans on removed functions, deprecated extensions, or patterns PHP 8 rejects, those slices need real re-implementation rather than a mechanical bump. The bulk of the genuine work lives here.

The decision is rarely about the interpreter — it’s about the framework and dependencies the code is pinned to, and the behavior changes between major versions. That coupling is what turns a version bump into a modernization project.

Modernizing off it, slice by slice

We treat the application the same way we treat any legacy system: not a single risky cutover, but a sequence of small, reversible steps.

A strangler facade lets the legacy PHP application and the modernized path run side by side. We break the application into slices — a route group, a service, a bounded module — and before any slice carries live traffic, we prove it behaves identically to the legacy: same responses, same state, reconciled against the original. AI-accelerated discovery reads the code, the composer dependencies, and the extension assumptions end to end and captures what the application actually does — including the undocumented logic the original authors never wrote down — under senior-engineer review. Traffic shifts only on green, rollback stays a flag away, and the unsupported PHP path is retired only once nothing depends on it.

When a straightforward step-up is enough

Not every PHP upgrade is a modernization project, and we’ll say so. An application only a version or two behind, on a maintained framework with compatible dependencies, is often best served by a straightforward step up to a supported PHP release — the lowest-cost path that clears the end-of-life risk, and one many teams can do themselves. The slice-by-slice approach earns its place when the gap is wide, when the framework has aged out alongside the runtime, when the code leans on behavior PHP 8 removed, or when the application can’t take downtime. Matching the effort to the actual gap is part of the assessment, not an afterthought.

Where to start

The first step is small and bounded: understand the application before committing to a path. A discovery call scopes which PHP version is in play, how far the framework and dependencies have drifted, where the compliance exposure sits, and whether the right move is a step-up or a deeper migration — on evidence, not a sales pitch. Reach the team at sales@modernlift.ai.