PHP 8.2 End of Life: An Upgrade Plan for UK WordPress Businesses
Plan your UK business website’s next PHP upgrade before PHP 8.2 support ends. Scope dependencies, staging, release approval and post-launch checks.
In this article
Illustrative editorial workspace; not a client website, incident or delivered system.
A support deadline is easier to manage while the website still works and the team has time to review a plan. For a UK business with an older WordPress build, the difficult question is often not where the PHP selector lives. It is whether the theme, extensions and custom functions will work on the next supported environment.
A scoped PHP upgrade project turns that uncertainty into an inventory, a compatibility decision and a release plan. Here is what to establish before booking a production switch.
Use the support date to start planning
The PHP project lists 31 December 2026 as the end of security support for PHP 8.2. That date concerns the PHP project’s branch lifecycle; a hosting or distribution vendor may have its own package arrangements. Confirm what your provider supplies rather than assuming a hosting plan and an upstream support policy are identical.
Use the deadline to assign ownership now. Identify the hosting contact, website developer and business reviewer. Ask for the current runtime and package details, the versions available on your plan and the dependencies that need checking before a supported destination can be chosen.
Inventory the parts people forget
Record more than the active theme and the number of plugins. Include custom snippets, integrations, scheduled imports, file handling and the tools staff use to edit content. Note licence ownership and whether a maintained release of each important component is available.
An old agency handover may leave a business unsure who owns a licence or custom-code repository. Resolve that before promising a release date. The discovery work should show which items can be updated, which require repair and which need a replacement decision. That is what makes the subsequent quote more reliable.
Choose the destination based on support and compatibility
Do not choose a target solely because it is the highest number in a hosting dropdown. Ask the developer to explain why the proposed branch is supported by the host and suitable for the application. Review the specific code and dependencies that make the move possible.
Where the site needs significant repairs, divide assessment from implementation. The first stage can establish the issues, options and expected checks; the second can carry out approved changes. This gives a UK business a decision point before committing to component replacement, redesign work or a larger change in hosting.
Make staging representative of the business website
A useful staging copy needs the configuration and representative content required to reproduce the site’s functions. At the same time, it should be kept out of public indexing and should not send normal customer notifications accidentally. Agree how data is copied and who may access it.
Use the staging check to exercise the editor, forms, search and important integrations. A static screenshot does not demonstrate that a custom enquiry workflow works. The release brief should specify what will be checked manually, what the host will verify and what the business owner needs to approve.
Book a release window with a recovery decision
Agree a date, time zone, reviewer and recovery procedure. “After hours” can mean different things to a UK business and a developer working from India. State when the team will be available to make a go/no-go decision and how a change will be communicated to staff.
Consider content and enquiry activity between the backup and the release. If restoration is needed, decide how new data will be protected. The plan should explain who may stop the release and which component would be restored, not simply promise that a backup makes every change reversible without consequence.
Ask for a quote that separates upgrade and ongoing care
Send the URL, hosting provider, current PHP version if known, custom features and a target window. I can assess the information and propose remote upgrade or compatibility work with clear deliverables. Any replacement licences or provider charges are identified separately.
After implementation, request the tested runtime, changes made, acceptance results and remaining actions. A WordPress maintenance agreement can then cover future updates and agreed checks. Keeping that ongoing work distinct helps you understand both the one-time upgrade cost and the responsibility for the next support deadline.
Related planning: WordPress Malware Removal for UK Businesses: What a Cleanup Quote Should Include · PHP Upgrades for Dubai Business Websites: Plan English and Arabic Checks.
References reviewed 23 October 2026: PHP supported versions.
Written by
Jagjeet Singh
Full stack development, WordPress engineering and practical web products. I work with businesses, teams and agencies in India and worldwide.
Explore my work
