How to Migrate a Large WordPress Site Without Upload Limits or Timeouts

Large WordPress sites rarely fail to migrate because of WordPress. They fail because of the route the data takes: one huge archive that has to squeeze through an upload limit, a PHP time limit and a browser download, often more than once. Change the route and most of those limits stop mattering.

This guide explains why big migrations break, how to shrink a site before moving it, and which approaches work when the site is many gigabytes. For the general step-by-step process, see how to migrate a WordPress site to a new host.

Why do large WordPress migrations fail?

Most failures come from server limits that a single large archive hits all at once. The usual suspects are:

• Upload limits. PHP’s upload_max_filesize and post_max_size cap how much one request can carry. Shared hosts often set these far below the size of a full-site archive.
• Time limits. max_execution_time, and web server or proxy timeouts, stop a long-running export, import or extraction halfway.
• Memory limits. Building or unpacking a big archive, or importing a very large SQL file in one go, can exceed memory_limit.
• Disk space. An archive needs room for the archive itself plus the extracted files, so the destination may temporarily need twice the site’s size.
• The round trip through your computer. Downloading 20 GB and uploading it again is slow, and a dropped connection means starting over.

Raising limits helps, but on shared hosting you often cannot raise them far enough. That is why the transfer method matters more for big sites than for small ones.

How big is your site, really?

Before choosing a method, measure. In the WordPress admin, Tools → Site Health → Info → Directories and Sizes shows the size of the uploads, themes and plugins folders and the database. Two numbers matter:

• Total file size, which is mostly wp-content/uploads.
• Number of files. Fifty thousand small thumbnails can be slower to move than a few large videos, because every file has overhead.

Also check the database size. Stores, membership sites and sites with heavy logging plugins can have databases of several gigabytes, which need a different import strategy from a typical blog.

Shrink the site before you move it

The fastest data to migrate is data you do not need to send. Look for these before you start:

• Old backups stored inside wp-content. Backup plugins often keep archives in a subfolder. Migrating them copies your site several times over.
• Cache folders. Page and object caches rebuild themselves on the new host.
• Post revisions and transients. Revisions can make up a large part of an editorial database; transients are temporary values WordPress recreates.
• Spam and trashed comments.
• Log files and development leftovers such as *.log files or node_modules folders in a theme.

You can delete these beforehand, or exclude them during the migration. SwiftMigrate’s Settings let you skip post revisions, transients and spam or trashed comments, skip whole database tables, and exclude files and folders with rules such as *.log or */node_modules.

Four approaches that work for large sites

If you have SSH on both servers and like the command line, rsync for files plus wp db export and wp db import for the database is hard to beat. If you are on shared hosting without SSH, a chunked server-to-server transfer gives you similar resilience from the WordPress admin.

How a chunked server-to-server transfer handles size

This is how SwiftMigrate approaches a large site, and why it is not limited by the size of a single upload:

1. It negotiates the request size. During the pre-flight check, the plugin reads the largest request the new host accepts and keeps every request below it.
2. Small files travel together; large files are split. Thousands of thumbnails are packed into a handful of requests, and a 2 GB video is cut into chunks that each fit the limit.
3. Several streams run at once. Four by default, which is safe on shared hosting. On a VPS or dedicated server, 8 to 12 streams is usually faster.
4. Every chunk is checksummed. The new host rejects anything that does not match its SHA-1 checksum, and after the transfer it confirms every chunk. Missing or damaged chunks are resent before a restore is allowed.
5. The database moves in ranges. Tables are exported by primary-key ranges, imported into temporary tables, and switched over in one step, so a half-imported database never goes live.
6. It resumes. Progress is saved on the server. Close the tab, lose your connection, come back and press Resume.

Tuning for a slow or strict host

If transfers time out or get blocked, change one setting at a time on the sending site:

• Timeouts: lower Parallel streams and Maximum request size. Fewer, smaller requests are gentler on a slow host.
• Very large table rows (page builders, logs): lower Database rows per chunk.
• HTTP 403 or 406 errors: a security plugin or firewall is blocking binary uploads. Turn on Firewall-friendly mode, which encodes data as text. It is about 35% slower but gets through most filters.
• Self-signed certificate on the new host: turn off SSL verification only if you trust the network between both servers. SwiftMigrate then also encrypts every request end to end with the migration key.

Plan disk space on the new host

A safe migration needs more room than the site itself. The new host has to hold the incoming site while it is being verified, and if you keep a rollback copy (recommended, and on by default in SwiftMigrate), it also keeps the previous database and replaced files until you delete them. As a rule of thumb, have at least twice the site’s size free, and delete the rollback copy once you are happy with the new site.

Migrating a busy store or membership site

For large WooCommerce or membership sites, the database keeps changing while you move it. Orders, sign-ups and comments made on the old site during the transfer may not all be captured. To avoid losing anything:

• Run the migration in your quietest hours.
• Pause content editing, and consider a short maintenance window for checkout during the final restore and DNS switch.
• After restoring, compare the latest order or user ID on both sites before switching DNS.

Our WordPress migration checklist includes these steps in order. If the site is business-critical and you would rather not run the move yourself, our web development team plans and executes large migrations. All our migration guides are collected in the WordPress migration guide.