PHP version planning is a compatibility and support decision. A newer version can offer useful improvements, but a website also depends on its application, extensions, database connections and custom code. Select a supported version that the complete application can use, then verify the change through real business journeys.
A page rendering successfully is a limited test. Forms, uploads, scheduled tasks, command-line tools and payment callbacks may use different execution paths. Include them in the upgrade plan before declaring that a website is compatible.
Identify where PHP runs
Record the PHP version used by the public website, background tasks and command-line maintenance. Some hosting accounts can configure these separately. A control-panel selector for the website does not necessarily alter the version used by a scheduled script.
List required extensions, configuration limits and application dependencies. Include custom packages and integrations that are not visible in a normal CMS plugin list. Ask the authorised technical owner how the installed application is built and deployed, so the inventory reflects the actual system.
Understand active and security support
PHP branches have defined support periods. Active support and security-only support are different stages, followed by end of support. As reviewed on 11 October 2026, PHP 8.4 has active support through 31 December 2026 and security support through 31 December 2028. Recheck the published support schedule when planning a later change.
An unsupported branch no longer receives the normal upstream support provided to a supported release. A hosting service may offer additional arrangements, but those need their own checked scope. Do not describe an old runtime as safe merely because the website still appears to work.
Choose the target around application compatibility
Check the application's supported versions and those of important themes, plugins and packages. Confirm the installed versions, not only the product names. A plugin family supporting a newer PHP branch does not prove that an old installed release supports it.
Read the migration information for the proposed version, including incompatible changes, deprecated behaviour, extension changes and new requirements. Moving from PHP 8.4 to 8.5 needs that specific review. A broad claim that every newer branch is faster or universally compatible is not an adequate upgrade justification.
Create a representative test environment
Use a controlled copy with relevant code, settings and sample data. Configure the intended PHP version and required extensions. Protect confidential data and prevent the test copy from sending real customer emails or creating genuine orders.
Preserve a baseline on the current version, so the team can distinguish a new runtime problem from an existing fault. Include unusual but supported inputs, such as large uploads or records containing non-ASCII characters. These can reveal issues that a homepage smoke test misses.
Test the complete execution paths
- Open key public pages and inspect application errors.
- Test forms, uploads and outgoing notifications.
- Check administrator editing and scheduled publication.
- Test database access and essential third-party integrations.
- Run relevant scheduled and command-line tasks under the intended version.
- Review warnings and logs without exposing credentials or personal data.
Deprecated behaviour may produce warnings before it becomes an incompatible change in a later release. Record those warnings and prioritise the affected code. Avoid hiding error evidence simply to make a test appear clean. Public error display and useful protected logging are separate configuration decisions.
Compare performance fairly
If performance is part of the reason for upgrading, compare representative requests using the same application, data and test conditions. Check response time, errors and resource use together. A single faster page load does not establish a general improvement for every business task.
Separate runtime effects from caching, database changes and infrastructure differences. Keep the test method and limits in the decision record. Compatibility and continued support can justify an upgrade even when a small business cannot demonstrate a meaningful speed improvement.
Prepare production and rollback
Take a recoverable backup and confirm how the hosting service switches versions. Check whether the change affects one website or a whole account. Plan the timing with the business and define the conditions that would stop or reverse the change.
Rollback can involve more than returning a version selector to its old value if application or dependency updates were performed alongside the runtime change. Record the compatible combination of code, dependencies, data and configuration. Avoid separating the runtime from the application state required to use it.
Verify the live result
Check the actual production runtime and important journeys after the change. Confirm background tasks separately, review protected error logs and monitor the service through an appropriate observation period. Update the version inventory, support review date and unresolved maintenance actions.
For hosting configuration and runtime requirements, visit Giraffe Hosting. Where application changes are needed, Giraffe Digital's website design service can connect technical compatibility work with the customer-facing functionality the business needs to preserve.
