PHP upgrade service for legacy applications
Move to a supported PHP version without breaking the business that depends on it.
If your application runs on PHP 5.6, 7.x, 8.0 or 8.1, it no longer receives security fixes. If it runs on 8.2, that ends on 31 December 2026. I upgrade large, undocumented, untested PHP applications in stages, tests first, rollback ready, so the upgrade is a planned project and not a production incident.
Book a free conversationLegacy System Assessment, from £2,500
Is your PHP version still supported?
Dates from the official PHP supported-versions page, checked October 2026. Always confirm at php.net/supported-versions.
| PHP version | Security support ended / ends | Status |
|---|---|---|
| 5.6 | December 2018 | End of life |
| 7.0 - 7.3 | 2019 - 2021 | End of life |
| 7.4 | November 2022 | End of life |
| 8.0 | November 2023 | End of life |
| 8.1 | 31 December 2025 | End of life |
| 8.2 | 31 December 2026 | Security fixes only, ending soon |
| 8.3 | 31 December 2027 | Security fixes only |
| 8.4 | 31 December 2028 | Supported |
| 8.5 | 31 December 2029 | Supported |
"End of life" means vulnerabilities discovered today will never be fixed in that version. Not sure which version you're running? Ask your host or developer, or tell me and I'll find out. Is my PHP version safe?
Why it can't wait
- Security: unpatched vulnerabilities are scanned for automatically. Old PHP is an easy target.
- Hosting: providers drop old PHP versions on their timetable, and your site can stop working with little warning.
- Compliance and insurance: Cyber Essentials, cyber insurance and customer questionnaires increasingly ask about unsupported software. Data protection and security
- Everything else is blocked: modern libraries, payment providers and APIs increasingly require current PHP. The longer you wait, the bigger each jump becomes.
- Performance: modern PHP is substantially faster than PHP 5.x and 7.x, which can reduce hosting costs.
How I upgrade PHP applications safely
1. Assess
I establish the current version, framework, dependencies, database, server and integrations, and map what will break and in what order. AI-assisted analysis scans the whole codebase for incompatibilities up front, instead of finding them one at a time in production. How I use AI
2. Build a safety net
Where critical behaviour has no tests, I write tests that capture how the system behaves today. They tell us if the upgrade changes something it shouldn't.
3. Upgrade in stages
Large jumps (for example 5.6 to 8.x) are done in sensible steps, with the application working at each stage, not in one risky leap. Dependencies and framework are upgraded alongside.
4. Fix what breaks
Removed functions, changed behaviour, deprecated features and incompatible libraries are fixed methodically, reviewed by a person and verified against the tests.
5. Test in staging
The upgraded application runs in a copy of your production environment, where you and your team can check it.
6. Controlled rollout
Deployment is planned for a low-risk time, with a rollback plan ready, followed by monitoring.
7. Handover
You receive documentation of what changed and a plan to keep the application current.
What typically breaks
Every application is different, but common culprits include:
- Removed database functions. The old
mysql_*functions disappeared in PHP 7 and need replacing. - Removed or changed language features across 7.x and 8.x, such as
each(),create_function()and changed comparison rules in PHP 8. - Deprecations in 8.1 and 8.2, including passing
nullto built-in functions and dynamic properties (creating undeclared object properties). - Abandoned third-party libraries that no longer run on modern PHP.
- Framework and CMS versions tied to old PHP.
- Server configuration, extensions and cron jobs that depend on old behaviour.
- Character encoding and date handling quirks buried deep in old code.
None of these is unusual. They are predictable once you map them before you start, which is the point of the assessment.
Upgrade, extended support, or rewrite?
| Option | When it makes sense | Caution |
|---|---|---|
| Staged upgrade | Most business applications that still do their job | Needs a safety net of tests first |
| Extended or patched-PHP support (some hosts and vendors offer this for end-of-life versions) | A short-term bridge while you plan the upgrade | Doesn't fix the underlying problem, costs money every month, and may not satisfy auditors |
| Rewrite | The application no longer fits the business, or the code is beyond saving | Expensive, slow and risky; it can lose years of embedded business logic |
I'll tell you honestly which fits your system. Rewrite vs refactor vs upgrade
Frameworks and platforms
PHP upgrades often have to happen alongside a framework or CMS upgrade. I work with custom PHP and with framework-based applications, including Laravel, CodeIgniter, Zend/Laminas, Symfony, CakePHP, Yii and Drupal. If you have something else, ask. Laravel upgrades
What it costs
Fixed price, after assessment. I can't honestly quote an upgrade for a system I haven't seen. The usual route:
- Free conversation to understand the situation
- Legacy System Assessment, from £2,500, mapping what the upgrade involves and its risks
- Fixed-price quote for the upgrade, based on the findings. You're under no obligation to continue.
What affects cost: how far behind you are, codebase size, framework and dependencies, existing tests, integrations and server complexity. Direct day rate is £950, with urgent recovery work from £1,300. Full pricing
For agencies
Got a client on PHP 5.6 that your team would rather not touch? I can run the upgrade white-label or take the work directly with you as referrer. Agency terms
Frequently asked questions
How long does a PHP upgrade take?
It depends on the size, age and complexity of the application. I'll confirm a timeline in the fixed-price quote once I've assessed the system. A well-contained application can be quick, while a large one with no tests and abandoned dependencies takes longer.
Which PHP version should we upgrade to?
The newest version that your framework and dependencies support, usually 8.3, 8.4 or 8.5. Upgrading to a version with a long support window means you won't be back in the same position next year.
Will the website go down during the upgrade?
Not for the build. The work happens on a copy. The final switch is planned for a quiet time with a rollback ready, so downtime is minimal and controlled.
My host says they'll drop my PHP version. How urgent is it?
Ask them for the exact date. If it's within weeks, tell me now, since we may need a short-term plan first. Server and hosting migration
Can you upgrade it without tests or documentation?
Yes, that's the normal starting point. Building the safety net is part of the job.
Do I have to upgrade all the way in one go?
No. The work is staged. If budget is tight, we can prioritise the highest-risk systems first.
Is it better to just rewrite?
Rarely. Occasionally, yes, and I'll tell you if so. But a rewrite usually costs far more and takes far longer than a staged upgrade, and risks losing business logic nobody remembers.
Tell me what you've inherited.
Tell me your PHP version, your framework and what's worrying you. I'll tell you honestly what an upgrade involves.
Book a free conversationLegacy System Assessment, from £2,500