Upgrading an Old PHP Website: Versions, Risks and a Safe Plan

PHP still runs a large share of the web, including most WordPress sites and a long tail of custom business systems built in the 2010s. The language itself is in good shape: PHP 8 is fast, typed where you want it to be, and actively developed. The problem is the sites that were built on PHP 5 or 7 and never moved. They keep working, so nobody touches them, until a host forces an upgrade or a vulnerability makes the decision for you.

Why the version number matters

Each PHP release gets roughly two years of active support and then a period of security-only fixes. After that it gets nothing. A site on an unsupported version is running code with publicly known vulnerabilities that will never be patched, and every plugin or library it uses will eventually stop supporting it too. The current schedule is published at php.net/supported-versions; as of late 2026, anything below 8.2 is out of security support, and 8.2 itself reaches end of life at the end of this year.

• Security. Unsupported versions do not get fixes, and attackers scan for them automatically.
• Speed. PHP 8 is substantially faster than PHP 7.0 and dramatically faster than PHP 5 for typical workloads, often without any code changes beyond compatibility fixes.
• Hosting. Shared hosts in Nepal and abroad are removing old versions. When they do, an unprepared site shows a white screen on a Monday morning.
• Dependencies. Current versions of WordPress plugins, Laravel and Composer packages require modern PHP. Staying old means staying on old, unpatched libraries as well.

Find out what you are actually running

Do not trust what the original developer told you three years ago. Check. In cPanel or a similar panel the PHP version is usually under a "Select PHP Version" or "MultiPHP Manager" screen. In WordPress, Tools → Site Health → Info → Server shows it. On a server you can reach over SSH, run the commands below. Note that the command-line PHP and the web server PHP can be different versions on the same machine, which causes confusing bugs in cron jobs.

php -v                      # CLI version
php -m                      # loaded extensions
composer show --outdated    # outdated packages, if Composer is used

What usually breaks between PHP 7 and PHP 8

Most upgrade failures come from a short list of changes. PHP 8 turned many old warnings into errors, so code that was quietly wrong for years now stops instead of carrying on.

• Removed functions. each(), create_function() and the old mysql_* functions are gone. Very old custom sites often use mysql_query everywhere and need moving to PDO or mysqli.
• Stricter type handling. Passing null to built-in string functions like strlen() or trim() is deprecated since 8.1 and fills logs with warnings. Comparisons such as 0 == "abc" changed result in 8.0, which can silently flip an if statement.
• Undefined array keys and variables are warnings now rather than notices, and on a site that displays errors they leak paths and break layouts.
• Dynamic properties on classes are deprecated since 8.2. Older plugins and hand-written models set properties that were never declared.
• Abandoned plugins and themes. On WordPress the core is rarely the problem. A plugin nobody has updated since 2019 usually is.

A safe upgrade plan

The goal is that the live site never sees an untested change. On a small business site this is a few days of work, not a project, and it costs far less than recovering from a hacked or broken site.

• 1. Back up everything. Files and database, downloaded off the server, and test that the backup actually restores somewhere.
• 2. Make a staging copy. Same code, same data, same server software, on a separate subdomain that search engines cannot index.
• 3. Scan before you switch. Tools like PHPCompatibility for PHP_CodeSniffer, or Rector for automated fixes, will list most problems before you change anything.
• 4. Upgrade staging one step at a time. Moving from 7.4 to 8.0, then 8.2, then the current release makes failures easier to trace than one big jump.
• 5. Turn on full error logging on staging and click through every important path: forms, checkout, login, search, admin screens, and any scheduled jobs.
• 6. Fix, update or replace what breaks. Replace abandoned plugins instead of patching them yourself.
• 7. Switch production in a quiet hour with the previous version one click away, and watch the error log for a day.

An upgrade that is planned takes a few days. An upgrade forced on you by a host or an attacker takes as long as it takes.

Upgrade, rewrite or move to something else

If the code is reasonably structured, upgrading is almost always cheaper than rewriting. If it is a decade of copied files with SQL built by string concatenation, the upgrade will surface security problems that were always there, and that is the moment to weigh a rebuild. We cover that decision in how to choose a web development company in Nepal and the framework question in Next.js vs WordPress. Whatever you choose, keep the URLs or redirect them, as described in site migration without losing traffic.

Keeping PHP current is one line item in a sensible maintenance plan. If your site is on an old version and you are not sure what will break, our web development team can run the compatibility scan on a staging copy and tell you exactly what the upgrade involves before you commit to anything.