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

By Greg Nowak. Last updated 2026-06-21.

If you have an old PHP 5 site, the risky part is rarely the button or server setting that changes the runtime. The risky part is everything around it: abandoned packages, removed extensions, forgotten cron jobs, untested payment flows, and code paths that only a customer finds. A PHP 5 to PHP 7 upgrade should be handled as a controlled migration, not a quick hosting switch.

There is also an important 2026 update to the original advice: PHP 7 is no longer a safe final destination. PHP 7.0 reached end of life in January 2019, and PHP 7.4 reached end of life in November 2022. If the internal task still says "upgrade PHP 5 to PHP 7", treat PHP 7 as a temporary compatibility bridge in staging. The business goal should be a supported PHP 8 branch that your host, CMS, framework, plugins, and extensions can run reliably.

Start with an inventory, not code edits

Before rewriting anything, make a short technical inventory. Capture the current PHP version, enabled extensions, framework or CMS version, Composer dependencies, custom modules, scheduled jobs, payment providers, form handlers, search, email, and integrations. For an agency inheriting a site, this inventory is often the difference between a scoped migration and an open-ended rescue job.

Useful first checks include:

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

If the project does not use Composer, list the libraries and plugins manually. That is slower, but it is still better than discovering a business-critical dependency after deployment. The Composer prohibits command is especially useful because it shows which packages block a target PHP version.

Use staging as a diagnostic tool

The old advice to copy the site to a PHP 7 server and see what happens is still useful, but only as a diagnostic step. Do it on a staging copy with a separate database, production-like configuration, detailed error logging, and no real customer traffic. A successful page load is not the same as a successful migration.

In practice, many legacy projects move through three stages: first make PHP 5.6 code explicit and testable, then use PHP 7.4 in staging to flush out older compatibility problems, then move to a supported PHP 8 version. PHP 7.4 itself is end of life, so it should not become the new production home. It is a stepping stone when jumping straight from PHP 5 to PHP 8 would hide too many problems at once.

Situation	Recommended route	Commercial reason
Small brochure site or simple CMS	Clone to staging, update CMS/plugins, test on supported PHP 8	Fastest route if the stack is still maintained
Custom PHP 5 application	Scan, patch removed APIs, test on PHP 7.4 staging, then PHP 8	Reduces unknowns without accepting an unsupported runtime
Revenue-critical site with few tests	Add smoke tests, logs, backups, and rollback before changing runtime	Protects orders, leads, and internal workflows
Agency-inherited legacy project	Sell an audit and migration plan before quoting the full rebuild	Creates clarity before the riskiest work begins

A practical decision matrix for choosing the migration route before changing production PHP.

Fix the usual PHP 5 breakpoints

Automated scanning helps, but it does not replace judgment. PHPCompatibility for PHP_CodeSniffer can flag many cross-version issues. After installing the standard in the project, a useful scan looks like this:

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

Expect to find old database calls, removed functions, error-handling assumptions, and syntax that relied on PHP 5 quirks. The classic mysql_* extension must be replaced with mysqli or PDO. Old ereg calls should move to preg_*. Mcrypt-era encryption needs a proper review rather than a mechanical replacement. Custom exception handlers may also need attention because PHP 7 changed how many fatal errors are represented, and modern PHP versions are stricter again.

Do not fix everything as one giant commit. Group changes by risk: dependencies first, removed APIs next, runtime errors after that, then warnings and cleanup. Keep the site shippable between steps. For business owners and operations teams, this matters because it gives you decision points. You can pause after the audit, after staging passes, or after the first production-safe milestone.

Plan the release like an operational change

A good migration plan includes a deployment window, a database backup, a file backup, a tested rollback path, and a short acceptance checklist. Check login, checkout, contact forms, search, admin screens, scheduled jobs, file uploads, emails, redirects, API calls, and any reporting jobs the team depends on. Watch error logs during and after launch, not just the homepage.

The practical outcome is not "the site runs on PHP 7". The outcome is a legacy PHP system that has been moved onto a supportable path, with fewer hidden risks and a clearer maintenance future. If your team is dealing with an inherited PHP 5 site and needs a calm upgrade plan, contact Greg about an audit, migration plan, or hands-on implementation support.