If your hosting company has asked you to move your WordPress website off PHP 8.2, start by checking which version the live site actually uses. Then agree a replacement version, test the complete customer journey and confirm how the host would reverse the change if something fails.
PHP is the server-side software that runs much of WordPress. Changing it is a hosting-level change, separate from updating a plugin or editing a page. Your homepage can look fine while an enquiry submission, checkout or scheduled task needs attention.
The immediate reason to plan is clear: PHP’s current support schedule lists 31 December 2026 as the end of security support for PHP 8.2. As checked on 3 November 2026, that deadline is still ahead. Use the remaining time to arrange a controlled move.
What does the PHP 8.2 deadline mean for your business?
The deadline concerns support from the PHP project. It does not tell you when your hosting company will change your account, withdraw a version or introduce an extra charge. Ask your host for its own policy in writing.
PHP distinguishes active support, covering bugs and security issues, from the later period covering critical security issues only. The current security-support end dates are:
- PHP 8.3: 31 December 2027.
- PHP 8.4: 31 December 2028.
- PHP 8.5: 31 December 2029.
Those dates help you compare the useful lifespan of a proposed replacement. They do not prove that your particular website will work on it. A move to 8.3 may resolve an immediate compatibility constraint, while a tested move to 8.4 or 8.5 offers a longer support window.
Ask whether any extended support offered by your host includes maintained security fixes, what it costs and when it ends. Treat it as a defined arrangement with a review date.
Check the PHP version used by the live website
In WordPress, open Tools > Site Health > Info and expand Server. The official Site Health guide explains where to find this information and describes the server configuration section. Record the PHP version shown, then ask the host to confirm it for the live domain.
Keep the complete version number. The branch, such as 8.2, tells you which support timetable applies; the remaining numbers help identify the installed patch release. Ask the host to explain how its package receives security fixes.
Also ask whether scheduled jobs and command-line tasks use the same PHP version as web requests. Include staging sites and other websites on the account in the conversation: establish exactly what the proposed hosting change will affect.
Choose a version your whole website can support
WordPress currently recommends PHP 8.3 or greater. That is a starting point for choosing hosting, rather than a compatibility certificate for every theme, plugin and piece of custom code.
Check your installed WordPress release against the current WordPress and PHP compatibility table. It covers WordPress core. Separately check the versions of your theme, page builder, form tool, payment integration and other business-critical extensions with their maintainers.
For a bespoke quote calculator or integration, ask the developer who maintains it to confirm the proposed PHP target. An old compatibility statement for a different plugin release is weak evidence for the code running today.
Request a clear recommendation: the target PHP branch, the software changes needed first, any unresolved compatibility concerns and the reason for choosing that branch. Prefer a supported stable version with a useful remaining lifespan that your complete site can demonstrate it supports.
Keep immediate security patching separate from the planned upgrade
A future migration date is not a reason to postpone current security work. PHP’s October 2026 notices include security releases on 21 October, a session-upload follow-up on 23 October and updated Windows builds on 26 October.
Ask your hosting provider to confirm that the installation has current applicable security fixes and that it has reviewed the later guidance relevant to its environment. The provider should assess its packages and configuration. Keep that check alongside the longer-term move away from PHP 8.2.
Prepare a test copy that represents the live site
Ask for a protected staging copy using the proposed PHP version and a representative hosting configuration. Agree how test payments, emails, CRM updates and bookings will be contained so that testing does not contact customers or create genuine work.
Before changing PHP on that copy, run your important journeys on the existing version and record the outcome. Where WordPress, theme or plugin updates are needed, test those changes before the PHP switch where practical. This makes it easier to establish which change introduced a fault.
Have the host or developer compare the following between the existing and proposed environments:
- Required PHP extensions and any extra runtime requirements documented by your plugins.
- Memory, upload and execution limits needed by your actual forms, imports and scheduled work.
- The PHP version and configuration used for background jobs.
- Any hosting-specific settings that the version selector will reset or replace.
Agree a current backup of both files and database, who can restore it and how restoration has been verified. Also record the original PHP configuration. A useful recovery plan identifies the person who can act if the WordPress dashboard becomes unavailable.
Test the work customers and staff need to finish
Choose tests around revenue and enquiries. Give each one an expected outcome and a person responsible for checking it.
Enquiries and bookings
Submit a clearly identified test enquiry from a phone. Include an attachment if customers normally send one. Confirm the submission reaches the intended inbox or CRM with usable details. For bookings, check that the appointment reaches the correct calendar and that the confirmation arrives.
For example, a bicycle repair business should test a service-booking request from submission through to the workshop receiving it. Seeing a thank-you message covers only one part of that route.
Orders and customer accounts
Use the agreed payment-testing method to complete a representative purchase. Check the selected product, delivery choice, final total, payment record, order status and confirmation. Include account login or paid downloads where those features matter to the shop.
Keep a record of test transactions and how they will be cleared. Avoid changing the live payment setup simply to make a staging test convenient.
Editing and background work
Ask a member of staff to open the editor, change a test page and upload a normal photograph. Check the page builder and any custom content fields the team relies on.
Then verify a scheduled process, such as an order export or reminder, using controlled test data. Check its destination as well as its run status. The test should show that useful work completed, with the correct information.
If the PHP change exposes an error, collect specific evidence
Record the failing action, time, page address and PHP version. Ask the developer to reproduce it and inspect the relevant error logs. Describe the outcome precisely: for example, the form returns an error after submission, while ordinary pages still load.
WordPress’s debugging guidance explains how developers can log errors and keep their display separate. It recommends debugging tools for local and staging environments. A deprecation notice concerns functionality scheduled for future removal; it does not by itself prove that a customer action has failed.
Have the developer identify the responsible code and propose an update, repair or replacement. Keep logs protected and diagnostic messages away from visitors. Turning off a critical form or payment plugin is not an acceptable completed repair unless an agreed alternative keeps that function available.
Agree the live switch and the recovery decision
Choose a change window when the host or developer and someone from your business can check the result. Agree what would trigger reversal, how quickly that decision will be made and who will carry it out.
Distinguish switching the PHP runtime back from restoring an older database. If new orders or enquiries have arrived, ask how they will be preserved before authorising any database restoration. Do not assume that recovery requires overwriting everything.
After the switch, confirm the live PHP version and repeat the essential customer tests. Review errors during those tests and check the next scheduled jobs. Retain the test outcomes, target version and any outstanding remedial work with a named owner.
If compatibility work prevents the move, record the exact blocker and a date for resolving it. An unresolved plugin dependency needs a maintenance decision before the support deadline.
Give your host or developer a clear brief
Ask for a quote covering the target version, required compatibility repairs, staging checks, live verification and recovery arrangements. That gives you something concrete to approve and makes responsibility clear.
BuzzBoost’s web development service includes integrations, maintenance and recovery planning. If a PHP upgrade notice has left you unsure what your website needs, send us the notice and your website address. We can help establish the next practical step.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
