PHP 7.4 and 8.1: Upgrade or Extended Support?

PHP 7.4 and 8.1 have passed upstream end of life

Upstream means the PHP project that develops PHP itself. PHP 7.4 reached its upstream end of life on November 28, 2022. PHP 8.1 followed on December 31, 2025. Neither branch receives regular PHP project releases now. Those dates do not tell you whether a separate package provider maintains your installed build. PHP's unsupported branches list records the dates.

PHP project support as of October 22, 2026
Branch	Current upstream status	Upstream security support ends
7.4	End of life	November 28, 2022
8.1	End of life	December 31, 2025
8.2	Security fixes only	December 31, 2026
8.3	Security fixes only	December 31, 2027
8.4	Active support	December 31, 2028
8.5	Active support	December 31, 2029

Active support includes ordinary bug fixes and security fixes. PHP's later support period covers critical security issues. Check its supported versions table again when choosing a deployment date.

Exceptional patches need separate attention. On October 21, 2026, PHP announced minimal source backports for 7.4, 8.0 and 8.1 for that day's two critical vulnerabilities. These source changes help people who build PHP; they do not restore routine support or automatically update a hosting account. Ask your package provider what it has shipped. PHP's October 21 advisory explains the exception.

Choose an upgrade, maintained older packages or a temporary restriction

The comparison below is practical advice. Your application requirements and confirmed package coverage should decide which route is workable.

Three ways to handle an older PHP application
Choice	When it fits	What you must arrange	Main limit
Upgrade to supported PHP	Your application can run on a supported branch after manageable changes.	Compatible application and extension releases, staging tests, a deployment window and recovery steps.	Old code or dependencies may break; testing and repairs take developer time.
Use extended security support	You need more time to replace code or a dependency, and a provider maintains a suitable build.	Written scope for your operating system, PHP packages, extensions, architecture and required fixes; someone must install updates.	Coverage has conditions and an end date. It does not make the application compatible with newer PHP.
Reduce or pause public access	No confirmed fix can be deployed immediately, or the application is being retired.	Access changes matched to how people use the application, checks for routes around those controls and a dated next step.	Customers may lose access. Remaining reachable code still runs on the older runtime.

You can combine these choices. An administrator might install a provider's maintained package now while developers prepare a supported PHP upgrade in a separate test environment. Restricting an unused administrative route can also be sensible during that work. Give each task an owner and a completion date.

Prepare an upgrade around what people do in the application

First record the application release, third-party libraries, extensions, database driver and PHP package source. Include scheduled tasks and queue workers, which may run outside the website. Ask whoever maintains the application which PHP versions it supports. A hosting control panel offering a version does not establish application compatibility.

Then make a staging environment, a separate copy for testing changes. Match production settings and required extensions closely enough to reveal meaningful problems. Use protected or suitably anonymized data. Disable real customer email and use test payment credentials so a checkout test cannot charge a customer.

Moving from 7.4 crosses PHP 8.0 changes, including removed functions and changed comparison behavior. A move from 8.1 also crosses later changes, such as PHP 8.2's warnings about creating undeclared object properties. Read migration notes for every intervening branch, even if production will move directly to the chosen destination. PHP 8.0 incompatibilities and PHP 8.2 deprecations give concrete examples. A deprecation is a warning that a feature is being phased out.

Test login, permissions, search, uploads, orders, emails, imports and reports that your application actually uses. Include scheduled work, failure messages and external integrations. Compare important outputs, such as report totals, as well as checking whether pages load. PHP's 8.5 migration guide also calls for compatibility testing before changing production.

Before switching production, agree how to restore the application, configuration and data if a critical function fails. A PHP version switch alone cannot undo database changes made by an application upgrade. Decide how orders or edits made during the deployment will be preserved, and who can authorize recovery.

Extended support applies to defined packages and builds

A provider may backport a security fix, meaning it adapts a repair to an older software branch. The base PHP number can stay old while the full package revision changes. Debian explains this approach in its security FAQ. To assess a package, compare its complete revision and source with the provider's notice for your operating system.

Ubuntu is one documented example of distribution support. Canonical's technical documentation separates esm-infra, which extends maintenance for Main packages, from esm-apps, which covers Universe packages. A subscription limited to infrastructure is therefore a different purchase from the broader service. Check the installed package and required stream before assuming it has coverage. Ubuntu's ESM scope documentation describes these streams.

Ubuntu's October 21 PHP security notice for older Ubuntu releases lists PHP 7.4 packages for Ubuntu 20.04 and identifies the update as available through Ubuntu Pro. That example establishes coverage for the packages and issues named there. It does not establish coverage for an independently compiled PHP installation, a third-party repository or every extension.

