A practical, step-by-step upgrade guide for business websites and custom PHP software — what breaks between PHP 7 and PHP 8.4, the tools that find it for you, and how to go live without downtime.
Most PHP upgrades fail for the same reason: someone switches the PHP version on the live server, the site shows a blank page or a fatal error, and the version gets switched straight back. The site then stays on an unsupported version for another year. A PHP upgrade done properly is not risky — but it has to be done in the right order, on a copy of the site, with the right tools.
Which Version Should You Target?
PHP supports each release for four years: two years of active support and two years of security fixes. PHP 8.1 reached end-of-life on December 31, 2025. PHP 8.2 reaches end of security support on December 31, 2026. PHP 8.3 is supported until the end of 2027, PHP 8.4 until the end of 2028 and PHP 8.5 until the end of 2029. For most business websites today, PHP 8.4 is the best target: it is mature, widely supported by frameworks and plugins, and gives you more than two years before the next mandatory upgrade.
Do not upgrade to PHP 8.2 in late 2026 — you would be doing all the work for barely two months of security support. Jump straight to PHP 8.4, or 8.5 if every dependency already supports it.
Step 1: Audit What You Have
- Current PHP version (php -v on the server, or phpinfo() on a private page) and the PHP extensions in use
- Framework or CMS and its version — Laravel, CodeIgniter, Symfony, WordPress, Magento, OpenCart
- Every plugin, theme, module and Composer package, with its latest version and whether it supports PHP 8.4
- Integrations: payment gateways, SMS and email APIs, ERP connectors, cron jobs and background scripts
- Server setup: Apache mod_php or PHP-FPM, OS version, and whether your host even offers PHP 8.4
Step 2: Let the Tools Find the Breaking Changes
You do not have to read every file by hand. Three free tools find most compatibility problems automatically. PHPCompatibility (a PHP_CodeSniffer standard) scans your code for functions and syntax removed or changed in your target version. PHPStan performs static analysis and catches type errors and undefined methods that PHP 8 now treats more strictly. Rector can automatically rewrite much old code into modern equivalents — run it with --dry-run first to see what it would change.
The Most Common Things That Break
- mysql_* functions — removed back in PHP 7.0; they must be rewritten to PDO or mysqli, ideally with prepared statements (which also fixes SQL injection)
- each(), create_function() and the old money_format() — removed in PHP 8.0
- Stricter type handling — passing null to many built-in string functions triggers deprecation notices since PHP 8.1, and comparisons between numbers and strings behave differently since PHP 8.0
- Dynamic properties — creating properties that were never declared on a class is deprecated since PHP 8.2
- Old plugins and libraries — often the biggest problem; abandoned WordPress plugins or Composer packages that will never support PHP 8 must be replaced
- Framework versions — very old Laravel or CodeIgniter 3 versions do not support PHP 8.4 at all, so the framework has to be upgraded along with PHP
Step 3: Upgrade on Staging, Not Production
- 1Clone the site — files and a recent copy of the database — to a staging server running the target PHP version
- 2Turn on full error reporting on staging (never on production) so every warning and deprecation is visible in the logs
- 3Update Composer dependencies, the framework or CMS core, then plugins and themes, committing each step separately so problems are easy to trace
- 4Apply Rector's automated fixes, then fix the remaining issues found by PHPStan and PHPCompatibility by hand
- 5Test every business-critical flow: login, registration, contact forms, search, checkout and payment, invoices and emails, admin screens, cron jobs and API integrations
Step 4: Go Live Safely
Pick a low-traffic window, take a fresh backup, and deploy the upgraded code together with the new PHP version. If your host lets you set the PHP version per site, switch it at the same moment as the code deploy. Keep the rollback path ready — the previous code and PHP version — and watch the error log closely for the first 48 hours. Small edge cases, such as a rarely used report or a monthly cron job, often only show up after launch.
Make the next upgrade easier: run PHP in Docker or pin the version in your deployment configuration, keep dependencies updated monthly, and add a few automated tests for your most important flows. The upgrade after this one should take days, not weeks.
How Long Does It Take?
A WordPress or small custom site with maintained plugins typically takes a few working days. A Laravel or CodeIgniter application of moderate size usually takes two to four weeks, especially if the framework also needs a major version upgrade. Large legacy systems on PHP 5.x with no tests can take one to three months, and are best upgraded module by module. If the audit shows the code is beyond saving, a migration to Python (Django or FastAPI) may be the better long-term investment.
Need Help With Your Upgrade?
Frequent Solutions upgrades PHP websites and software every week — from WordPress and WooCommerce stores to custom Laravel and CodeIgniter platforms. We start with a free compatibility audit, give you a fixed-price quote, and do all the work on staging before your site goes live on PHP 8.4.