PHP 5.6 to PHP 8: what breaks, and four ways off

1. The application doesn’t start

PHP 7.0 removed the mysql, ereg, mssql and sybase_ct extensions, so the first page that touches the database dies. Search your code to see how much this covers.

grep -rnE "mysql_[a-z_]+\(|ereg(i)?(_replace)?\(|split\(|mcrypt_" --include="*.php" .

PHP 8 itself also rejects some old forms outright: create_function() and each() have gone, and a method named after its class is no longer a constructor. That last one matters in old PHP 4 style classes, because the object is simply created without the setup you expected.

2. Pages start, then stop part way through

Many fatal errors became exceptions in PHP 7, so custom error handlers may no longer fire. Calling a function with too few arguments throws from 7.1. Calling count() on something that can’t be counted warns from 7.2 and throws a TypeError from 8.0. Older code tends to do this on database results that came back empty, so it fails only when there is no data, which is the case nobody tested.

3. Everything appears to work, but some results are different

This is the expensive group, because nothing tells you. The main ones:

• Loose comparison. In PHP 8, 0 == "foo" is false where it used to be true. Status checks and rule tables built on loose comparison can take a different branch.
• Random numbers. From 7.1, rand(), shuffle() and array_rand() give different output for the same seed. That matters if you stored or relied on a seeded sequence.
• Array iteration. foreach no longer moves the internal array pointer, and list() assigns in a different order, so code that depended on either behaves differently.
• Database types. From 8.1, PDO returns native integers and floats for MySQL, so a strict comparison against a string starts to fail.
• Case conversion. From 8.2, strtolower() and its relatives are ASCII-only, which changes results for accented names if your code relied on a locale.

4. Data you can’t read any more

Check for mcrypt, which left core in 7.2. Anything stored with it has to be decrypted and re-encrypted, and that is best planned while the old system can still read it. Also check character encoding: old systems on MySQL 5 are often latin1 at the database level with UTF-8 text inside. Our MySQL 5 to 8 checklist covers this.

For every step in between, see the full PHP upgrade matrix.

Published durations for this work are rare, so here are ours. Both are re-platforms, and they sit at very different ends of the range.

• Loyalty-card system, two months. We had built the original on PHP 5.6 ourselves, so we already knew the code. We rebuilt it on Laravel, migrated the data, and kept every card, balance and rule.
• Cabinet manufacturer, about eight months. Ordering, quoting, dealer portal and inventory moved from PHP 5.6 and MySQL 5.0 to Laravel 13, PHP 8.5, MySQL 8 and a new Next.js front end. We audited the code and schema first, validated data at every step of the migration, and checked each workflow against the old system running in parallel.

The gap between them isn’t only size. We already knew the loyalty system’s code, and the cabinet project’s scope also took in a database move and a new front end. Don’t read either as a benchmark. Our rewrite or upgrade comparison looks at what drove the difference, and the cost guide has our published prices.

1. Are the business rules correct? If yes, keep them, which rules out a redesign. If people work around the system every day, an upgrade only preserves the problem.
2. Can you tell when something has broken? Without tests, a side-by-side run or people who can check results, an in-place upgrade is riskier than it looks.
3. Can you hire for what you end up with? The cabinet manufacturer’s system was impossible to hire for. Moving to a supported runtime without moving off an unusual codebase may not solve that.

If you want someone else to run this, see our legacy PHP modernisation service. If your system is already Laravel, however old, Laravel rescue is likely a better starting point.