Update WordPress with WP-CLI, staging checks and a coordinated rollback

A WordPress update changes a running application, not just a version number. Core, plugins, themes, PHP and the database schema can interact, and a database migration can make a file-only rollback incomplete. A reliable update procedure records the starting state, tests the changes on a controlled copy and verifies the business workflow after the live change.

Inventory the installation and runtime before updating

pwd
wp --info
wp core version
wp plugin list --fields=name,status,version,update,update_version
wp theme list
php -v

The PHP version reported in the shell can differ from the PHP version serving web requests. Confirm the web runtime through the hosting tools or application health information as well. Check compatibility requirements for the particular plugin, theme and core release instead of assuming that the newest component supports your current stack.

Record the installed versions and whether a component is active. Include must-use plugins, custom code and any external service integrations. A failure caused by a payment or authentication integration may not be visible on the public home page.

Back up both database and files outside the web root

umask 077
BACKUP_DIR="$HOME/private-backups/wp-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$BACKUP_DIR"
wp db export "$BACKUP_DIR/database.sql"
tar -czf "$BACKUP_DIR/site-files.tar.gz" -C "$PWD" .
gzip -t "$BACKUP_DIR/site-files.tar.gz"

Verify the destination is outside the WordPress tree before creating the archive. Check each command's result and test that the SQL file is nonempty. The backup should include the configuration and content needed to restore the application, with suitable protection for the secrets and customer data it contains.

Files and SQL captured at different times can disagree on an actively written site. Plan a write pause or another application-supported consistency method when that matters. A provider snapshot or paid VPS backup can be useful, but restoring it also rolls back unrelated changes within its scope.

Rehearse a controlled update sequence on staging

Start with a staging copy that has passed a restore test. Update a small, understood set of components and inspect the result after each meaningful change. Avoid turning a troubleshooting exercise into an unreviewed update of every plugin and theme.

wp core check-update
wp maintenance-mode activate
wp core update
wp core update-db
wp core version
wp core verify-checksums

These commands update the application and database; they are not a dry run. For plugins, choose an installed slug from the inventory and use wp plugin update with that slug after reviewing its release notes. Repeat for themes as appropriate. The exact sequence can depend on vendor compatibility guidance, so a generic command list is not a substitute for the component's migration instructions.

Checksum verification compares supported files with the upstream release; it does not establish that the entire site is free of malicious code. Custom and commercial components may not have the same public checksum coverage. Investigate findings in context instead of automatically deleting reported files.

Verify more than the home page

• Open representative content and verify uploads, image derivatives and page templates.
• Test login, password reset, forms and the database-backed workflows your business depends on.
• Use a sandbox for checkout or billing integrations; do not create unintended customer charges.
• Review PHP/application logs, scheduled jobs, cache behavior and error responses.

wp maintenance-mode deactivate
wp maintenance-mode status
curl --fail --silent --show-error -I https://staging.example.com/

Clear or refresh the caches involved in the change using their documented controls. A cached success page can hide a broken application, and clearing every cache repeatedly can create load without identifying the cause. Compare uncached and ordinary requests where your architecture supports that safely.

Plan a rollback that includes data written after the backup

If the update fails, first determine whether the problem is configuration, code compatibility or a schema change. A matching pre-update file archive and SQL export can restore a known state, but importing the old database overwrites newer records. On a live shop, that can include customer orders placed during the maintenance period.

Rehearse the rollback on the isolated staging copy: verify its database name, restore the intended files and import the paired SQL backup there. Do not copy a production database password into an unprotected test environment. If production must be restored, coordinate the write window and any data reconciliation instead of blindly reversing files and hoping the schema remains compatible.

Repeat the proven change on production and record it

After staging acceptance, prepare a current production recovery set, apply the reviewed updates in an appropriate window and repeat the same business checks. Keep the previous release and backup until the change has been observed long enough to meet your recovery policy.

Record the versions installed, important migration steps, verification results and any follow-up work. Regular, tested updates are easier to reason about than a large catch-up operation performed only after a serious incident.

Primary documentation

• WP-CLI core commands
• WP-CLI database export
• WP-CLI maintenance mode
• WordPress hardening guide