How to Migrate a Large WordPress Database Safely
%203.png&w=256&q=75){kind=small}
Why Large Databases Fail to Migrate
A 500 MB+ WordPress database migration fails for three predictable reasons: the dump gets interrupted by an SSH timeout on a slow connection, the import runs out of memory on tables with huge single rows (serialized option blobs), or a naive dump-and-import approach locks tables long enough to cause visible downtime on a site that's still live during the transfer.
Each of these has a specific, well-known fix — none of them require special tools beyond what MySQL/MariaDB already ships with.
Dump with Compression and Locking Control
A 2 GB uncompressed dump typically compresses to 300–500 MB, which meaningfully shortens transfer time over SSH — always compress before transferring across servers, never after.
Transfer and Import in the Background
Run both the transfer and the import inside screen or tmux so an SSH disconnect doesn't kill a multi-hour import:
Handle Tables Too Large for a Single Dump
If wp_postmeta or wp_options alone is multiple gigabytes — common on sites with years of accumulated transient rows or a bloated autoloaded options set — dump that table separately with a smaller batch size to avoid memory spikes, and clean up expired transients before migrating rather than after:
Verify Row Counts After Import
Compare row counts per table between source and destination before declaring the migration done — a truncated import from a timeout or disk-full error can succeed without an obvious error message, leaving a table silently short a few thousand rows:
