PHP Upgrade and Modernisation UK

PHP2Shell: a good prompt to plan your upgrade

PHP2Shell is the name given to two flaws in the PHP interpreter itself, CVE-2026-109618 and CVE-2026-109619, which became public on 20 and 21 October 2026. The PHP security team rates both Critical, with a CVSS v4.0 score of 9.2. Official fixes came out on 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older are end of life, so there is no official release for them.

That does not mean an older application has to come off the internet tomorrow. It can keep running on protected hosting, with Cloudflare's firewall in front, a security extension that closes the known attack path on old PHP versions, hardened settings and each site isolated. Those layers are mitigations rather than an official fix, so moving to a supported version is still the best long-term position. PHP2Shell is a sensible moment to find out what that move would involve, and to do it on your own timetable.

Our guide, running an old PHP app after PHP2Shell, sets out the choices: keep it running safely now, upgrade when it makes business sense, or rebuild if the application is at the end of its life anyway. The NCSC alert covers what UK organisations should check.

PHP support dates that matter now

Each PHP release branch gets two years of active support, with bug and security fixes, followed by two years of security fixes only. After that it is end of life and gets no fixes at all. These are the current dates from the official php.net supported versions and end of life pages, checked in October 2026:

If you are on 8.2 or older, the practical target is PHP 8.4 or 8.5, depending on whether your framework, extensions and host support it yet. Some Linux distributions backport security fixes to older PHP packages for longer, but that only covers PHP itself, not the frameworks and libraries your application uses.

What breaks when you upgrade

Most upgrade work is finding and fixing a known set of changes. The ones we meet most often:

• PHP 7.0 removed the old mysql_* functions, so very old code needs moving to PDO or mysqli
• PHP 8.0 removed each() and create_function(), changed how strings and numbers compare, and turned many warnings into errors
• PHP 8.1 deprecated passing null to non-nullable parameters of built-in functions, which shows up all over older code
• PHP 8.2 deprecated dynamic properties, common in older frameworks and plugins
• PHP 8.4 deprecated implicitly nullable parameter types

Deprecations do not break anything on the day, but they become errors in a later version, so we fix them as part of the upgrade rather than leaving a backlog.

How we do it safely

1. Get the code into Git and set up a local and staging environment, usually with Docker, on both the current and target PHP versions.
2. Scan with PHPCompatibility for PHP_CodeSniffer and PHPStan against PHP 8.2 to 8.5 to list every deprecated or removed function, every incompatibility and every likely bug.
3. Write tests for the paths that matter most: login, checkout, invoicing, imports, integrations and reports. Where there were no tests before, these are characterisation tests that record current behaviour.
4. Refactor with Rector, which applies known upgrade rules automatically, then review every change by hand.
5. Upgrade dependencies through Composer, replacing abandoned packages.
6. Test on staging with real workflows and a copy of live data, with deprecation logging turned on.
7. Cut over at a quiet time with a rollback plan, then watch the logs closely afterwards.

The server side of an upgrade

Code is only half of a PHP upgrade. The other half is the server, and it catches people out. We check the PHP extensions your application needs are available for the new version, compare php.ini settings such as memory limits, upload sizes and timezone, and configure OPcache and PHP-FPM pools sensibly. Cron jobs and queue workers often call a specific PHP binary by path, so they can quietly keep running the old version, or fail, after the web server has moved. We find and update each one.

Where the host allows it, we run the old and new PHP versions side by side on the same server, so the switch is a configuration change that can be reversed in moments. If your host cannot offer a supported PHP version at all, we can help you move as part of the project. Our sister company dijihost runs both supported PHP versions and protected older ones, so the old application can stay up safely while the upgraded one is tested.

Frameworks and platforms

Often the PHP version cannot move without the framework or platform moving too. We plan these together:

• Laravel: stepping through major versions with the official upgrade guides, or jumping several with Rector rules and careful testing. See Laravel development.
• Symfony, CodeIgniter 3 to 4 and Zend Framework to Laminas migrations
• WordPress and WooCommerce plugins that need updating or replacing
• OpenCart, CubeCart and Magento extensions, which we have been working with since the early days of those platforms
• Custom PHP with no framework, where we may introduce Composer autoloading and structure as part of the work

Upgrade, modernise or rebuild?

Sometimes an upgrade is all that is needed. Sometimes the audit shows that most of the code would have to change anyway, the framework is long abandoned, and the application no longer fits how the business works. In that case a rebuild on current Laravel and PHP 8.4 or 8.5 can be the better investment, and we will price both so you can compare. Sometimes it reveals that the application needs more than a version bump, and a staged legacy modernisation is the better investment. If you are not sure what you have, a code audit will tell you before you commit. Once upgraded, regular maintenance keeps you on supported versions so you do not face a big jump again. Get in touch for a free chat.

What we deliver

• A compatibility audit against PHP 8.2 to 8.5, listing every deprecated or removed function and every blocking library
• Automated refactoring with Rector, reviewed by a developer
• Framework, library and extension upgrades to supported versions
• Characterisation and regression tests for the critical paths
• A staging environment on the target PHP version for testing
• A planned cut-over with rollback, then monitoring for runtime warnings
• A Composer-managed dependency setup if the project did not have one
• A costed rebuild option alongside the upgrade, where an upgrade is not worth it

How it works and what it costs

Every project gets a fixed-price quote after a free initial chat and a short scoping stage. You own the code and the data.

1. Free chat

   Tell us the problem in plain English: what you do now, what goes wrong and what "better" looks like. No charge, no obligation.

2. Scoping

   We map the processes, systems and data involved, agree what is in and out, and write it down so there are no surprises.

3. Fixed-price quote

   You get a fixed price for the agreed scope, or a phased plan for bigger builds, so you can start small and prove it works.

4. Build and test

   We build in short stages you can see and try, test against real data, then go live carefully with a rollback plan.

5. Hand over and look after

   You own the code and the data. We can host it, support it and keep improving it, or hand it to your own team.

Related