Upgrade Now or Pay for Extended Support? Options When Your PHP Version Runs Out

When a PHP version you depend on reaches its end date, you have three real choices, not one. You can upgrade the application to a supported version, you can pay a vendor for php extended support on the old version, or you can isolate the system and limit what touches it while you plan the next step. Each option carries a different cost, a different risk, and a different timeline, and the right one depends on your specific system rather than on which option sounds best in the abstract.

Most businesses treat an end of life deadline as a single switch: upgrade or do not. In practice there is a real middle ground, and skipping past it, in either direction, usually costs more than weighing it honestly.

What actually happens when the clock runs out

PHP support runs on a fixed schedule. A version gets roughly two years of active development, when bugs and security holes both get fixed, then about two more years of security only fixes, then nothing. Once a version is past that second window, no new patch arrives, no matter how serious the flaw turns out to be. Your hosting provider cannot fix this for you. Nobody can, because the fix does not exist.

This does not mean the application stops working the day the deadline passes. The server keeps running. The site keeps loading. What changes is the direction of risk. The longer a system runs on an unsupported version, the more known, published vulnerabilities pile up against it, and the easier it gets for an automated scan to find one. An insurer, auditor, or enterprise customer who asks what PHP version you run, and gets an answer like "8.1, unsupported since the end of 2025," tends to treat that answer as a red flag rather than a technicality.

Option one: upgrade the application now

Upgrading means moving the application to a currently supported PHP version, which usually drags framework and library updates along with it, since old dependency versions often will not run on new PHP at all. This is the only option that removes the underlying problem instead of managing around it.

The cost here is mostly developer time rather than licensing fees, and it scales with how much deprecated code the application has built up. A clean, well tested Symfony or Laravel application built in the last few years might move two major versions in a few weeks. An application with a decade of untouched code, no test coverage, and custom extensions nobody remembers writing can take months, and the estimate usually grows once work starts, because that is when the undocumented parts surface.

Tools like Rector can automate a meaningful share of the mechanical changes, such as renamed functions and changed signatures, which cuts timeline and risk on larger codebases. It does not replace the testing and judgment a person still has to apply, especially around anything touching money, authentication, or stored data.

Upgrading is the right default when the application still has a future: when it is actively used, when the business plans to keep investing in it, and when the codebase is not so tangled that starting over would genuinely be faster.

Option two: pay for php extended support

Several vendors, including some tied closely to the PHP project itself, sell extended support contracts that keep delivering security patches for versions past their official end date. This buys time without touching the application at all.

The appeal is obvious. There is no development work, no risk of breaking something mid upgrade, and a predictable annual cost instead of an open ended project. The tradeoff is that you are paying every year for a version that still has none of the performance improvements or language features a current version offers, and the payments do not build toward anything. Extended support also typically excludes the framework and the rest of the stack. Paying to keep PHP itself patched does nothing for an unsupported Symfony LTS branch or an abandoned library sitting one layer up.

Extended support contracts make the most sense as a bridge rather than a destination: a way to buy six months or a year of safety while a real upgrade gets planned and budgeted, not an indefinite substitute for doing the upgrade at all. Treated as a permanent fix, it just delays the same decision while the gap between your version and the current one keeps widening.

Option three: isolate the system and wait

The third option gets discussed less often, but it is frequently the right call for a system that is genuinely on its way out. If the application is scheduled for replacement, used by a shrinking number of people, or kept alive mostly out of inertia, the smartest move can be to isolate it. Pull it off the public internet where possible, lock down network access to only what it needs, remove integrations that are not essential, and stop adding features entirely. An unsupported system that nothing can reach is a much smaller risk than the same system sitting on a public endpoint.

This only works as a stated, deliberate plan with a timeline, not as the default outcome of nobody deciding anything. "We isolated this and plan to retire it within the year" is a defensible answer to an auditor or an insurer. "We never got around to fixing it" is not, even if the technical state looks identical from the outside. The distinction is whether someone made the call and wrote it down, or whether the deadline just quietly passed while nobody decided.

How to actually decide

The three options are not mutually exclusive, and the right combination comes down to three questions: how long does this system need to keep existing, how much does it cost to touch, and what happens if it gets compromised while you work that out.

A system central to revenue, with active development ahead of it and a codebase that is not a disaster, usually points toward upgrading now and treating any support gap as a short bridge rather than a plan. A system that works fine, has a low blast radius if something goes wrong, and is not going anywhere soon can often justify an extended support contract while the upgrade gets scheduled on a realistic timeline instead of a rushed one. A system on its way to retirement, with few users and little new development, is usually better served by isolation than by either of the other two, since paying ongoing support fees or sinking upgrade effort into something you plan to shut down rarely pencils out.

What rarely makes sense is doing nothing and hoping the deadline slides. PHP end of life dates do not move, and the unsupported window only gets wider the longer it sits unaddressed.

If you are not sure which bucket your system falls into, that assessment is usually the first thing worth getting outside help on. A short legacy code audit can tell you how much real work an upgrade involves before you commit to a timeline or a support contract, and a broader tech stack strategy review can settle whether the system is worth upgrading at all versus planned for retirement.

Wolf-Tech works through exactly this kind of decision with clients regularly, including the audit step that tells you which of these three paths actually fits your situation. If you want a second opinion on a PHP version that is running out of runway, reach out at hello@wolf-tech.io or visit wolf-tech.io.