Upgrading PHP 5: Use PHP 7 as a Bridge, Not the Destination

By Greg Nowak. Updated 23 July 2026.

If a business-critical website still runs PHP 5, changing the server version is the easy part. The real work is uncovering everything that depends on the old runtime: abandoned libraries, custom plugins, scheduled jobs, payment integrations, email delivery and code paths nobody has tested recently.

That is why an old request to “upgrade PHP 5 to PHP 7” needs reframing. Every PHP 7 branch is now unsupported; PHP 7.4 reached end of life in November 2022. As of July 2026, the supported branches are PHP 8.2 through 8.5, with 8.2 already limited to critical security fixes until the end of 2026. For most projects, PHP 8.4 or 8.5 should be the shortlist—but the correct target is the newest supported release that the application, hosting platform and required extensions can all run reliably.

First decide whether the system is worth migrating

Before estimating code changes, establish what the application does for the business. A lightly customised brochure site may be cheaper to rebuild on a maintained platform. A bespoke ordering, membership or operational system may justify a staged migration because its business rules are difficult to reproduce safely.

Record the current PHP version, web server, operating system, database, enabled extensions, CMS or framework version, Composer packages, custom modules, cron jobs, queues and external integrations. Include the people who know the operational exceptions. The undocumented monthly export or unusual refund process is often more important than the homepage.

On a controlled copy of the environment, these commands provide a useful starting point:

php -v
php --ini
php -m
composer validate
composer outdated --direct
composer prohibits php 8.4
composer audit
composer check-platform-reqs

Substitute the intended target for 8.4. Run check-platform-reqs under the target runtime because it checks the real PHP version and installed extensions, not just Composer’s configured platform. Do not run an unplanned composer update on production: dependency upgrades can introduce a second set of changes while you are still diagnosing the runtime migration.

Starting position	Sensible route	What to approve first
Maintained CMS with little custom code	Update the CMS and extensions on staging, then test directly on supported PHP 8	Compatibility check and acceptance test
Custom PHP 5 application	Inventory dependencies, scan the code, use isolated PHP 7.4 testing if it helps separate failures, then move to PHP 8	Technical audit and phased estimate
Revenue-critical system with weak test coverage	Add smoke tests, monitoring and rollback preparation before changing dependencies or runtime	Risk-reduction milestone
Small system with obsolete architecture	Compare migration cost with replacement and data export	Migration-versus-rebuild decision

A migration decision matrix for choosing the route before anyone changes production.

When PHP 7 is a useful bridge

PHP 7 can still be useful as a diagnostic checkpoint for a large custom application. Moving an isolated staging copy from PHP 5.6 to PHP 7.4 can expose one generation of removed functions and changed error behaviour before PHP 8 adds stricter typing and further incompatibilities.

But this is an engineering tactic, not a deployment destination. Keep the PHP 7 environment private, temporary and disconnected from live customer traffic. If a maintained CMS and its plugins already support PHP 8, going directly to the chosen PHP 8 release is usually simpler. An intermediate step should reduce uncertainty; it should not become another legacy platform to maintain.

Use scanners to find work—not to declare success

PHPCompatibility for PHP_CodeSniffer can identify many version-sensitive constructs. If it is installed in the project, a targeted scan might be:

vendor/bin/phpcs -ps . \
  --standard=PHPCompatibility \
  --runtime-set testVersion 7.4-8.4

Set the range to the runtimes you genuinely intend to test. The tool’s own documentation notes that coverage is not complete, so a clean report is not proof that the application works.

Common findings include removed mysql_* calls, obsolete ereg usage, mcrypt-era encryption, incompatible method signatures and code that depends on PHP 5’s loose comparisons or error handling. Treat encryption and authentication changes as design reviews, not search-and-replace jobs. Group changes into reviewable batches: dependencies, removed APIs, fatal runtime errors, behavioural differences and finally warnings or cleanup.

Test business journeys, not just pages

A homepage loading successfully proves very little. Build a compact acceptance checklist around what customers and staff actually do:

sign in, reset passwords and manage sessions;
submit forms, receive email and process file uploads;
search, place orders, pay, refund and generate invoices where applicable;
use administration screens and permission-controlled actions;
run scheduled jobs, imports, exports, queues and API integrations;
confirm redirects, cookies, logging and error reporting.

Use a production-like staging copy with sanitised data, a separate database and detailed logs. Automated tests are valuable, but a short manual walkthrough by the people who operate the system often catches assumptions that are absent from the codebase.

Release it as an operational change

Agree on a deployment window, named decision-maker, verified database and file backups, rollback trigger and post-release monitoring period. Test the rollback procedure before launch; “we have a backup” is not the same as knowing how long restoration takes or which transactions could be lost.

The successful outcome is not merely a higher version number. It is a supportable application with known dependencies, repeatable deployment, tested business journeys and a realistic maintenance path. If you have inherited a PHP 5 system and need help deciding whether to migrate, stabilise or replace it, Greg can provide a focused technical audit and a practical delivery plan.