# PHP Upgrade and Modernisation UK

Source: https://dijituldevelopments.co.uk/php-upgrade-modernisation/
Updated: 2026-10-10

> dijitul developments upgrades PHP applications for UK businesses: moving custom systems, Laravel, Symfony, CodeIgniter, WordPress, OpenCart and Magento sites from PHP 5, 7 or early PHP 8 to a supported version such as PHP 8.4 or 8.5, with tests and automated refactoring so nothing breaks quietly. Every upgrade is a fixed-price quote after a free chat.

## Problems this solves

- Your host has warned that your PHP version is going away or now costs extra
- The site shows deprecation warnings or white screens after a server update
- A plugin, extension or library you rely on no longer supports your PHP version
- Your app uses old mysql_* functions or other removed features
- An auditor, insurer or customer has flagged unsupported software
- Nobody wants to touch the upgrade because there are no tests

## Key facts

- According to php.net, PHP 8.1 reached end of life on 31 December 2025 and PHP 7.4 on 28 November 2022
- PHP 8.2 security support ends on 31 December 2026, so 8.2 is a short-term stop, not a target
- PHP 8.4 has security support until 31 December 2028 and PHP 8.5 until 31 December 2029 (php.net)
- Each PHP branch gets two years of active support and two further years of security fixes only
- We use Rector for automated refactoring and PHPStan plus PHPCompatibility to find breakages
- Framework and extension upgrades are planned alongside the PHP version
- We have worked with PHP since the CubeCart, OpenCart and KashFlow integration days

## 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:

| PHP branch | Active support until | Security support until |

| 7.4 | End of life 28 Nov 2022 |
| 8.0 | End of life 26 Nov 2023 |
| 8.1 | End of life 31 Dec 2025 |
| 8.2 | 31 Dec 2024 | 31 Dec 2026 |
| 8.3 | 31 Dec 2025 | 31 Dec 2027 |
| 8.4 | 31 Dec 2026 | 31 Dec 2028 |
| 8.5 | 31 Dec 2027 | 31 Dec 2029 |

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

- **Get the code into Git** and set up a local and staging environment, usually with Docker, on both the current and target PHP versions.
- **Scan** with PHPCompatibility for PHP_CodeSniffer and PHPStan to list every incompatibility and likely bug.
- **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.
- **Refactor** with Rector, which applies known upgrade rules automatically, then review every change by hand.
- **Upgrade dependencies** through Composer, replacing abandoned packages.
- **Test on staging** with real workflows and a copy of live data, with deprecation logging turned on.
- **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.

## 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 or modernise?

Sometimes an upgrade is all that is needed. 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 report listing every issue found for the target PHP version
- 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

Technologies: PHP 8.4, PHP 8.5, Rector, PHPStan, PHPCompatibility, Composer, Laravel, Docker

## FAQs

### Which PHP versions are still supported?

According to php.net, checked in October 2026, PHP 8.2, 8.3, 8.4 and 8.5 are supported. PHP 8.2 gets security fixes only until 31 December 2026, PHP 8.3 until 31 December 2027, PHP 8.4 until 31 December 2028 and PHP 8.5 until 31 December 2029. PHP 8.1 and older are end of life.

### What happens if we stay on an old PHP version?

Your site keeps running, but it gets no security fixes, hosts gradually withdraw or charge for old versions, and libraries stop supporting it. The longer you wait, the bigger the eventual jump. dijitul developments can tell you how much work an upgrade involves after a quick review.

### Can you upgrade from PHP 5 straight to PHP 8?

Yes. We usually go straight to the target version rather than stepping through each release, using Rector, PHPStan and PHPCompatibility to find and fix every change between them, backed by tests. Very old code may also need its database layer and framework replaced.

### Will our site go down during a PHP upgrade?

It should not. dijitul developments does the work on a separate staging environment running the new PHP version, tests it with real workflows, and switches live over at a quiet time with a rollback plan. The cut-over itself is usually a short configuration change.

### Can you upgrade an old OpenCart or WordPress site?

Yes. We check every extension and plugin against the target PHP version, update or replace those that are abandoned, and fix custom code. dijitul developments has worked with OpenCart, CubeCart and WordPress extensions for many years, so we know where the usual problems are.

### How is a PHP upgrade priced?

dijitul developments quotes a fixed price after a free chat and a compatibility scan of your code, which shows how many issues there are. For large or very old systems, the upgrade may be split into phases, each with its own fixed price.

## Pricing and contact

Every project gets a fixed-price quote after a free initial chat and a short scoping stage. You own the code and the data. Book a free chat: https://dijituldevelopments.co.uk/contact/ · 01623 650333 · info@dijitul.uk