LEGACY AND END-OF-LIFE PHP
PHP upgrade services
We move business-critical applications off unsupported PHP — 5.x, 7.x, 8.0, 8.1 — onto a version that still receives security fixes. Version by version, with tests in place, without a rewrite.
Which version are you on?
An unsupported PHP version does not stop working. That is the problem — the application carries on serving customers while the security holes found after its end-of-life date are never patched, and nobody notices until an auditor, an insurer or an attacker does.
If you are not sure which version you are running, or which of your applications are on which, that is the first thing our audit tells you.
PHP 5.x and 7.x
End of life. PHP 7.4, the last of the line, stopped receiving security fixes in November 2022.
PHP 8.0
End of life since November 2023. No security fixes.
PHP 8.1
End of life since 31 December 2025. No security fixes.
PHP 8.2
Security fixes only — and they stop on 31 December 2026.
PHP 8.3
Security fixes only, until December 2027.
PHP 8.4 and 8.5
Actively supported. This is where we take you.
Source: php.net supported versions, September 2026.
What actually blocks a PHP upgrade
It is rarely the language itself. It is everything that was written against the old one.
What breaks
- ✗ Functions and extensions that were removed outright — each(), create_function(), the original mysql_* extension, ereg
- ✗ PHP 8 turning long-standing warnings into fatal errors, so code that limped along now stops
- ✗ The stricter string-to-number comparison rules in PHP 8, which quietly change what your conditionals decide
- ✗ Composer dependencies pinned to constraints that have no PHP 8 release
- ✗ Abandoned libraries and plugins with no maintained version at all
- ✗ Custom php.ini and server configuration written for a different runtime
What we do about it
- ✓ A full static analysis pass across the codebase before anything is touched, so the size of the job is known up front
- ✓ Removed functions rewritten to their modern equivalents rather than shimmed
- ✓ Dependencies inventoried, updated where possible, replaced where the project is dead
- ✓ Characterisation tests around the parts with no test coverage, so we can prove behaviour did not change
- ✓ Abandoned plugins re-implemented as maintained code you own
- ✓ Configuration rebuilt to match the original intent, documented as we go
How the upgrade runs
Nothing is built until you have seen the audit and agreed the number.
01
Audit
Static analysis across the whole codebase, a dependency inventory, and a written report of exactly what breaks and where.
02
Fixed proposal
Scope, sequence and cost in writing. If the honest answer is that a rebuild costs less, we say so here.
03
Upgrade in a branch
Version by version, behind tests, on a staging environment you can use before anything reaches production.
04
Cutover and support
A planned switch with a rollback ready, then a maintenance plan that keeps you on a supported version.
It stops being a technical question
At some point the PHP version leaves the development backlog and turns up in an audit, a questionnaire or a renewal.
Cyber Essentials
The scheme expects software that is still supported by its vendor and patched within defined timescales. Unsupported PHP is a straightforward fail.
PCI DSS
If you take card payments, you are required to keep system components patched against known vulnerabilities. There are no patches for an end-of-life runtime.
Public-sector and enterprise buyers
Procurement and supplier assurance questionnaires increasingly ask which runtime versions you are on, and want evidence.
Cyber insurance
Insurers ask about patching and supported software at renewal, and a claim can turn on the answer.
ORGANISATIONS WE HAVE DONE THIS FOR
PHP upgrade questions
How long does a PHP upgrade take?
It depends almost entirely on how much of the code relies on functions and extensions that were removed. The audit takes one to two weeks and ends with a firm timeline and cost, so you are not asked to commit to a number before anyone has read the code.
Can you upgrade without downtime?
In most cases yes. We work in a branch, prove it on a staging environment, and plan the cutover for a window you choose, with a rollback ready.
What if a library we depend on has no PHP 8 version?
That is one of the most common blockers. Depending on what it does, we replace it with a maintained alternative or re-implement the part you actually use as code you own.
We have no tests. Is that a problem?
It is normal, and it is handled. Before changing behaviour we add characterisation tests around the areas being touched, so we can show that what went in still comes out.
Which version should we move to?
PHP 8.4 in most cases: it is in active support until the end of 2026 and receives security fixes until the end of 2028. Where a dependency forces it, 8.3 is a reasonable staging post.
Is it cheaper to rebuild instead?
Sometimes, and we will tell you if that is what the audit shows. A rebuild is the right answer when the application no longer matches how the business works, not simply because the PHP version is old.
Contact us!
Do you have a question about our PHP development services?
Looking for a bespoke solution for your website?
We’re here to help!
What happens next
We reply within one working day. The first call is 30 minutes, with a developer on it, and there is no charge for it.
Phone:
0203 507 1728