A browser importer that stops at 30%, returns 504 or shows a blank screen does not reveal whether MySQL rejected a statement, PHP timed out or the proxy merely stopped waiting. Repeating the same import can leave partial tables and make the next attempt harder to interpret.
Freeze the source consistently
Choose a maintenance window appropriate to the site. For an active membership or shop, decide how new writes will be paused or reconciled. Record the source database name, table prefix, size, table count, storage engines and export time.
Do not combine exports taken at different times without a deliberate delta process. Keep the source online for rollback until the destination is verified.
Inspect what makes the database large
Find the largest tables before transferring. Logs, sessions, analytics events, transients, scheduled-action history and abandoned plugin tables may dominate size.
Delete data only when its retention and application role are understood. Optimising or purging during an emergency changes the source; often it is safer to migrate first and clean later with a separate backup.
Create a reliable export
Prefer a hosting backup tool, WP-CLI or mysqldump over a single browser request. Compression reduces transfer time and storage but does not fix logical SQL errors.
mysqldump --single-transaction --quick --default-character-set=utf8mb4
database_name | gzip > wordpress.sql.gz--single-transaction is useful for transactional tables, not a universal lock-free guarantee. Avoid putting passwords directly in shared shell history.
Check space and transfer integrity
The destination may need room for the compressed archive, expanded SQL, database data and temporary files simultaneously. Confirm disk and inode headroom before import.
Transfer over a reliable channel, then compare a checksum:
sha256sum wordpress.sql.gzMatching checksums prove the archive arrived unchanged, not that it contains a complete export.
Retain the checksum beside the migration record for later verification.
Use a server-side import
Create an empty target database with the intended charset and collation. Import through the command line or a host-provided server-side restore facility so PHP upload and proxy timeouts are not part of the path.
gzip -dc wordpress.sql.gz | mysql database_nameCapture standard error and exit status. If the host offers no shell, split with a database-aware tool or ask support; arbitrary text splitting can cut a statement in half.
Diagnose an import that still fails
Read the first actual MySQL error. Common causes include packet limits, insufficient privileges, unsupported collations, invalid definers, duplicate objects, disk exhaustion or a server-version difference.
Do not increase every limit blindly. Correct the narrow cause, recreate a clean destination and import once. Continuing into a partially populated database can mix old and new rows.
Prove database completeness
Compare table counts, important table row counts and recent known records. Confirm the configured prefix and check for failed or crashed tables. Application-level validation matters: login, content, search, media references, scheduled tasks and writes.
For transactional sites, reconcile orders or submissions created near the freeze. A homepage is a weak database test.
Complete URL and environment changes
Run a serialization-aware dry-run before replacing domains or paths. Update database credentials securely and inspect plugins containing absolute filesystem paths.
Keep verbose errors private. Remove SQL archives from web-accessible directories and revoke temporary users or permissions once the move succeeds.
Make large migrations repeatable
Maintain off-server backups, documented database size trends and periodic restore tests. Recurring maintenance can prune approved operational tables before they become enormous and verify that the host can export and import within the recovery window. The successful outcome is a measured, reversible transfer—not an importer reaching 100%.