My site broke after the host upgraded PHP. What do I do right now?
Restore service first, fix properly second; that is the order any PHP version upgrade service should follow. Most shared hosting panels, including cPanel’s PHP selector tools and Plesk, let you choose the PHP version per domain. If the old version is still offered, switch back, confirm the site loads, and you have bought time to fix things calmly.
If the host has removed the old version, put a simple maintenance page up rather than show visitors fatal errors or a blank white page. Take a full backup of files and database at this point, even of the broken state, because it is the baseline for everything that follows.
Then collect the evidence. The PHP error log, usually in the hosting panel or a file called error_log in the site folder, tells a developer exactly which file and line failed. WordPress sites may also have sent a recovery-mode email to the admin address naming the plugin or theme that caused the fatal error. Send both to whoever will fix it.
- Switch back to the previous PHP version if the panel still lists it
- If not possible, show a maintenance page instead of errors
- Take a full backup of files and database immediately
- Download the PHP error log and any WordPress recovery email
- Do not update plugins on live in a panic; that can make things worse
What is a PHP version upgrade service?
A PHP version upgrade service is a developer-led job that moves your website or web application from an old PHP version to a supported one while keeping everything else the same: design, content, URLs, data and features. The difference from clicking “upgrade” in cPanel is that the code is checked and fixed before the switch, not after it breaks.
The work has three layers. First, your own code: the theme, custom plugins, or the controllers and models of a custom app. Second, third-party code: plugins, Composer packages and bundled libraries such as old PDF or mail classes. Third, the server: PHP extensions, memory limits and settings that the new version handles differently.
A good PHP version upgrade service ends with a written summary of what was changed, what was replaced, and when the next PHP deadline falls. It should not end with a site that works today but carries a dozen silenced warnings that will become fatal errors next year.
Why is my hosting company forcing a PHP upgrade?
Because the old version no longer gets security fixes. PHP.net’s support policy gives each release two years of active support and then two more years of security fixes only; after that it is end of life. PHP 7.4 reached end of life on 28 November 2022, PHP 8.0 on 26 November 2023 and PHP 8.1 on 31 December 2025.
Running unpatched PHP on a shared server is a risk to every customer on that server, not just you, so hosts retire old versions on their own schedule. Some offer paid extended support for a while; many simply switch accounts to a newer version with a notice email that often lands in spam.
The next deadline is close. PHP.net lists PHP 8.2 as receiving security fixes only until 31 December 2026. If your host moved you to 8.2 a year ago and you thought the problem was solved, expect another move soon. That is why our PHP version upgrade service aims for PHP 8.3 or 8.4 rather than the lowest version that happens to work.
Which PHP version should you upgrade to in 2026?
For most sites, PHP 8.3 or PHP 8.4. According to PHP.net, 8.3 receives security fixes until 31 December 2027 and 8.4 until 31 December 2028. PHP 8.5, released on 20 November 2025, has the longest runway, to 31 December 2029, but some plugins and packages take a few months to catch up with a new branch.
The right answer depends on what sits on top. WordPress recommends PHP 8.3 or greater on its requirements page. Laravel’s release notes list Laravel 12 as supporting PHP 8.2 to 8.5 and Laravel 13 as supporting 8.3 to 8.5. CodeIgniter 4 requires PHP 8.2 or newer. An app pinned to an old framework version may need that framework upgraded before PHP can move.
We pick the highest version that every critical component supports, then test on it. If one plugin blocks 8.4 but 8.3 works, you get 8.3 now and a note about what must change before the next step.
Choose PHP 8.4 when
Your theme, plugins or framework release explicitly support it and you want the longest support window without being first on a new branch.
Choose PHP 8.3 when
One important component has not confirmed 8.4 support yet. It is still supported until the end of 2027.
Avoid PHP 8.2 as a target
It works, but its security support ends on 31 December 2026, so you would repeat the exercise within months.
What breaks when you upgrade from PHP 7 to PHP 8?
The failures a PHP version upgrade service fixes come from a known list of removed functions, stricter errors and changed comparisons, most of them documented in PHP.net’s migration guides. Code written for PHP 5 or 7 tends to trip over the same handful of changes.
Removed functions cause instant fatal errors. The old mysql_* functions and ereg functions were removed back in PHP 7.0, so a site still using them has been running on a very old version. PHP 8.0 removed create_function() and each(), both common in older themes and plugins, and it no longer treats a method with the same name as its class as a constructor.
Behaviour changes are quieter and more dangerous. In PHP 8, comparing 0 with a non-numeric string such as "abc" gives false where PHP 7 gave true, which can silently change login checks, filters or discount logic. Many warnings became thrown errors, and curly-brace string offsets like $str{0} no longer parse.
Later versions add deprecations that fill logs today and break tomorrow. PHP 8.1 deprecates passing null to built-in functions that expect strings, and PHP 8.2 deprecates dynamic properties, the dollar-brace “${var}” string interpolation style and utf8_encode(). None of these stop the site on their own, but they are the fatal errors of a future version.
PHP version upgrade for WordPress and WooCommerce sites
WordPress core handles new PHP versions well; in most WordPress jobs our PHP version upgrade service handles, the trouble is almost always a theme or plugin. Its requirements page still lists PHP 7.4 as workable but warns that such end-of-life versions may expose the site to security vulnerabilities, and recommends PHP 8.3 or greater.
Our WordPress routine: clone the site to staging, switch staging to the target PHP version, update core, then update plugins one at a time with a check after each. Plugins with no update in years, or a changelog that never mentions PHP 8, get replaced with maintained alternatives. Premium themes and plugins with lapsed licences often have the fix in a newer release, so renewing the licence can be the cheapest step.
Custom code needs reading, not just scanning: a child theme’s functions.php, snippets pasted in years ago, or a small custom plugin written by a previous developer. For WooCommerce stores we place test orders through each payment method and check emails, invoices and stock updates before the live switch.
- Update WordPress core on staging first
- Update plugins one by one, testing after each
- Replace plugins abandoned by their authors
- Read child-theme and snippet code by hand
- Place test orders and submit every form before going live
If the old theme is the real problem, a lighter block-based rebuild may be the better spend; our custom Gutenberg block development page explains that route.
Laravel and CodeIgniter apps on a new PHP version
Framework apps have a dependency chain: the PHP version supported by your framework release decides how far PHP can move. Laravel publishes a table of which PHP versions each release supports, so an app on Laravel 8 or 9 usually has to climb framework versions before it can run on PHP 8.3 or 8.4.
We upgrade Laravel one major version at a time, following its upgrade guide for each, and run the test suite or a manual checklist after every step. Composer packages are updated alongside; abandoned packages get replaced or their small useful part rewritten into the app.
CodeIgniter 3 apps can usually be made to run on PHP 8.x by fixing the application code and keeping the framework on its last 3.x release, though deprecation notices need handling on 8.1 and 8.2. CodeIgniter 2 apps are harder, since that version was never meant for PHP 8. When the patching bill starts to look like a rewrite, we will say so and compare it with a move to Laravel.
Laravel app
Framework upgraded version by version, Composer packages updated, tests after each hop, PHP switched last.
CodeIgniter 3 app
Application code fixed for PHP 8, framework kept on its final 3.x release, deprecations handled, database calls checked.
Core PHP app
Removed functions replaced, database calls moved to PDO or mysqli with bound parameters, errors and warnings cleared file by file.
Fixing hand-written PHP code for PHP 8.x
In a PHP version upgrade service, hand-written PHP from the 2000s and early 2010s is where upgrades cost most, because there is no framework upgrade guide to follow. The pattern is always similar: a folder of PHP files, a config.php with database details, SQL built by joining strings with form input, and functions that PHP no longer has.
We start with a static scan across every file, using tools such as PHPCompatibility with PHP_CodeSniffer and PHPStan, to list removed and deprecated calls. Then we fix in order of danger: fatal errors first, then behaviour changes like loose comparisons in login or payment code, then deprecations that will become errors in later versions.
Database code is the biggest item. Replacing mysql_* calls with PDO or mysqli is the moment to switch to bound parameters, which closes SQL injection holes at the same time. We keep the queries doing exactly what they did, and compare results on staging with copies of real data.
If the app is central to your business and keeps growing, a patched core-PHP app is still hard to hire for; our PHP to Laravel migration page covers the longer-term route.
Why a PHP version upgrade must be tested on staging first
Because the live site is where your customers are, and a PHP version upgrade service that experiments on live is gambling with them. A staging copy on the new PHP version lets every error surface in front of us, not your visitors, and gives you a place to click through the site before anything changes live.
A staging environment is simply a copy of the site on the same hosting (or a similar server) with its own database copy and a private address. Emails and payment gateways are pointed at test modes so nothing real is sent or charged. Search engines are blocked from indexing it.
Testing covers more than the home page. We keep a checklist per site: every form submitted, login and registration, search, cart and checkout, admin screens, file uploads, scheduled tasks and emails. Error logs stay at full reporting on staging so notices and deprecations show up. Only when that checklist passes do we schedule the live switch, at a low-traffic hour, with a fresh backup and the rollback steps written down.
- Private staging copy on the target PHP version
- Emails and payments in test mode
- Full error reporting while testing
- Written checklist of every form and flow
- Live switch at a quiet hour with a rollback plan
How much does a PHP version upgrade service cost?
The price of a PHP version upgrade service depends on code size and age more than anything else. After a scan we quote the upgrade itemised by component, so you can see what the theme, each problem plugin and each custom module adds. The quote arrives in about two working days and nothing is billed before you approve it in writing.
As a guide to effort: a small WordPress site with maintained plugins is often a few working days including testing; a WooCommerce store with custom checkout code takes longer because every payment path is tested; a custom PHP or CodeIgniter app ranges from one to several weeks depending on the number of affected files. Large custom application upgrades start at ₹60,000.
Two things lower the cost: renewing licences for premium plugins and themes, which often contain the fix already, and retiring features nobody uses. Two things raise it: code with no version control history, and a server that is also compromised. If fixing would cost more than rebuilding, for example an abandoned theme on a simple site, we will compare it with a new site from ₹10,000.
Risks and red flags when hiring someone to upgrade PHP
The most common bad fix sold as a PHP version upgrade service is hiding errors instead of solving them: setting error_reporting to zero or wrapping calls with the @ operator so the logs look clean. Note that PHP 8’s @ operator no longer silences fatal errors, so this approach is failing more often anyway. Ask any developer whether warnings will be fixed or hidden.
Other warning signs: editing plugin files directly (the next plugin update wipes the fix), updating everything on live without a backup, or promising a result before looking at the code. Watch too for “upgrades” that quietly change your hosting account or move the site to a server the developer controls; your access should never shrink.
- Errors hidden instead of fixed
- Fixes made inside third-party plugin files
- No staging copy and no fresh backup
- Hosting or domain moved into the developer’s account
- A fixed promise given before the code has been seen
- No written list of what was changed
If your site has been showing security warnings as well as PHP errors, look at website showing not secure for the certificate side of the problem.
Usually a little faster, sometimes noticeably. Newer PHP versions run the same code with less work per request, and moving off old versions often comes with OPcache properly enabled. The gain shows most on uncached pages such as WooCommerce carts, search results and admin screens.
For SEO, the direct effect is small but the indirect effects matter. A site that throws errors, loads slowly on the server side or gets hacked because of unpatched PHP loses rankings; a site that responds quickly helps Core Web Vitals, especially time to first byte. Nobody can promise rankings from a PHP upgrade, and we do not.
AI search tools and search crawlers both prefer pages that load reliably and return clean HTML. After an upgrade we check that key pages return proper status codes, that no warnings are printed into the HTML (a common side effect of PHP 8 notices on misconfigured servers), and that sitemaps still generate. For deeper speed work, see WordPress speed optimisation.
Access, ownership and who does the upgrade
With our PHP version upgrade service you stay in control of everything. We work through a separate user or temporary credentials that you create for us in your hosting panel, WordPress admin or Git repository, and you can revoke them when the job is done. Your domain, hosting account and code never move to us.
The work is split across three people. One of us fixes the code, from theme functions to Laravel controllers. Another of us handles the server side: PHP version settings, extensions, backups, staging and logs. The third of us keeps the checklist, coordinates the test pass with you and schedules the live switch. You talk to all three on WhatsApp in English or Hindi, seven days a week.
At the end you receive a short report: PHP version before and after, what was fixed, what was updated or replaced, what still shows deprecation notices for the next version, and the date the chosen PHP branch reaches end of life. We do not visit offices, and we do not take over hosting you already have.
PHP version upgrade service for businesses across India
Indian businesses on shared hosting got the same notices at the same time, so this work comes from everywhere: manufacturers’ catalogue sites in Ludhiana and Jamshedpur, hotel booking sites in Udaipur and Jodhpur, school portals in Kanpur and Varanasi, and textile traders in Salem.
Everything happens remotely. You create access for us, we scan and quote, you approve, and the fix is tested on staging before your live site changes. Payment is by UPI or bank transfer with GST invoices where needed, and clients outside India pay in USD by Wise, wire or PayPal.
Some India-specific pieces break often on PHP 8: old SMS gateway scripts, payment callback files from gateways that have since changed their kits, Hindi or regional-language text handled with utf8_encode, and GST invoice PDFs generated by ageing libraries. Each gets tested explicitly before the switch.
PHP upgrade checklist for site owners
Whether you hire a PHP version upgrade service or try it yourself, work through these steps in order. Skipping the early ones is how a thirty-minute job becomes a three-day outage.
- Note the current PHP version and the date your host will change it
- Take a full backup of files and database, and check you can restore it
- List what runs on the site: CMS, theme, plugins or packages, custom code
- Check each plugin or package for recent updates and stated PHP 8 support
- Create a staging copy and switch only staging to the new version
- Turn on full error logging on staging and click through every flow
- Fix, update or replace what fails; never edit third-party files directly
- Test forms, logins, checkout, emails and scheduled tasks
- Switch live at a quiet hour, with rollback steps written down
- Watch error logs and Search Console for a week afterwards
Ongoing maintenance catches the next deadline early; our WordPress maintenance and general care plans start at ₹8,000/mo a month.
Worked example: a hypothetical CA firm’s site moving from PHP 7.4 to 8.3
Say a chartered accountancy practice in Ludhiana has a WordPress site built in 2017 with a premium theme, fourteen plugins, and a small hand-written client portal in a subfolder where clients upload documents. The host emails that PHP 7.4 will be removed in thirty days; the office manager tries PHP 8.2 on a Saturday and the portal shows a blank page.
We would switch the domain back to 7.4 the same day, take a backup and clone everything to staging on PHP 8.3. The scan might find the theme two major versions behind (licence expired), two plugins abandoned since 2019, and the portal using mysql_connect() and each(). The quote would list: theme licence renewal and update, two plugin replacements, portal database code moved to PDO with bound parameters, and a full test pass.
Timeline for a job like this: two days for WordPress and plugin work, three to four days for the portal, one day of testing with the office manager uploading real sample files on staging, and a Sunday morning live switch. This is an illustration of how we would handle such a case, not a report on a past client.