Debian needs a current lifecycle check too. Debian announced that Debian 11, also called Bullseye, reached the end of its LTS period on August 31, 2026. From September, Debian no longer supplies its security updates; external parties may cover a subset of packages. An old statement that Debian 11 has LTS support is now out of date. Debian's end-of-life announcement states the change.

For any commercial provider, obtain answers that identify your actual installation:

Which operating system releases, processor architectures, PHP builds and repositories are included?
Which bundled and separately installed extensions are covered? What about application libraries and encoded commercial software?
Which vulnerabilities qualify for a fix? What exclusions and delivery targets apply?
Who installs updates, restarts services and checks the application?
When does coverage end, and what happens if a required issue cannot be fixed on this branch?

Ask for a package or advisory reference for each urgent vulnerability. Confirm that the maintained packages are installed and serving the application. Our guide to backports and running PHP covers that separate check.

Compare the full cost of keeping the application usable

The application owner pays either staff or a service provider to do the work. Extended support can add a recurring subscription, while an upgrade can require a larger initial development project. Both routes still need deployment and application checks. A useful quote separates these costs:

Costs to request in an upgrade or extended-support quote
Cost	What the quote should explain
Application changes	Which code, plugins or dependencies will be repaired, replaced or upgraded, and which features are excluded.
Maintained packages	Which machines or other billing units need coverage, subscription length, included packages and renewal terms.
Delivery	Who prepares staging, installs updates, changes configuration, restarts services and checks business functions.
Recovery and follow-up	Who restores service after a failed change, whether data recovery is included, and which later faults cost extra.

For a fixed comparison period, add development, support subscriptions, testing, deployment and expected hosting changes. Include a second migration if the proposed destination will soon lose support. Ask separately about lost sales or staff time during downtime, because a provider's fee may not cover those business losses.

Use temporary protections with a named next step

If an application cannot receive a confirmed fix now, its owner and administrator should decide which functions must remain reachable. An internal tool may be moved behind a private network or restricted to approved addresses. A public application may need some functions paused, or a temporary maintenance page that does not invoke its PHP code.

Check whether visitors can bypass a restriction through another hostname, a direct server address or an unprotected service. A web application firewall filters requests according to its rules; whether it blocks a specific exploit depends on those rules and all paths to the application.

These are exposure-reduction choices, not a general fix for unsupported PHP. PHP's October 21 advisory explicitly says its temporary measures leave risk and that updating is required. Have an administrator assess any advisory-specific setting against your application and resource limits rather than copying a universal hardening recipe. Read PHP's current advisory.

Record which access changed, which users or integrations may be affected, who will deploy the maintained build or upgrade, and when you will review the restriction. If the application has no continuing business use, a planned retirement may be less costly than maintaining its runtime.

15 questions about older PHP

1. Do we need to act if our PHP 7.4 application still works?

Yes. Successful page loads tell you that familiar features work; they do not tell you who will repair newly discovered PHP flaws. Establish the installed package's maintenance source and present coverage. PHP lists 7.4 as an unsupported upstream branch. If no provider maintains your build, arrange an upgrade and assess public access while it is prepared. If a provider does maintain it, check its package notices and set a date to review the migration plan. PHP's end-of-life list is the starting point for upstream status.

2. Should we choose PHP 8.4 or 8.5 for the upgrade?

Compare application compatibility, extension availability and support remaining when the change will go live. Both branches have active PHP project support on this article's check date; 8.5 has the later security-support end date. A destination your application and host support can be a reasonable choice even when a newer branch exists. Ask your developer to show successful staging checks and your host to confirm maintenance for its package source. Recheck PHP's support calendar before committing to a long project.

3. Can we move directly from PHP 7.4 to PHP 8.5?

You can prepare and test a destination environment without deploying every intervening PHP branch to production. Your code still crosses all relevant language and library changes. Use the intervening migration guides as a checklist, and let test failures determine whether developers need intermediate test environments to isolate problems. A direct production move should happen only after the application works on the destination. PHP's 7.4-to-8.0 guide and 8.4-to-8.5 guide both identify compatibility testing as part of a move.

4. Is PHP 8.2 a sensible destination from PHP 8.1?

It may be a short intermediate step if it can be delivered sooner and provides the fixes you need. As of October 22, 2026, it has only until the end of this year in PHP's security-support period. Ask whether moving to 8.4 or 8.5 now would avoid paying for another near-term migration. If an application only supports 8.2, document that constraint and the next application release or repair needed. The choice should account for both delivery speed and the cost of the following move. PHP publishes the branch deadlines.

5. What should we test beyond the home page?

List the tasks people rely on and give each one a clear pass condition. For an application that accepts orders, that may include login, cart changes, a sandbox payment, order confirmation and a refund test in the payment sandbox. For an internal tool, it may include imports, role restrictions and matching report totals. Test background jobs and integrations separately. Review logs in staging for new errors and warnings, then retest important tasks after production changes.

