By Greg Nowak. Updated 9 September 2026.
If your website or internal system still runs PHP 5, the difficult part of upgrading is usually discovering what might stop working. Orders, customer accounts, scheduled exports and custom integrations all need to survive the change. For a business owner or agency inheriting the system, that uncertainty makes the project hard to price and approve.
A useful migration plan turns those unknowns into decisions: what to keep, which dependencies to replace, what to test and who can authorise launch. PHP 7 can sometimes help diagnose old code along the way, but the production destination should be a supported PHP 8 release.
Choose the destination before planning the bridge
Every PHP 5 and PHP 7 branch is unsupported by the PHP project. PHP 7.4 reached end of life on 28 November 2022, according to PHP’s unsupported branches register.
As of September 2026, PHP 8.2 through 8.5 remain supported. However, 8.2 receives security fixes only until 31 December 2026. PHP 8.4 has security support through December 2028, and 8.5 through December 2029. Check the official support schedule when agreeing the target.
My starting shortlist would be PHP 8.4 or 8.5, subject to the CMS, framework, hosting and extensions supporting it. If a required component blocks both, give that dependency its own replacement or upgrade plan. Otherwise, the project can finish with another urgent migration already approaching.
Decide whether to migrate or replace
A small brochure site with abandoned plugins may be cheaper to replace. A bespoke ordering system may contain business rules that would be expensive to rediscover. Compare the cost of preserving those rules with the cost of rebuilding them, including data migration and staff retraining.
| Starting position | Practical route | First deliverable |
|---|---|---|
| CMS with a maintained upgrade path and little custom code | Follow the CMS upgrade sequence, then test on supported PHP 8 | Compatible core and extension list |
| Custom application with valuable business logic | Migrate in reviewed batches; use isolated PHP 7 testing if helpful | Dependency map and phased estimate |
| Revenue-critical system with few tests | Capture essential workflows and rehearse recovery before release | Acceptance checklist and rollback plan |
| Small application built around abandoned components | Compare replacement with migration, including data export | Costed recommendation |
Ask for a bounded discovery phase before committing to the full build. Its output should identify blockers, assumptions, scope and acceptance criteria. That gives owners a basis for approving spend and agency teams a clearer boundary for delivery.
Inventory the application and its dependencies
Record the PHP version, operating system, database, web server, extensions, CMS or framework, custom code, libraries, cron jobs and integrations. Ask operations staff about occasional tasks: a monthly export deserves a test even if nobody uses it during a normal demonstration.
These commands identify the command-line PHP environment:
php -v
php --ini
php -mCheck the web server’s PHP configuration separately; it can differ from the command line. For a Composer-managed project, inspect a working copy using a tooling environment that supports your Composer version:
composer validate
composer outdated --direct
composer prohibits php 8.4
composer audit --lockedReplace 8.4 with your target. The Composer CLI documentation explains these checks: declared dependency blockers and reported vulnerabilities help define the work, but do not prove application compatibility. The locked audit requires a lock file; use composer audit to inspect installed packages instead.
After installing the proposed dependencies under the target runtime, run:
composer check-platform-reqsThis checks actual PHP and extension requirements, ignoring Composer’s simulated config.platform setting. Keep dependency updates reviewed and reproducible in the lock file; avoid an unplanned composer update on production. Libraries copied into the project manually need a separate inventory.
When does PHP 7 help?
A temporary PHP 7.4 environment can help separate earlier compatibility failures from later ones. PHP’s PHP 7 migration notes document changes including removal of mysql_* and ereg* functions and changes to error behaviour.
Use that checkpoint only when it makes diagnosis easier. Keep it private, short-lived and disconnected from live payment, email and customer systems. If the application’s upgrade path supports moving directly to your PHP 8 target, skip the intermediate runtime. Either route still requires reviewing the migration notes for the versions crossed.
Scan the code, then test the business
PHPCompatibility can flag version-sensitive code without running the application. Install it according to its current instructions in a suitable development environment; the scanner can run on a newer PHP version than the code being inspected. With the standard registered, a scan for PHP 8.4 could be:
vendor/bin/phpcs -ps /path/to/application \
--standard=PHPCompatibility \
--runtime-set testVersion 8.4Replace the path and target. Use 7.4-8.4 only if the code must support that whole range, rather than to describe the migration journey. Coverage is incomplete, so treat findings as a work list. Authentication and encryption changes need particular care to preserve access to existing accounts and data.
On production-like staging with sanitised data, separate storage and sandbox integrations, test complete workflows:
- Sign in, reset passwords and check permissions.
- Submit forms, upload files and verify email delivery.
- Place orders, process test payments, refund and generate invoices.
- Run scheduled jobs, queues, imports, exports and API integrations.
Record expected results and have the staff responsible for those processes approve them.
Make launch and recovery part of the scope
Agree the deployment window, decision-maker, rollback triggers and monitoring owner. Rehearse restoring files and data. If customers can create orders after launch, decide how those transactions will be preserved or reconciled during rollback; restoring an older database can lose them.
Finish with documented dependencies, repeatable deployment and an owner for ongoing updates. If you need help choosing between migration and replacement, discuss your PHP system with Greg. Share the current version, what the application does and any hosting deadline to give the assessment a practical starting point.
Related on GrN.dk
- MariaDB 10.6 EOL: quiet CMS hosting debt needs a real upgrade plan before July 2026
- Microsoft Access Database Resources: When to Fix, Split, or Replace Your System
- PHP 8.2 Is Near End of Life: A Practical Upgrade Plan for CMS Hosts
Need help with this kind of work?
Discuss your PHP migration with Greg Get in touch with Greg.
