Before Upgrading PHP: A Practical Application Checklist

Changing PHP in a hosting panel takes seconds. Finding the overlooked failure can take much longer: the home page loads, but login breaks, uploads fail or a nightly job keeps using the previous executable. A successful page load is only one item on the migration checklist.

Start with an explicit destination supported by the application and the packages it depends on. If that decision is still open, use the PHP version-selection guide first. Here, the runtime environment means the PHP installation together with the extensions and settings the application needs.

Record the environment you are leaving

Inspect the command-line environment under the application's account. This is often called CLI: PHP invoked from a terminal rather than through a web request.

php -v
php --ini
php -m
command -v php

Record the web runtime separately. Being on the same server does not prove that the shell and website use the same executable. Compare the loaded configuration, additional INI files, required extensions, timezone, upload limits and session settings in the destination environment.

Avoid copying the entire old configuration without review. Move the settings the application needs, not every historical option accumulated on the host. A removed configuration directive can become another migration problem.

Check dependencies with the intended interpreter

composer validate --strict
composer prohibits php 8.5.12
composer check-platform-reqs

Here, 8.5.12 is the example target. prohibits identifies dependency constraints opposing it; it does not execute an application compatibility test. check-platform-reqs examines the PHP and extensions actually running the command. Run the check in the target environment, not merely under the old shell runtime. The distinction is documented in the Composer command reference.

A config.platform.php setting can model a platform for dependency resolution. It does not install that platform. Preserve the lockfile while isolating the runtime change. An unrelated composer update can change many packages at once, making the cause of a failure harder to identify.

Read the intermediate migration guides

Moving from 8.2 to 8.5 involves more than the latest release's feature list. Review incompatible changes, deprecations and removals for each intervening branch. The 8.4 and 8.5 migration guides belong in that review.

Suppressing a warning from an old theme or library does not repair the underlying compatibility problem. Capture errors in the test environment and associate them with the component producing them. Server-side logging and showing raw errors to visitors are separate settings.

Test what the site actually does

• Login, logout, session persistence across requests and password resets.
• Form validation, file uploads, image processing and downloads.
• A database write followed by reading the saved value.
• External APIs, email, queue workers and scheduled tasks.
• For commerce applications, a completed transaction in the payment provider's test environment.

Before testing, prevent the staging copy from sending real customer messages or initiating live payments. Use the same application files, locked dependencies and representative data as the intended deployment. An empty installation starting successfully is not a substitute for exercising the real application.

Make rollback a defined operation

Confirm that the backups can actually be restored. If database migrations accompany the PHP switch, the previous application code may not work with the new schema. Keep the runtime change separate where practical and define what happens to files, data and workers on rollback. Returning to a vulnerable runtime is not a satisfactory permanent fix either.

After the production switch, check the web executable, CLI and background tasks independently. Use the host's supported procedure when relevant services need reloading. Repeat the important workflows and compare error logs. If the panel shows the intended version but jobs still behave differently, follow the web, shell and cron troubleshooting guide before declaring the migration finished.