How long does a PHP upgrade take? Steps and a timetable

Why does "one click" turn into half a day?

The switch itself takes minutes. The time goes into the backup, updates and testing before it, and the checking after it. Even a small site with no problems usually needs about half a day.

People tend to underestimate how long their own tasks will take. Psychologists call it the planning fallacy. In one well-known study, students expected to finish their thesis in 33.9 days on average; it actually took 55.5 days, and only about 30% finished within their own estimate.¹ Research also suggests that breaking a job into smaller steps can help. So this article splits a PHP upgrade into seven steps, in four groups:

1. Prepare: take stock → back up → update
2. Test: try the new version on a copy of your site first
3. Switch: change the version on your live site
4. Check: click through pages, forms and admin → keep an eye on it for a few days

The switch is one group out of four. Most of the time is spent before and after it.

Before and after take longest.

Jeensuk's takeWhen someone tells you "it'll only take a minute," ask what will. Usually it's the click.

What are the steps, and how long does each one take?

Work through the seven steps below in order. For a small company website with no surprises, plan on 3 to 5 hours. If you have old plugins or code someone customized years ago, plan on 1 to 3 working days.

To be clear up front: we couldn't find any public study that timed real upgrades and averaged them. The times below are ATATAKAI Digital's estimates for a typical company website on shared hosting, with 10 to 20 plugins and no custom code. Only the times hosting companies publish themselves are official figures.

Jeensuk's takeThe more boxes in this table you can't fill in, the longer it takes. It's the unknowns, not the technology, that eat the time.

Why does preparation take so long?

Because you have to build your way back before you leave. You can't switch versions until the backup and updates are done, and both take longer the longer a site has been left alone.

WordPress.org's own order starts with a backup, because "a backup will let you revert your site to how it is right now in the event anything goes wrong." Then you update WordPress, your themes and plugins, check compatibility, and change the version through your host.⁵

Half a backup won't save you. WordPress.org says a backup has two parts, the database and the files, and "you need both to be able to fully restore a typical WordPress site." It recommends keeping at least 3–5 recent backups, stored in different locations.⁶ DreamHost adds a step after updating: check whether each theme and plugin has been updated within the past year.⁷ Plugins nobody has touched in over a year are usually the first to break on a new version.

Back up your database regularly, and always before an upgrade. — WordPress.org, "WordPress Backups"

Jeensuk's takeYou can't roast a frozen turkey. Clicking the button without a backup is the most expensive shortcut there is.

Can you try the new version before you switch?

Yes. Make a test site (a practice copy of your real site, often called a staging site) and run it on the new version first. Checking tools can't catch everything, so you still need time to click through the pages yourself.

DreamHost puts it simply: "A safe way to test the new PHP version is to create a staging website," and if no errors show up, upgrade the live site.⁷ WP Engine also offers a PHP Test Driver that lets a logged-in user preview the site on another version while visitors keep seeing the normal site.³ WordPress.org points to a plugin called PHP Compatibility Checker,⁵ but that plugin's own page now says it "is no longer actively maintained," and that it "cannot detect runtime compatibility issues" because it doesn't actually run your theme and plugin code.⁸

There's a lot that can change, too. PHP's manual lists dozens of behavior changes for the move from 8.3 to 8.4 alone, sorted by feature.⁹ Which of them affect your site is hard to know until you try.

Jeensuk's takeYou taste the gravy before it goes on the table. A test site is your tasting spoon.

What depends on your hosting company?

At most US hosts, the switch itself is quick. What differs is whether you can preview first, how you roll back, and whether your host picks the date for you.

Kinsta: the change "may take up to three minutes," with a couple of seconds of downtime for the WordPress backend only; visitors see no downtime. When something breaks, "the culprit is almost always a plugin or an active theme," and Kinsta recommends testing on staging first.²

WP Engine: the change happens in place, "in just a few moments," without downtime. If the previous version is still on the server, you can switch back temporarily. And there's a catch: "When a version of PHP reaches end-of-life, WP Engine will automatically upgrade all websites to a more current version," and "automatic PHP upgrades cannot be deferred." WP Engine emails your technical contact several times beforehand.³

Bluehost: Websites → Manage Site → Settings → PHP Version → Change PHP Version, and "your site will immediately reflect the new PHP version." Bluehost currently supports PHP 8.2 and above.⁴

Automatic PHP upgrades cannot be deferred. — WP Engine, "PHP Upgrade Guide"

So the risk isn't a slow button. It's that your host may press the button on its own schedule, before you've done steps 1 to 4. If your plan doesn't offer the version you need at all, in our experience the switch can turn into a move to a new plan or a new host, and that's a bigger job.

Jeensuk's takeIf your host has a date on the calendar, put yours two weeks earlier. It's better to be the one who decides when the oven goes on.

Is it one and done? How should you schedule it?

It isn't. Every PHP version has a fixed support window, so you'll be back at this timetable every few years. Pick the date first, and decide at the same time whether you'll do it yourself or hand it off.

Each PHP version gets two years of full support, then two more years of fixes for critical security issues only. PHP 8.2's security support ends on December 31, 2026; 8.3's on December 31, 2027.¹⁰ WordPress.org's statistics (checked October 25, 2026) show 34.2% of WordPress sites still running 8.1 or older, already past support, and 23.3% on 8.2, which ends this year.¹¹ After December 31, that's about 57.5% of sites on versions with no security support.

1. Fine to do yourself: your host switches versions from a menu, you have few plugins and they're recently updated, and you know how to back up and restore. Block half a day on your calendar and follow the timetable.
2. Better to hand off: plugins not updated in over a year, code a former developer customized, a plan without the version you need, or no one to set up a test site.
3. Either way: set a date a month before your current version's support ends. If you're on 8.2, that means sometime in November.

If you meet the do-it-yourself conditions, doing it yourself is perfectly fine. But if you hit three or more boxes you can't fill in while working through the timetable, those boxes are the parts that are hard to do alone. And instead of repeating this every few years, there's also the option of moving to a website that doesn't run on PHP at all.

Jeensuk's takeThanksgiving comes back every year. When a job keeps coming back, deciding who does it and when gets you halfway there.