Migrating a huge WordPress site — tens or hundreds of gigabytes of media, a massive database, years of content — breaks the easy tools that work fine for small sites. One-click plugins hit their size limits, standard uploads time out, and a naive approach stalls halfway. But large-site migration is entirely doable; it just requires methods built for scale, moving the bulky media and the big database with the right techniques rather than the beginner ones. This guide covers exactly those methods.

You will learn why large sites need a different approach, how to move gigabytes of media efficiently, how to handle a very large database without timeouts, the tools and methods suited to scale (server-side transfer, staging, host migration services), how to keep the site consistent during a long transfer, and how to test and cut over a big site. By the end you will know how to move a large WordPress site reliably, without the failures that plague the small-site tools at scale.

Why large sites need a different approach

The tools and methods that make a small WordPress migration effortless — one-click export-import plugins, browser uploads, a single database dump — run into hard walls at scale. One-click plugins have import size limits that a 100GB site blows past. Browser and PHP uploads time out on huge files. A single massive database export can exceed memory limits or time out during import. What is trivial for a small site becomes a series of failures for a large one.

The reason is that large sites stress the limits of the convenient tools: file-size caps, execution time limits, memory limits, and upload restrictions all become binding constraints when you are moving gigabytes and a huge database. The convenient tools were built for the common case of a modest site, and a large site is simply outside their comfortable range.

So a large-site migration is not about trying harder with the same tools — it is about using methods designed for scale. The core idea is to move the two components (files and database) using efficient, resilient techniques rather than the beginner ones: transferring media in a way that does not time out, and moving the database without hitting memory or execution limits. Once you switch to scale-appropriate methods, a large migration becomes as reliable as a small one — it just uses different mechanics.

Moving gigabytes of media efficiently

The bulk of a large WordPress site is usually the media — the uploads folder full of images and files, which can be the lion’s share of that 100GB. Moving this efficiently is the biggest practical challenge, and the key is to use transfer methods that are resilient and do not depend on a single fragile upload. Rather than a browser upload that times out, use robust server-level transfer.

• Server-to-server transfer: move files directly between hosts (via SSH/rsync or the host’s tools) rather than downloading to your computer and re-uploading — far faster and more resilient.
• Compress before moving: archive the media into a compressed file on the server, transfer the single archive, and extract on the new host — fewer, larger transfers beat millions of tiny ones.
• Sync in stages: tools like rsync can transfer in chunks and resume if interrupted, so a huge transfer that hits a snag continues rather than restarting.
• Move media separately: handle the giant media folder as its own transfer, apart from the code and database, so each is managed with the right method.

The unifying principle is resilience and efficiency: a large media transfer must be able to move a lot of data without timing out, and ideally resume if interrupted, which is exactly what server-level tools like rsync or a compressed archive over SSH provide, and what a browser upload does not. Moving the media as its own resilient transfer, separate from the smaller code and database, is what makes the bulk of a large migration tractable. This is the single most important technique for big sites.

Handling a very large database

A large site’s database can also be too big for the convenient tools — a single phpMyAdmin export or import can time out or exceed memory limits when the database is huge. So a large database needs export and import methods that handle size without hitting those walls, typically at the command line rather than through a web interface.

The scale-appropriate approach is to use command-line database tools (mysqldump to export, and the mysql client to import) over SSH, which handle large databases far more reliably than a browser-based phpMyAdmin, without the web server’s execution-time and upload limits. For extremely large databases, you can also export and import in pieces, or compress the dump during transfer, so no single operation is too large to complete.

So just as with media, the solution for a big database is to move it with resilient, size-appropriate tools rather than the beginner ones. Command-line export and import bypass the web-interface limits that cause large-database migrations to fail. If you are not comfortable at the command line, this is one of the strongest arguments for using a host-assisted migration or a server-side tool for a large site, since those handle the big database with the right methods for you. Either way, the database, like the media, must be moved in a way that its size does not defeat.

Tools and methods suited to scale

Several approaches are specifically well-suited to large-site migration, and choosing one of them (rather than fighting the small-site tools) is the key decision. First, server-side migration tools and the paid tiers of migration plugins are built to move large sites without the import size limits and timeouts of the free tools, often transferring directly between servers.

Second, host migration services are often the best option for a large site: many quality hosts will migrate even a very large site for you as part of their service, using professional tools and server-level access to handle the scale reliably — turning a daunting large-site move into something their team simply does. This removes both the technical difficulty and the risk of a big migration.

Third, staging environments can help: some hosts let you build and sync a large site to a staging area with efficient tools, then push it live. And underlying all of these, direct server access (SSH) with command-line tools is the most powerful and reliable method for those comfortable with it. So the menu for a large site is: a server-side or paid migration tool, a host migration service, a staging workflow, or hands-on SSH — any of which is built for scale, unlike the one-click plugins that fail at it. Matching your large site to one of these scale-appropriate methods is what makes the migration succeed.

Keeping the site consistent during a long transfer

A large-site migration takes longer — potentially hours for the media and database to fully transfer — and that extended window raises a consistency issue: if your site changes during the long transfer (new content, new orders, new uploads), the copy you are moving can become out of date before it goes live. This matters more for large sites precisely because their transfer takes long enough for meaningful changes to accumulate.

The approaches to handle this mirror the store-migration logic. For a site with active changes, you can freeze content changes during the migration window, or plan the transfer for a low-activity period, or do an initial bulk transfer and then a final sync of just the changes right before cutover (which resilient tools like rsync make efficient, transferring only what changed since the first pass). The goal is that the version that goes live reflects the current state, not a stale snapshot.

