How to migrate a very large website

A large website — one with a database running into gigabytes, tens of thousands of images, or years of accumulated content — follows exactly the same migration principle as a small one: copy first, test second, switch DNS last. What changes is the scale of each step, and a few of the tools you reach for to move that much data without hitting limits along the way.

Why size changes the approach, not the order

The temptation with a large site is to look for shortcuts that skip testing, on the theory that a bigger job needs to move faster to stay on schedule. The opposite is usually true: a large site has more pages, more plugins, more integrations and more edge cases than a small one, which means more can be quietly wrong after a big transfer — not less. Budget more time for testing, not less, in proportion to the size of the site.

Moving the files without going through your own connection

Downloading gigabytes of files to your own computer and then re-uploading them to the new host is usually the slowest possible way to move them, limited by your own internet connection's upload speed rather than by anything on either server. Moving files directly between the two hosts — server to server — is dramatically faster, since server connections are typically much faster than a home or office connection in either direction. See moving files directly between two hosts for how to set this up.

Handling a database too large to import normally

Most browser-based import tools, including phpMyAdmin, have an upload limit that a large database export can easily exceed — commonly somewhere around 50MB. Two practical options:

• Compress the export first. A .sql file compresses well, often shrinking to a fraction of its original size, which may be enough to bring it under the limit.
• Import via the command line instead, which has no such upload limit:

mysql -u newuser -p newdatabase < backup.sql

For an export still too large even for this, see importing a database too large for phpMyAdmin, which covers splitting an export into smaller pieces and importing them in sequence.

Media libraries deserve their own transfer

A large wp-content/uploads folder, or equivalent, is often the single biggest part of a large site by file size, and bundling it into one enormous archive alongside everything else increases the chance of a transfer timing out partway through. Moving it as a separate, dedicated transfer — ideally server to server — makes it easier to confirm it completed fully, and easier to resume if it does not.

Testing at scale

A full page-by-page test is impractical on a site with thousands of pages, so test strategically instead:

• A representative sample of page types — a product page, a category page, a blog post, a landing page — rather than every individual page.
• Every plugin or integration that does something functional: search, forms, payment, membership areas.
• The admin area and content editing, since a large content library often surfaces database issues here first.
• Site-wide search, which depends on the database having imported completely and correctly.

Switching DNS and watching resource usage

Once testing passes, switch DNS following the same order as any migration — lower the TTL in advance, then change the nameservers or A record, and keep the old hosting running for about a week afterwards. For a large, high-traffic site, also watch server resource usage on the new account in the days after the switch, since real traffic at scale sometimes reveals a bottleneck that a testing session, by nature lower-traffic, could not.