Guide PHP & Development

How to upgrade PHP without breaking your site

Check compatibility, test on staging, then switch the live version over — the order that keeps a PHP upgrade from taking your site down.

iFastHosting Support Team Updated 8 min read Intermediate

Every PHP version eventually stops receiving security fixes, and hosts move their defaults forward as a result. Left alone, a site quietly ends up running a version nobody actively chose. Newer PHP versions are also faster than the ones they replace and are the only ones still receiving security patches — reason enough to move deliberately rather than waiting until the old version is switched off from under you.

The failure mode everyone has heard about — a plugin fatal-erroring the moment the version changes — is almost always a compatibility problem discovered too late, not bad luck. Find it before the switch and the whole exercise is uneventful.

Check compatibility before you change anything

Every serious CMS, framework and plugin declares a minimum and, less often, a maximum supported PHP version. Find that declaration before you do anything else:

  • WordPress core lists supported versions on its own requirements page, and most well-maintained plugins state theirs in their changelog or plugin header.
  • Composer-based projects declare it in composer.json under "require": { "php": "..." }. Run composer check-platform-reqs after switching to see exactly what fails.
  • Custom code has no declaration to check, which is precisely why it needs the staging test in the next section rather than a guess.
The usual breakage is a removed feature, not a new one

Most upgrade failures come from something PHP used to allow quietly and now refuses outright — a dynamic property on a class, a function that took an array and now insists on a string, a deprecated notice that graduated into a fatal error. Old, unmaintained plugins are the most common source, because nobody has gone back to update them for versions released after the plugin itself stopped being touched.

Take a backup before you touch anything

Back up the full site — files and database together — before changing the version anywhere, including on staging. If the upgrade turns out to need more surgery than a quiet afternoon allows, you want the option to put the old version back and try again another day, not a partial rollback done from memory.

The steps, in order

  1. Check what your application actually supports

    Confirm the minimum PHP version for your CMS or framework and the current version of every plugin or package that matters. Note anything already flagged as unsupported on the version you plan to move to.

  2. Take a full backup

    Files and database together, stored somewhere other than the account you are about to change.

  3. Switch the version on a staging copy first

    Set up a staging copy of the site, change its PHP version in the PHP settings area of your control panel, and reload every part of the site that matters — admin area, checkout, contact forms, anything with custom code.

  4. Fix or update whatever the staging test flags

    Read the error log for the staging site rather than relying on what visibly breaks in the browser — plenty of deprecation notices and non-fatal errors do not show as a broken page but are still worth clearing before they become fatal on a future version. Update plugins to versions that declare support for the new PHP release, or replace ones that have gone unmaintained.

  5. Switch the live site and watch the error log

    Once staging is clean, change the live site's version in a quiet period. Watch the error log for the next few minutes rather than assuming silence means success, and check the pages that matter most — the homepage, checkout, login — by hand.

Know how to go back

The PHP version setting in your control panel can be switched back in the same place it was changed. If something is broken on the live site after the switch and a quick fix is not obvious, put the old version back first and investigate on staging afterwards — a site that works on an older version is better than one that is correct in principle but down right now.

What shared hosting can and cannot do here

On shared hosting you can change the PHP version for a site and adjust a wide range of PHP settings through your control panel or a user-level ini file, all without needing root access. What you cannot do is recompile PHP with custom build flags or run two incompatible system-level PHP builds side by side outside what the panel exposes. If an application genuinely needs a PHP build option that shared hosting does not offer, that is a job for a VPS, where you control the whole stack.

After the upgrade

Keep an eye on the error log for a few days rather than just the first few minutes — some code paths only run on a schedule, a form submission, or a specific report a customer generates once a month, and a compatibility problem there will not show up on the first pass. Once the new version has settled in without incident, you can safely remove the staging copy or repurpose it for the next round of changes.

Related reading

Which PHP version should I be running?

Run the newest PHP version your application supports and that still receives security updates — rarely the oldest one that merely still works.

 How to check which PHP version your site uses

A one-line PHP script and the PHP settings screen in your control panel both show the exact version your site runs on.

 How to set up a staging environment

A subdomain, its own database, and a safe way to copy data across — what a staging environment needs before you can trust it.

 How to read a PHP error log

The error log names the exact file and line that failed — here is where to find it and how to read what it is telling you.