6. What if an abandoned plugin or library prevents the upgrade?

Identify the specific failure and the component responsible. Then compare a supported replacement, a focused repair, removal of an unused feature and retirement of the application. Keeping an older runtime indefinitely also keeps that dependency in service, with its own maintenance questions. Extended PHP support can provide time for a replacement project if the exact runtime is covered, but it does not transfer maintenance of the plugin to the PHP provider. Ask the developer to quote the blocked feature separately so you can judge what preserving it will cost.

7. How do we check extension and encoded-software compatibility?

Make a list of required extensions, their versions and who supplies them. Obtain destination-PHP compatibility information from each extension or commercial software maintainer. Encoded applications may need a compatible loader and permission or a new build from their supplier. On a staging machine you administer, php -m lists modules for that command-line PHP executable. It is a useful inventory aid, but it does not prove that web requests load the same modules or that every application path works. PHP documents the command-line options.

8. Can Composer tell us whether the application supports newer PHP?

Composer checks declared package requirements, which can reveal blockers and missing extensions. In a trusted staging copy, with Composer already installed and the intended PHP executable selected, this diagnostic checks requirements of installed production dependencies:

composer --no-plugins --no-scripts check-platform-reqs --no-dev

It does not update packages. The flags disable Composer plugins and project scripts for this check. It examines the actual command-line PHP and extensions, even when Composer's configuration declares a different target platform. A successful check is one input to application testing; it cannot validate business behavior or undeclared dependencies. Composer documents what this command checks.

9. Does an old PHP version number always mean the package is unpatched?

No. A distribution may adapt a fix to an older PHP branch and record it in its package revision. Ask for the full package identifier, the operating system release, the repository and a matching security notice. Compare those together rather than comparing only the first three version numbers with an upstream release. A generic claim that a host uses backports still needs evidence for your installed package and the issue being assessed. Debian's security FAQ about version numbers explains why version-only warnings can misclassify maintained packages.

10. Does Ubuntu Pro automatically cover every PHP installation on Ubuntu?

Check the installed source and enabled services. On a machine you administer, with the Pro client already present, these commands show coverage information without attaching a subscription or installing an update:

pro security-status
pro security-status --thirdparty

The first command summarizes installed APT packages and their coverage. The second identifies third-party packages, such as packages from a separate repository. A self-built PHP binary may need investigation outside that package inventory. Read any stale-cache warning, then ask your administrator to confirm current package information and applicable service scope. Canonical explains these outputs.

11. Can we still rely on Debian 11 LTS for PHP 7.4?

Debian 11 LTS ended on August 31, 2026. If you still run it, establish whether an external provider covers your particular packages now, and plan an operating system move as well as a PHP decision. Debian's announcement says external support covers a subset of Bullseye packages; it does not promise that every installation or extension is included. Obtain the actual package list and maintenance terms from that provider. Debian's August announcement is the dated reference, rather than an older hosting guide.

12. What should an extended-support provider confirm in writing?

Ask it to name the operating system release, architecture, PHP package source, covered builds and extensions, support end date and required subscription tier. For an urgent security issue, ask which advisory and package revision address it and when that build can be installed. Separate package maintenance from application troubleshooting, incident response and deployment services. Request any exclusions or delivery commitments in the contract. A provider may supply maintained packages while your host or administrator remains responsible for installing them and checking that the application works afterward.

13. Is extended support cheaper than an upgrade?

That depends on application repairs, subscription terms and how long you need the older runtime. Request actual quotes for both routes over the same period. Include developer time, replacement software licenses, test hosting, deployment and follow-up. Ask whether a subscription price includes human help or only access to packages, and how machines or containers are counted. Extended support can defer a migration expense, but the later migration may still be necessary.

14. Can a firewall or private network make unsupported PHP safe to keep?

Access restrictions can reduce who reaches an application, which may be useful while a fix or retirement is prepared. They depend on correct configuration and complete coverage of every entry point. A permitted user, another reachable route or a different flaw can leave risk. Ask your administrator which access is blocked, how that was checked and which users or integrations will fail. PHP's October 21 advisory says its temporary measures leave exposure.

15. What should our host do if we only have a control-panel login?

Ask the host to identify the PHP package serving your site, its maintainer, current security coverage and available supported destinations. Ask whether it can provide a separate test copy and explain what a version switch affects, including scheduled jobs and extensions. You may need your application developer to repair compatibility issues while the host manages server changes. Do not run administrator commands you do not have permission to use. Before approving a production change, agree the test checklist, maintenance window and who restores service if a required function fails.

Primary sources and related guides

Support dates and package scope can change. These sources were checked on October 22, 2026; confirm the relevant provider notice again before a production change.