Running a WordPress major upgrade step by step with WP-CLI — commands and checkpoints for each stage

The W series has covered what to check before a major upgrade, when to apply it, and what can go wrong. This fourth part covers the remaining question: how to actually run it. Once the preparation is in place and the timing is right, this is the command sequence to follow — one stage at a time, with a confirmation step at each boundary.

Why not use the admin dashboard Update button

The WordPress admin screen has an "Update All" button that runs core, plugin, and theme updates in a single operation. This is the approach to avoid for major upgrades.

The reason is loss of isolation. When core plus five plugins plus two themes update in one pass, any breakage afterward has multiple suspects and no clear way to narrow them down. The dashboard update also displays "Updated successfully" even when PHP warnings or non-fatal errors occurred during the process — making it easy to miss problems until they surface later.

WP-CLI lets you apply core, the DB migration, plugins (one at a time), and themes in separate steps, with a check between each one.

STEP 0 — Final checks before starting

Before touching anything, establish a baseline and take a backup.

# Confirm the current core version and what updates are available

wp core version

wp core check-update



# Export the database with compression

wp db export - | gzip > backup_$(date +%Y%m%d_%H%M%S).sql.gz



# See which plugins have updates pending

wp plugin list --update=available --format=table



# See which themes have updates pending

wp theme list --update=available --format=table

wp core check-update tells you what the upgrade will move to before you start. Running it first also gives you a record of the pre-upgrade state in your session log.

The database backup taken here is the recovery point for the entire upgrade. If core update fails or something breaks in the DB migration step, this is what you restore from. Take it immediately before starting, not hours earlier.

STEP 1 — Update core in version steps

Jumping directly from 6.4 to 6.7 means several DB migration passes run back-to-back, and if something breaks you’re left trying to figure out which intermediate version caused it. Applying one version at a time keeps the problem space smaller.

# Specify the target version explicitly — don’t rely on "latest"

wp core update --version=6.5



# Run the DB migration immediately after core update

wp core update-db



# Verify core file checksums against the WordPress.org reference

wp core verify-checksums

Omitting --version= updates to the latest available, which skips the intermediate-version approach. For major upgrades, name the version explicitly.

wp core update-db aligns the database schema version with the code. Without it, WordPress may run the migration automatically when the admin screen loads — which works, but runs without any visible confirmation that it completed cleanly. Running it from WP-CLI gives you a clear success or failure signal.

wp core verify-checksums compares core files against the WordPress.org checksums for that version. On servers where files were previously modified directly via FTP, this catches discrepancies before they become confusing later. Worth running both before and after core updates.

After the core step: confirm that the admin dashboard loads and that the front page returns a 200 before moving on.

STEP 2 — Update plugins one at a time

With core confirmed stable, move to plugins. One plugin per update, with a check after each one.

# List plugins that have updates available

wp plugin list --update=available --format=table



# Update one plugin at a time

wp plugin update contact-form-7

# ... check the site ...

wp plugin update woocommerce

# ... check checkout flow ...

wp plugin update yoast-seo

A useful order: start with plugins that have a narrow blast radius (SEO, debugging tools, admin utilities), and finish with the high-stakes ones (e-commerce, forms, page builders, authentication).

W3’s failure patterns 2 and 3 — JS library version jumps and PHP minimum requirement changes — are most likely to appear during plugin updates. After updating any plugin with heavy JavaScript dependencies, open the browser console and check for JS errors before calling the step done.

If WP-CLI itself starts throwing errors or crashing after a plugin update, the --skip-plugins --skip-themes rescue flag lets you restart WP-CLI without loading plugins — useful for investigating the problem or rolling back without getting stuck in a broken plugin load loop.

STEP 3 — Update themes

After plugins are confirmed stable, update themes.

# Check which themes have updates

wp theme list --update=available --format=table



# Update the theme

wp theme update twentytwentyfour

If a child theme is in use, the parent theme update doesn’t touch the child theme files — but parent theme hook changes can break child theme behavior if the child overrides hooks that were renamed or removed. After any parent theme update, walk through the pages that use customized template parts.

W3’s pattern 4 — Classic Theme child theme customizations breaking when switching to Block Themes — is most likely to appear here if theme updates involve moving from one theme architecture to another. That’s a case where the theme update decision needs to be treated separately from the core upgrade decision.

Rolling back when something goes wrong

Have these commands ready before starting. Running the upgrade without knowing the rollback path in advance is the kind of setup where panic sets in under pressure.

Roll back core

# Force-reinstall a specific prior version of core

wp core update --version=6.4 --force



# Restore the database from the backup taken in STEP 0

wp db import backup_20260615_090000.sql.gz

--force installs the specified version even if it’s already installed — necessary when rolling back to the previous version that’s already recorded as the current one.

Roll back a plugin

# Force-install a specific prior version of a plugin

wp plugin install contact-form-7 --version=5.8.3 --force

Plugin rollback is covered in detail in the WP-CLI pinpoint rollback post. The version number to restore to is in the version column of wp plugin list.

When core has been rolled back, the situation is the same as the halt-after-core-rollback design: continuing plugin updates on an unstable core adds another variable to an already unclear state. Stabilize core first, then resume.

Summary

Where W1–W4 fit together:

Running updates in stages isn’t a slower path — it’s the path that keeps each step reversible and each problem identifiable. When something breaks after a one-at-a-time update sequence, you know exactly which step caused it. That clarity is what makes the difference between a short investigation and a long one.