PHP 7.4 reached end of life and stopped receiving security patches on November 28, 2022; its last release was 7.4.33. Upgrading means moving to PHP 8.3 or later, and the real work lies in the PHP 8.0 changes that break old code.
That is almost four years without fixes. In that time new flaws have surfaced, PHP2Shell among them, which was fixed on October 21, 2026, only in 8.2.35, 8.3.36, 8.4.27 and 8.5.12. At DCisGlobal we still find invoicing systems, online stores and CRMs on 7.4 that seem to work fine but run without a safety net.
What it means when PHP 7.4 is unsupported
It means nobody fixes the flaws that come up. The official PHP site puts it plainly: users of an unsupported version may be exposed to unpatched security vulnerabilities and should upgrade as soon as possible.
There is a second, less visible cost. Hosting providers retire old versions, and libraries and plugins stop shipping updates for 7.4. The system freezes: every improvement costs more because you have to work around old dependencies.
For background on the most recent flaw, see what PHP2Shell is and what to do.
Which version to upgrade PHP 7.4 to
Straight to 8.3 or later. PHP 8.0 and 8.1 are already unsupported, and 8.2 loses support on December 31, 2026. Stopping halfway means repeating the project in a few months.
PHP 8.3 has security support until 12/31/2027, 8.4 until 12/31/2028 and 8.5 until 12/31/2029. If your dependencies allow it, 8.4 or 8.5 give you more years of runway for a similar effort.
The PHP 7.4 to 8 changes that tend to break old systems
The official php.net guide “Migrating from PHP 7.4.x to PHP 8.0.x” lists the incompatible changes. These are the ones we see most in business systems, translated into what the business notices:
| Technical change | What the business notices |
|---|---|
| Functions such as create_function(), each() and money_format() were removed | Screens or processes that stop loading entirely |
| Comparison between numbers and strings changed: 0 == "foo" is no longer true | Filters, searches or validations that return a different result without showing any error |
| Several warnings became errors, for example count() on something that is not a list | A report or a payment that stops halfway instead of continuing with a warning |
| Methods named after the class no longer act as constructors | Objects created without their initial data that fail later on |
| PDO, the database access layer, throws exceptions by default | Database errors that used to pass silently now stop the page |
| Nested ternaries without parentheses and static calls to non-static methods | Old code that simply stops running |
| The @ operator no longer silences fatal errors | Problems that were hidden come to light |
Is your PHP version safe?
Type the exact version your server runs and we’ll tell you right away whether it’s exposed and what to do.
The hardest part is usually the last one: problems that had existed for years but stayed hidden. PHP 8 does not break a healthy system; it stops looking the other way.
What changes from PHP 8.0 to 8.3
Once past the jump to 8.0, the rest is lighter. The guides “Migrating from PHP 8.0.x to PHP 8.1.x”, “8.1.x to 8.2.x” and “8.2.x to 8.3.x” mostly document deprecations:
- In 8.1, passing null to built-in functions that expect a string or number triggers deprecation notices. In old systems they tend to show up in many places and flood the logs.
- In 8.2, dynamic properties on objects are deprecated, as are utf8_encode() and utf8_decode(), common in systems that mix text encodings.
- In 8.3, the list of incompatible changes is short and specific.
These notices do not stop the system, but it pays to fix them in the same project so you do not carry them forward.
What to do now
- Confirm version and scope. Which systems run on 7.4 and on which servers.
- Review dependencies. Framework, CMS, plugins and libraries: which have a PHP 8.3-compatible version and which do not.
- Analyze your custom code. Static analysis tools catch a good share of incompatible changes before anything runs.
- Test on a copy with PHP 8.3 or later. Walk through the processes that bring in revenue: sales, invoicing and collections.
- Show every warning in testing. What was hidden in production has to surface in staging, not in front of a customer.
- Go to production with a backup and a clear plan to roll back if something fails.
For the detailed process, see our guide on how to upgrade PHP on unsupported systems. If your server shows “PHP/8.0.30”, read PHP 8.0: vulnerabilities and end of life; for 8.1, see PHP 8.1 end of life: why PHP 8.3 is the next step.
How we solve it at DCisGlobal
We run a technology assessment of the system and deliver a plan with what needs to change, in what order and at what cost. If upgrading does not make sense, we say so and evaluate phased custom software development.
The migration happens in a staging environment, is validated with your team and goes to production with a backup in place. Afterwards we can take over support and maintenance so the system does not fall behind again.
