Introduction

A cPanel account transfer can bring a site online with the wrong effective PHP version even when the files and database moved successfully. The destination server may apply a different default version, lose a per-domain override, or keep a handler setup that no longer matches the restored account. The result looks like a random post-migration break, but the real problem is that the application is no longer running under the PHP version it had before the move.

This is different from a planned PHP upgrade. In a transfer case, nobody intended to change the runtime. You need to prove which PHP version the site is actually serving, then fix the domain-level configuration that did not survive the migration cleanly.

Symptoms

  • The site breaks immediately after cPanel transfer or restore
  • WordPress, Laravel, Magento, or custom PHP apps start showing fatal errors after cutover
  • cPanel shows one PHP version, but the live site behaves like it is using another
  • Some domains or subdomains in the same account fail while others still work
  • Error logs mention unsupported syntax, missing functions, or version requirement failures
  • The application worked on the old server and only failed after the account move

Common Causes

  • The destination server default PHP version differs from the source server default
  • MultiPHP settings for domains or subdomains were not preserved during transfer
  • CloudLinux PHP Selector or alt-PHP settings did not migrate the same way as standard cPanel settings
  • Old .htaccess handler rules are forcing the wrong PHP version
  • PHP-FPM is enabled or mapped differently on the new server
  • The destination host is missing the exact PHP version or extensions the app used before
  • A domain now inherits server defaults because its explicit override was lost

Step-by-Step Fix

  1. Check the PHP version the live website is actually using in the browser instead of trusting only what cPanel shows, because the real runtime is what matters for the broken application.
  2. Compare that live PHP version with the version the site used on the source server, because you need a known-good target before changing handlers or selectors.
  3. Review MultiPHP Manager or the host’s PHP selector for every affected hostname, including addon domains and subdomains, because some hostnames may have lost their explicit override while others kept it.
  4. Set the required PHP version directly on the affected domain instead of leaving it inherited, because inheritance is a common reason migrated sites silently switch runtimes.
  5. Inspect .htaccess files for old handler directives such as AddHandler or SetHandler, because migrated legacy rules can force an unavailable or incorrect PHP version on the destination host.
  6. Check whether PHP-FPM is enabled and consistent with the selected PHP version, because mismatched PHP-FPM pool settings can keep serving the wrong runtime even after visible selector changes.
  7. Verify that the destination server has the necessary PHP version and required extensions installed, because matching the version number alone does not help if the app is still missing core modules.
  8. Re-test the site after each change and watch the error log immediately, because this shows whether you fixed the actual runtime problem or only changed a control panel setting without affecting live requests.
  9. Once the site is stable, document the final PHP version, handler model, and per-domain overrides, because cPanel migration issues like this tend to come back during later restores if the working state is not recorded.