So for a large site, plan for the transfer duration and its consistency implications: decide how to handle changes during the long window, ideally with a final incremental sync just before go-live so the new site is current. This is an extra consideration that small, fast migrations do not face, and overlooking it can mean the migrated large site is missing the latest content or activity. Managing consistency across the long transfer is part of doing a big migration properly.

Testing and cutting over a big site

Once the large site is transferred and assembled on the new host, testing is more involved simply because there is more to check — but the principle is unchanged: verify privately before going live. Using a hosts-file preview or temporary URL, spot-check across the breadth of the site: key pages and posts, media loading from the huge uploads folder (a common weak point after a large media transfer), styling, forms, logins, and any heavy or dynamic features. Confirm the big database imported completely by checking content counts and that everything is present.

When the large site is verified working, cut over by updating DNS, keeping the old host running through propagation — and here, having lowered your TTL beforehand is especially valuable, because you do not want a long propagation window on top of an already-long migration. Do a final incremental sync of any changes just before or at cutover if you planned one, so the live site is current. Then re-verify on the live site and confirm email and integrations.

Finally, retire the old host only once you are certain the large site is fully and correctly serving everyone — which for a big, complex site warrants extra care and a longer confirmation period. So a large-site migration follows the same test-cutover-verify-retire arc as any migration, just with more to move, more to check, and consistency to manage across a longer transfer. Use scale-appropriate methods for the media and database, manage the long-window consistency, verify thoroughly, and even a 100GB+ WordPress site moves reliably — the failures come only from trying to force big sites through small-site tools.

FAQs

How do I migrate a large WordPress site (100GB+)?

Use scale-appropriate methods, not one-click tools. Move the bulky media with resilient server-level transfer (rsync/SSH or a compressed archive between servers), handle the large database with command-line tools (mysqldump/mysql) to avoid timeouts, or use a host migration service or server-side migration tool built for scale. Manage consistency across the long transfer with a final sync, then test thoroughly, cut over DNS, and retire the old host last.

Why do migration plugins fail on large WordPress sites?

Because large sites blow past the limits the convenient tools were built around: one-click plugins have import size caps, browser and PHP uploads time out on huge files, and a single massive database export can exceed memory or execution-time limits. What’s trivial for a small site becomes a series of failures at scale — the fix is scale-appropriate methods (server-side transfer, command-line database tools, or a host migration service), not the small-site plugins.

How do I move gigabytes of media efficiently?

Use resilient server-level methods: transfer directly between hosts via SSH/rsync rather than downloading and re-uploading through a browser; compress the media into an archive, move the single file, and extract on the new host; and use tools like rsync that transfer in chunks and resume if interrupted. Handle the giant media folder as its own transfer, separate from the code and database. Resilience and efficiency are the goal.

How do I migrate a very large database?

Use command-line tools over SSH — mysqldump to export and the mysql client to import — rather than a browser-based phpMyAdmin, which times out or exceeds memory limits on huge databases. For extremely large databases, export and import in pieces or compress the dump during transfer. If you’re not comfortable at the command line, a host-assisted migration or server-side tool will handle the big database for you.

How do I keep a large site consistent during a long migration?

Because a big transfer takes hours, the site can change before it goes live. Handle it by freezing content changes during the window, migrating in a low-activity period, or doing a bulk transfer then a final incremental sync of just the changes right before cutover (efficient with tools like rsync). The goal is that the version going live reflects the current state, not a stale snapshot from when you started.

What’s the easiest way to migrate a huge WordPress site?

A host migration service. Many quality hosts will migrate even a very large site for you as part of their service, using professional server-level tools to handle the bulky media and large database reliably — removing both the technical difficulty and the risk. It’s often the best option for a big site, turning a daunting move into something the host’s team simply does for you.

The bottom line

Migrating a large WordPress site of 100GB or more is entirely achievable, but it breaks the easy tools that make small-site migration effortless — one-click plugins hit their import size caps, browser uploads time out, and a single massive database dump exceeds memory or execution limits. The fix is not to try harder with those tools but to switch to methods built for scale. For the media, which is usually the bulk of a large site, use resilient server-level transfer — direct server-to-server copying via SSH/rsync, or a compressed archive moved as a single file and extracted on the new host, with tools that transfer in chunks and resume if interrupted — handled as its own transfer separate from the smaller code and database. For the large database, use command-line tools like mysqldump and the mysql client over SSH rather than a browser-based phpMyAdmin, so its size does not cause a timeout.

Beyond the mechanics, two things distinguish a big migration. First, choose a scale-appropriate approach up front — a server-side migration tool or paid plugin tier, direct SSH access, a staging workflow, or, often best of all, a host migration service whose team moves even very large sites for you with professional tools. Second, manage consistency across the long transfer window: because moving gigabytes takes hours, the site can change before it goes live, so freeze changes, migrate in a quiet period, or do a bulk transfer followed by a final incremental sync just before cutover so the live site is current. Then verify thoroughly (media loading and a complete database import are the common weak points), cut over via DNS with a pre-lowered TTL so propagation is not a long extra wait, and retire the old host only once you are certain the big site is serving everyone correctly. Use the right methods for scale and manage the long window, and even a 100GB+ site moves as reliably as a small one — the failures come only from forcing big sites through small-site tools.

When you are ready, you can start with Hostinger and use code PROTIPS for the reader discount. Large WordPress sites (100GB+) break one-click tools — size caps and timeouts. Use scale methods: move media via server-to-server transfer (SSH/rsync or a compressed archive), the big database via command-line mysqldump/mysql, and prefer a server-side tool or host migration service. Manage consistency over the long transfer with a final incremental sync, lower TTL for a fast cutover, verify media and the full database, and retire the old host last.