PHP2Shell showed that end-of-life PHP gets no official fix, only source backports or a vendor's long-term support branch. We audit your codebase, upgrade it to a supported PHP version and prove nothing broke along the way.
We scan your codebase for deprecated functions, dynamic properties and outdated framework or plugin versions before a single line changes.
Every upgrade runs on a staging copy first, with a documented rollback plan ready in case anything unexpected surfaces on go-live.
You work with one engineer who understands your application's history, not a rotating queue that needs re-briefing every time.
PHP's own release cycle gives each major version roughly two years of active support, then around a year of security-only fixes before it reaches end of life. PHP 7.4, 8.0 and 8.1 are all now past that point. When the PHP2Shell vulnerabilities were patched on 21 October 2026, fixes landed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 - PHP 8.1 and older received nothing official at all, as we covered in our earlier news piece on the vulnerability.
That gap isn't unique to PHP2Shell. Every end-of-life PHP version will eventually sit exposed to whatever the next critical bug turns out to be, with no official patch coming regardless of how severe it is. A PHP version upgrade UK businesses keep postponing doesn't get safer by waiting - it accumulates more risk and, usually, more work to fix later. Our PHP2Shell explainer sets out why this particular bug affected PHP core itself rather than any one application.
Businesses rarely delay an upgrade through choice. Usually it's a legacy PHP application upgrade that feels too risky to touch - a custom build with no test coverage, a framework pinned to an old version because a plugin depends on it, or simply no one left who remembers how the site was put together in the first place.
Treated as a planned project with a proper audit, staging environment and rollback plan, upgrading from PHP 8.1 to 8.3 is routine work. Treated as an emergency after the next vulnerability lands, it's considerably more disruptive - which is exactly the position PHP2Shell put a lot of unpatched sites in overnight.
A PHP version upgrade sold cheaply often means little more than flipping a version number and seeing what breaks. Proper upgrade work is broader than that, and the difference shows up at exactly the wrong moment - when a deprecated function silently changes behaviour instead of throwing an obvious error.
We scan your codebase for deprecated and removed functions, dynamic property deprecations and type coercion changes introduced between your current version and the target - the detail that turns an upgrade into a rewrite if it's missed.
Laravel, Symfony, WordPress, Magento and custom builds all carry their own dependency chains. We check every plugin, module and theme your application relies on against the PHP version you're moving to before touching production.
The upgrade runs against a mirror of your live environment first, with full regression testing, so issues surface on staging rather than in front of your customers.
A scheduled cutover window, agreed with you in advance, backed by a documented rollback plan so the upgrade can be reversed quickly if something unexpected appears after go-live.
The PHP security team published minimal source backport branches for 7.4, 8.0 and 8.1 after PHP2Shell, and some Linux distributions and LTS vendors offer similar cover. These only patch the issue that's already been found, not whatever comes next - we'll set one up if you genuinely can't move yet, but we'll always say plainly that it buys time, not security.
We sequence the upgrade by risk, testing your most fragile integrations first and scheduling the cutover outside business hours, so the upgrade itself doesn't become the outage you were trying to avoid.
From first conversation to a live upgrade on a supported PHP version - our process keeps things simple.
We scan your codebase for deprecated functions, dynamic properties and outdated framework or plugin versions against your target PHP release.
We build a staging copy on the target PHP version and fix what breaks there, before anything touches your live application.
We run through your core user journeys together with you, so you can see the upgrade working before it goes live.
A scheduled cutover with a documented rollback plan ready, plus close monitoring immediately afterwards to catch anything that only shows up under real traffic.
We start every upgrade with a code compatibility audit, not a version-number swap, so you know what will break before we touch anything.
You get a named engineer who understands your application's history, rather than a generic queue that needs re-briefing on your setup every time.
We work across Laravel, Symfony, WordPress, Magento and custom PHP builds, including sites built through our own WordPress website design work and sites we didn't originally build.
Every upgrade runs on staging first, with full regression testing and a documented rollback plan agreed before the live cutover, not improvised afterwards.
We're honest about backports and LTS patches - useful if you genuinely can't move yet, but we'll always say plainly that they're a stopgap, not a destination, and point you towards emergency PHP patching only where it's truly needed.
Once you're upgraded, we can fold ongoing patching into our website maintenance services, so your application doesn't quietly drift back towards end of life in a couple of years.
If you're working towards Cyber Essentials, an unsupported PHP version is a blocker we see often - we'll tell you honestly if an upgrade is the fix, or if the underlying application needs more than that.
Every upgrade is scoped to your application's size and framework - here's a rough guide to where most businesses land.
A single CMS or small application on one PHP version
Laravel, Symfony or similar with plugin and module dependencies
Multiple sites, custom integrations or heavily customised legacy code
We treat an ageing PHP application as a project to get right, not a quick version bump. Here's what sets our upgrade work apart.
We find what will break before we touch production, not after.
Every upgrade comes with a documented way back, agreed before go-live, not improvised under pressure.
We can fix what the audit finds, not just flag it and leave the work to you.
Laravel, Symfony, WordPress, Magento or custom PHP - we work across all of them, not one narrow stack.
One engineer owns your upgrade end to end, rather than a ticket queue that starts from scratch each time.
Full regression testing runs before the cutover, reducing the risk of surprises once you're live.
You continue to own your code and infrastructure outright, with nothing proprietary locking you into our service.
An upgrade is scoped, delivered and signed off - you're not tied into an ongoing contract to get it done.
A clear, plain-English record of what was found, what changed and what to watch, with no jargon-filled changelog.
We deliver a PHP upgrade service to businesses across the UK remotely, so your location doesn't change the level of attention your application receives. Whether you're running WordPress, Laravel, Symfony, Magento or a custom build, we scope the upgrade around your actual codebase and dependencies rather than a one-size-fits-all checklist. Because we also provide broader IT support and managed services, we can look at the hosting and server environment around your application too, not just the code itself.
This matters because a PHP upgrade rarely happens in isolation. A server still running an unsupported operating system, a hosting plan with no staging slot, or a dependency with its own end-of-life date can all complicate an upgrade that looks straightforward on paper. We look at the environment the application runs in as part of any proper upgrade, not just the code a visitor never sees.
Businesses generally choose between a few approaches once a PHP version reaches end of life, and it's worth being honest about the trade-offs of each.
Do nothing: the cheapest option in the short term, but PHP2Shell demonstrated exactly what that risk looks like in practice - an unauthenticated, application-agnostic vulnerability with no official fix available for PHP 8.1 and older.
A source backport or LTS vendor patch: keeps a legacy application running and patches the specific issue that's already been found, but it isn't a long-term plan - it covers yesterday's bug, not tomorrow's.
An in-house upgrade attempt: possible with the right time and testing discipline, but without a dedicated audit and rollback plan, deprecated functions and dependency conflicts tend to surface as live bugs rather than caught issues.
A managed PHP upgrade service: a compatibility audit, staging environment, full testing and a rollback plan, ending with your application on a version that has genuine support ahead of it rather than behind it.
Coverage
We upgrade PHP applications for businesses across the UK remotely, with London-based on-site availability for businesses that want a face-to-face meeting.
php upgrade service
A compatibility audit, staging upgrade, testing and rollout that moves a legacy PHP application onto a supported, actively patched version.
legacy php application upgrade uk
A PHP version upgrade service delivered remotely across the UK, covering WordPress, Laravel, Symfony, Magento and custom applications.
Got questions about our PHP upgrade service? We've answered the most common ones below. If you need more detail, get in touch.
Run php -v on the server or check your hosting control panel - but the CLI version can differ from what your web server actually runs, so we check the live PHP-FPM or Apache module version, not just the command line.
It can if it's rushed. That's why we run a compatibility audit and a staging upgrade first, so deprecated functions and dependency conflicts are found and fixed before your live site is touched.
A source backport patches a known issue on an end-of-life PHP version without moving you forward. It's a reasonable stopgap if you genuinely can't upgrade yet, but it leaves you exposed to the next vulnerability - moving to PHP 8.3 or 8.4 is the actual fix.
PHP 8.3 or 8.4 currently gives you the longest runway of active and security support, rather than upgrading to the oldest version that happens to run your code.
Yes, along with custom-built PHP applications. We confirm framework and plugin compatibility with the target PHP version during the audit stage.
We agree a documented rollback plan before go-live, so if anything unexpected surfaces we can revert quickly while we fix the underlying issue, rather than leaving your site broken.
It depends on the size and age of the application - a small site can be scoped and upgraded in days, while a larger legacy estate with multiple dependencies takes longer. We give you a timeline after the audit.
Yes - many clients combine a PHP upgrade with our website security hardening service, so the application and the server underneath it are both brought up to date together.
Yes. Cyber Essentials requires supported software with critical patches applied promptly, and an end-of-life PHP version with no official fix available doesn't meet that bar.
Early action costs far less than emergency work after the next vulnerability
We believe that communication is key to any successful project. Tell us about your application and one of our team will be in touch to scope the upgrade.
Tell us about your application and one of our team will be in touch to scope the upgrade
Powered by industry-leading technologies including SolarWinds, Cloudflare, BitDefender, AWS, Microsoft Azure, and Cisco Meraki to deliver secure, scalable, and reliable IT solutions.
22 Oct, 2026
Fixed wireless access delivers business internet over radio rather than a cable into the building, and for many UK businesses it is a genuine primary...
21 Oct, 2026
Row-level security reporting means building dashboards that show each person only the rows of data they are entitled to see their own region, their own team,...
20 Oct, 2026
Good LLM integration architecture is what separates an AI feature that keeps working for years from one that becomes a maintenance burden within months. The...