WP-CLI for Faster Migrations

Most WordPress migration guides point you to a plugin — install it on both ends, click through a wizard, wait for a zip to build. That works fine for a small brochure site, but once your database or media library grows past a gigabit or two, plugin-based migrations start hitting memory limits, execution timeouts, and painfully slow zip compression. WP-CLI skips almost all of that by working directly against the database and filesystem, which is why it’s the tool most experienced WordPress admins reach for on anything non-trivial.

Why WP-CLI Is Faster

A migration plugin has to run inside PHP’s request lifecycle — it’s bound by max_execution_time, memory_limit, and upload size caps, and it usually has to package everything into a single archive before you can move it anywhere. WP-CLI runs from the command line with no such ceiling. Database exports stream directly to disk, file transfers can run in parallel over rsync or SSH, and nothing has to survive a 30-second PHP timeout. On a multi-gigabyte site, this is the difference between a 5-minute migration and a multi-hour one that fails partway through and has to be restarted.

The Core Workflow

The basic WP-CLI migration pattern breaks into four steps, run on both the source and destination server (assuming you have SSH access to each — most hosts that support WP-CLI at all also support SSH):

1. Export the database. wp db export backup.sql dumps the full database on the source server without touching PHP’s memory limit.
2. Move files. Use rsync -avz wp-content/ user@newhost:/path/to/wp-content/ to transfer uploads, themes, and plugins directly server-to-server. Rsync only re-sends changed bytes on a retry, which matters if a large media library transfer drops partway through.
3. Import the database on the destination. wp db import backup.sql, then run wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables to fix serialized URLs across posts, options, and widget data in one pass — a step manual SQL find-replace tools frequently break because they don’t respect PHP’s serialized array format.
4. Flush caches and rewrite rules. wp cache flush and wp rewrite flush clear stale object cache and regenerate permalinks so the destination site doesn’t serve broken links or cached content from the old environment.

WP-CLI vs Plugin-Based Migration

Practical Tips

A few flags make a real difference on bigger migrations. wp search-replace supports --dry-run, which prints exactly what it would change without touching the database — always run this first on a production site. Add --skip-columns=guid if you want post GUIDs to stay pointed at the original domain (some teams prefer this for RSS/feed stability). For multisite networks, pass --network so the replace runs across every site in the network rather than just the current one. And if you’re moving to a host with WP-CLI pre-installed but no direct SSH (some managed hosts run it through a support ticket or dashboard terminal), confirm that access before you plan a migration window around it.

FAQ

Do I need SSH access on both servers?
Yes — WP-CLI runs server-side, so you need shell access on the source and destination. Most VPS and dedicated hosting includes this; some shared plans don’t.

What happens to media files during the database import?
wp db import only handles the database. Media, themes, and plugin files in wp-content are separate and need the rsync (or equivalent file transfer) step.

Is search-replace safe to run on a live site?
Run it with --dry-run first, and take a fresh database export immediately before running it for real — it’s a bulk write operation and should be treated like one.

Can WP-CLI migrate a multisite network?
Yes, with the --network flag on search-replace so URL rewrites apply across every subsite, not just the main one.

Verdict

For a small single-author blog, a migration plugin is fine and arguably less intimidating. Past that — a media-heavy site, a multisite network, or anything you expect to migrate more than once — WP-CLI is worth the one-time learning curve. It removes the size and timeout ceilings that plugins run into, and the same four-command workflow scales from a 500MB site to a 50GB one without changing approach.