A Safe WordPress Upgrade Process: Before, During and After

Step 1: Backups and Snapshots First

Before touching anything, take a filesystem snapshot and a database dump. Do not rely on your host’s nightly backup alone; take your own immediately before the window. On a VPS or cloud instance, trigger a volume snapshot through your provider API or panel. For the database, use mysqldump or WP-CLI. Store the dump outside the web root and off the origin server.

Take the database dump

SSH into the server and run WP-CLI from the WordPress root. This produces a single-transaction dump so InnoDB tables stay consistent:

wp db export /var/backups/wp-$(date +%Y%m%d-%H%M).sql --single-transaction --quick
gzip /var/backups/wp-$(date +%Y%m%d-%H%M).sql

Verify the file exists and is not zero bytes: ls -lh /var/backups/. A zero-byte dump means the credentials failed or the path is wrong; fix that before continuing.

Snapshot the filesystem

Copy wp-content, wp-config.php, and your custom mu-plugins directory. The core files are replaceable, your uploads and custom code are not:

tar -czf /var/backups/wp-content-$(date +%Y%m%d-%H%M).tar.gz wp-content wp-config.php

If you run behind a CDN such as described in our WordPress behind a CDN setup guide, note your current cache state so you can purge after the update. Pitfall: forgetting wp-config.php when you later need to restore salts or DB credentials. Verification: confirm the tarball extracts cleanly in a temp dir with tar -tzf.

Step 2: The Order of Updating (Step-by-Step Process)

1. Put the site in maintenance mode and confirm the .maintenance file is written.
2. Check PHP 8.3 compatibility of plugins and themes before touching versions.
3. Update plugins one by one, starting with must-use and security plugins.
4. Update the active theme and parent theme if using a child theme.
5. Update WordPress core with wp core update.
6. Run wp core update-db to apply database schema changes.

Never update core first. Core 6.7 in 2026 expects plugins to already declare compatibility; updating out of order triggers fatal errors from plugins calling removed functions. Start with a compatibility pass: use the PHP 8.2 compatibility checks workflow adapted for 8.3, running wp plugin list --fields=name,version,update to see what is pending.

Update plugins then themes then core

Use WP-CLI so you get transactional output. Update a single plugin and check the site immediately:

wp plugin update akismet --dry-run
wp plugin update akismet
wp theme update twentytwentysix
wp core update
wp core update-db

The --dry-run flag on the first command shows what would change without writing. Pitfall: bulk-updating all plugins with wp plugin update --all and then not knowing which one broke the site. Update one at a time, reload the front end after each, and read wp-content/debug.log if WP_DEBUG_LOG is true. For teams automating this, the patterns in our WP-CLI commands worth automating article show how to script the sequence safely.

Step 3: Rollback Plan Before You Start

A rollback plan is written before the update, not improvised at 2 a.m. Decide now: if the front end whitescreens, you restore wp-content from the tarball and the database from the dump. If only one plugin is at fault, roll back just that plugin to its previous version.

Roll back a single plugin

WP-CLI can reinstall a specific earlier version. Find the previous version in your backup or the repo, then:

wp plugin install akismet --version=5.3 --force

Replace 5.3 with the version you ran before. The --force flag overwrites the broken newer copy. Verification: wp plugin list shows the old version and the site loads.

Full restore

For a total failure, restore in this order: stop the web server or enable maintenance, extract the filesystem backup, import the database dump, then clear object and page cache:

tar -xzf /var/backups/wp-content-20260115-0200.tar.gz -C /var/www/html/
wp db import /var/backups/wp-20260115-0200.sql
wp cache flush

Pitfall: importing the dump while the site still writes to the database creates mismatched post IDs. Always block traffic first. If you use a managed service like custom WordPress development and maintenance, your provider should already script this restore path for you.

Step 4: Post-Update Checks

After updates, do not assume success because the dashboard loads. Check the front end, admin, cron, and logs. Use WP-CLI to confirm versions and database integrity:

wp core version
wp plugin list --fields=name,status,version
wp theme list --fields=name,status,version
wp cron event list
wp db check

wp db check runs CHECK TABLE on all tables and reports corruption. Run wp cron event run --due-now to fire scheduled tasks and watch for errors. Open the homepage, a single post, an archive, and wp-admin in a browser or with curl -I to confirm HTTP 200.

Read the error log

Tail the PHP error log while browsing the site: tail -f /var/log/php8.3-fpm.log. Any fatal error, deprecated notice from your own theme, or database warning must be resolved before you call it done. If you serve over TLS per our HTTPS and mixed content setup notes, also confirm no mixed-content warnings appear after core changes.

Pitfall: clearing only the WordPress object cache but leaving the CDN or reverse proxy serving stale HTML. Purge every layer. Verification is complete when the same URLs you tested pre-update return identical content with no new log entries.

Action Checklist

• Export the database and tar wp-content before any update.
• Update plugins, then themes, then core, one at a time with WP-CLI.
• Keep the rollback tarball and dump path written down before you begin.
• Verify with wp db check, cron run, and front-end requests.
• Purge CDN, page cache, and object cache after the final step.

Need this process run for you? Our team handles version upgrades, compatibility testing and rollback planning on production sites every week. See our WordPress development services for managed update windows.

Frequently asked questions

What is the safest order for a WordPress update?

Plugins first, then themes, then core, followed by wp core update-db. This prevents old plugins from breaking against new core functions.

How do I know the update worked?

The front end and admin return HTTP 200, cron events run without errors, wp db check passes, and the PHP log shows no new entries.

Can I roll back without a full backup?

Yes for a single plugin or theme by reinstalling the previous version with WP-CLI, but a full rollback needs the pre-update dump and tarball.

References & further reading

• WordPress Developer Documentation
• WordPress Theme Handbook
• WordPress Plugin Handbook