PHP end-of-life dates and the upgrade path from 5.6 to 8.5

Start with the branch your server runs. The first table tells you when it stopped getting fixes. The second table starts at that branch and lists every set of changes between you and your target, in order. Each row links to the migration guide on php.net, which is the complete list. We picked the items that most often matter in ordering, billing and portal systems, the kind of software we are usually asked to move.

To find out what you are running, check the version on the server itself, not on a developer’s laptop.

php -v
php -m          # loaded extensions, including mysql or mcrypt
composer why-not php 8.5   # which packages block a target version

These are the dates php.net lists on its unsupported branches page. After this date a branch gets no releases at all, security or otherwise.

Each branch gets two years of active support and two more of security fixes, four years in total, under the php.net support policy. Today only 8.4 and 8.5 still get routine bug fixes, and 8.4 loses them at the end of this year.

If you are choosing a target now, 8.5 gives the longest runway. Check that your framework and packages support it first. WooCommerce, for example, says it is tested up to PHP 8.4, so a store may sensibly stop one version short.

Read downwards from your version. The date is when the branch you are leaving reached, or will reach, the end of its security support. Items marked deprecated still run on that version.

5.6 to 7.0: the database layer

The removal of the mysql extension is simple to describe and slow to do. Every query has to move to mysqli or PDO, and if you are touching them anyway it is the moment to switch to prepared statements. Old code often builds SQL by joining strings, so this step is also a security improvement. Budget for reading every query, not for a search and replace.

7.1 to 7.2: mcrypt

PHP deprecated mcrypt in 7.1 and moved it to PECL in 7.2, recommending OpenSSL or Sodium. The code change is small. The real work is any data already encrypted with it: card tokens, stored passwords or personal details have to be decrypted and re-encrypted, and each cipher and padding choice has to be matched exactly. Find this early, because it can’t be fixed by a tool.

7.4 to 8.0: comparisons that change without an error

Most breaks announce themselves. The change to string and number comparison doesn’t. Where old code compares a number with text loosely, the result can flip while the page still loads. This is why tests or a side-by-side run matter more at this step than at any other. On systems with no tests, we write them around the money and permission logic before moving.

8.0 to 8.2: the noise

The null-parameter deprecation in 8.1 and the dynamic-property deprecation in 8.2 don’t stop anything, but in older code they can produce a large volume of log entries. Turn on logging, count them by location, and fix them in batches. Silencing them hides the warning you will need when a later version removes the behaviour.

Installing each version in turn is rarely worth it on a large jump. A practical sequence for an in-place upgrade is this:

1. Fix the database layer and any mcrypt use while still on the old version, if the code allows it.
2. Move to the latest 7.x you can, and clear what its deprecation notices tell you.
3. Add tests or a parallel run around the logic that handles money, stock and permissions.
4. Move to the target version, using static analysis and automated refactoring tools for the repetitive changes.
5. Run old and new side by side on real workflows before you cut over.

On a system with a framework that is itself out of support, moving PHP alone may not be possible, because the framework won’t run on the new version. Then the choice becomes a framework upgrade or a re-platform, which we cover in rewrite or upgrade. For the full route from PHP 5.6, see what breaks going from 5.6 to 8.

Laravel sets its own PHP floor, so the framework version can decide your target. Support dates below come from our Laravel versions page.

If your system is already on Laravel and only the runtime is behind, read PHP 8.1 end of life and Laravel instead. This matrix is aimed at custom PHP and older frameworks.

We moved a cabinet manufacturer’s ordering, dealer-portal and inventory system from PHP 5.6 and MySQL 5.0 to Laravel 13 on PHP 8.5 and MySQL 8, which is the full length of this table. It took about eight months. We also re-platformed a loyalty-card system we had first built on PHP 5.6 onto Laravel in two months. Separately, we moved a live Belgian WooCommerce store from PHP 7.4 to the current release during a maintenance engagement. Most of our work is delivered under NDA, so many projects cannot be named.

If you want this done for you, our legacy PHP modernisation service starts with an assessment of your code. For wider PHP work, see PHP development.