How to Upgrade an Older PHP Website Safely: A Compatibility-First Runbook

Upgrading an older PHP site is a maintenance project, not a dropdown change. A newer runtime may bring security fixes and a longer support runway, but application code, extensions, templates, and server configuration can rely on behavior that has changed. The safest upgrade process discovers those dependencies, tests the real business workflows, and keeps a rollback path available until the new runtime is proven.

This runbook is for owners of older PHP applications, including content sites, ecommerce systems, custom portals, and integrations. It applies whether PHP is managed in Plesk or another control panel. The target version must be selected with three checks: the PHP project’s current support status, the hosting platform’s available runtimes, and the application vendor’s compatibility matrix.

Why upgrade planning matters

PHP branches move through active support, security-only support, and end of life. The PHP project publishes current branch support dates on its supported versions page. Once a branch reaches end of life, it no longer receives upstream security fixes. A website stuck on an old runtime therefore needs a plan that addresses both technical compatibility and exposure.

That does not mean every site should jump straight to the newest branch. The correct choice is the newest runtime that the application and its required extensions can use reliably on the supported operating system and hosting platform. If the application vendor supports only a limited set of branches, document that constraint and create a remediation or migration plan.

Build an inventory before testing

Record the current PHP branch, handler, operating system, control panel, application version, framework, installed extensions, scheduled commands, and any custom PHP directives. Include the database driver, image processing tools, mail transport, payment libraries, and API clients. A site can use one runtime for web requests and a different command-line binary for cron jobs, so verify both paths.

List critical user journeys. For an ecommerce store, include storefront browsing, search, account creation, login, cart, checkout, payment callback, order email, tax or shipping integration, inventory sync, and refund or cancellation. For a CMS, include publishing, media upload, form submission, user access, search, backups, and scheduled tasks. Choose journeys based on business impact, not just the homepage.

Prepare a representative staging environment

Use a copy of the application and database with secrets and personal data handled appropriately. Match production’s PHP extensions, handler, web-server behavior, database version, and key configuration where practical. Ensure staging cannot send real customer emails, charge real payment methods, or modify production integrations. Replace credentials and external endpoints with test values.

Capture a baseline before changing anything: current logs, response behavior, key page timings, known warnings, queue status, and application test results. This makes it easier to distinguish pre-existing defects from upgrade regressions. Make the staging copy recent enough to include the plugins, theme, custom code, and database structure actually in production.

Upgrade dependencies and code methodically

Check the application vendor’s supported PHP branches and upgrade instructions. Review release notes for the framework, plugins, theme, and custom modules. Update components only when their supported target and security posture are understood. Remove abandoned extensions that are no longer needed, but test that their removal does not discard business logic or stored data.

Run static analysis or compatibility scanners where they add value, then exercise the application under the target runtime. Treat scanner output as leads rather than a final pass/fail verdict: automated tools can flag code that is not used or miss runtime-specific behavior. Inspect PHP error logs for warnings, deprecations, type errors, missing extensions, and fatal errors. Resolve the underlying issue rather than suppressing broad error reporting.

Check custom code for assumptions about parameter types, string handling, session behavior, serialization, database drivers, error handling, and third-party libraries. Review cron scripts separately. A web request may succeed while a scheduled command fails because it uses a different executable or environment variables. Run the actual scheduled tasks in staging and inspect their output.

Test the whole application, not only the landing page

After switching staging to the target version, test the critical journeys from a clean browser session and with the roles staff actually use. Confirm authentication, permissions, forms, uploads, search, database reads and writes, mail delivery through a test sink, API callbacks, and background jobs. Check both ordinary and edge cases, such as a customer with an existing cart or a product with an unusual option combination.

Review response headers, redirects, cache behavior, and error logs. Re-test after enabling the production-like handler. PHP-FPM, FastCGI, and other handlers can have different configuration and process behavior. Plesk documents per-domain PHP version and handler settings and cautions that different PHP versions are not fully compatible; verify the target on the specific domain and environment.

Plan the production cutover

Write down the maintenance window, owner, target version, change steps, user communication, validation owner, and rollback trigger. Confirm backups are recent and restorable. Export the current domain-level PHP settings, custom directives, and handler choice. If the hosting platform allows per-domain selection, change only the intended domain rather than the whole server. Keep the old runtime available until the application has passed acceptance checks, subject to security and platform policy.

For a high-impact store or portal, reduce the number of simultaneous changes. Do not combine a runtime switch, framework upgrade, database major-version change, theme redesign, and migration into one untraceable event unless there is a clear reason. Smaller changes make failures easier to diagnose and roll back.

Use a specific rollback plan

Define a rollback condition before deployment. Examples include a payment flow that fails, a rise in fatal errors, broken account access, or an unacceptably high rate of failed background tasks. Know how to restore the former PHP selection and configuration, and verify that the application state remains compatible after a rollback. A runtime rollback does not undo database migrations or code changes by itself; those need their own plan.

Capture logs and timestamps during the change. If rollback is needed, preserve enough evidence to investigate the compatibility problem. Do not leave the site on an end-of-life version indefinitely after the rollback; create a follow-up remediation task with an owner and a decision date.

Monitor after release

For the first hours and days, monitor fatal errors, response time, CPU and memory use, PHP worker saturation, database behavior, queue completion, mail, payment callbacks, and customer support reports. Compare against the baseline and look for changes by endpoint, not just aggregate uptime. Confirm backups still run and cron jobs use the expected PHP binary.

Document the final runtime, handler, extensions, configuration differences, tests performed, known exceptions, and next planned upgrade. This record makes future maintenance less dependent on one developer’s memory.

Common PHP upgrade mistakes

• Choosing a target only because it is the newest option shown in the control panel.
• Testing the homepage but not checkout, admin, API, mail, and scheduled tasks.
• Using a staging copy with different extensions or a different PHP handler.
• Suppressing warnings instead of deciding whether they reveal real compatibility defects.
• Changing code and runtime at once without isolating which change caused a failure.
• Assuming a file backup alone reverses database or configuration changes.
• Rolling back and then forgetting to schedule a supported-runtime remediation.

Frequently asked questions

Can I switch PHP versions in Plesk without a developer?

Plesk lets authorized users select versions and handlers where the hosting plan permits it. For a business-critical or older application, first verify compatibility and test the required workflows. The control panel can change the runtime; it cannot determine whether custom application code will work correctly.

Does a new PHP runtime automatically make a website secure?

No. A supported runtime is one component of security maintenance. The application, extensions, credentials, server configuration, dependencies, and operational practices also require attention.

What if the vendor no longer supports my application?

Document the risk, isolate the system where practical, review available patches or supported forks with the owner, and plan migration or replacement. A runtime change can help only if the application can run safely and correctly on the supported platform.

Plan an upgrade with a measurable outcome

Informatix Systems can inventory the application stack, assess runtime compatibility, prepare a test plan, coordinate a controlled upgrade, and validate key workflows after cutover. We agree the target, access requirements, rollback conditions, and acceptance checks before production work. Explore cloud and hosting services or contact Informatix Systems to scope a PHP upgrade assessment.

Official references: PHP supported versions and Plesk PHP settings. Always confirm current compatibility with your application vendor and hosting provider.