Moving or Restoring a WordPress Site: Size Limits, Downtime and a Plan That Works

Moving or Restoring a WordPress Site: Size Limits, Downtime and a Plan That Works
Moving a site and restoring a site look like different jobs. Underneath, they are the same job, and they go wrong in the same places.

Two jobs that turn out to be one
Someone moves a site to a new host because the old one got slow. Someone else restores a site because the old one got hacked, or an update broke the checkout. One of these is planned and the other is an emergency. The steps are nearly identical.

In both cases you take a copy of the files and the database, put them on a clean server, point the new copy at its database, fix the URLs, and switch traffic across. Every failure you will meet falls into one of a few groups. The copy was too big for something to handle. The copy was incomplete. The new server was set up differently from the old one. Or nobody tested before switching.

That is why a rehearsed move is the best preparation for a restore, and a rehearsed restore is the best preparation for a move. If you have done one calmly, the other holds no surprises.

This guide goes through the whole process in the order you will meet it. It covers what to collect, where size limits appear, how to test, how to cut over with little downtime, and what to check afterwards. It assumes a standard self-managed or hosted WordPress site and does not depend on any one tool.

What you are actually moving
A WordPress site is more than the pages you see. Before you move anything, list the parts, because forgetting one is the most common reason a move looks fine and then misbehaves.

The database
Posts, pages, comments, users, orders, settings and most plugin data live in the database. Every one of those tables has to come across. If your plugins create their own tables, they must come across too, and the table prefix in wp-config.php has to match what the tables are called.

The files
The files that matter are the wp-content folder, which holds themes, plugins and uploads, and the wp-config.php file with its settings. WordPress core itself can be reinstalled fresh, which is often cleaner than copying it. Uploads are usually the largest part by far.

The things outside WordPress
These are the items people forget:

Server rules such as an .htaccess file or nginx configuration, including redirects.
Cron jobs set up at the server level.
Email routing, since mail often depends on DNS records and on the old host's mail server.
SSL certificates and how they renew.
Any must-use plugins or custom code outside the usual folders.
Third-party services tied to the domain or server address, such as payment gateways that whitelist an IP.
Write the list down before you start. A move rarely fails because of the database. It fails because of something nobody remembered was there.

Three ways to move a site
There are three broad methods, and each fits a different situation.

Plugin-based migration
A migration plugin packages the whole site into one file or a set of files, which you then import on the destination. This is by far the most popular route because it needs no command line and works on nearly any host. It is a good fit for small and medium sites, one-off moves and people who are not comfortable with servers.

Its weaknesses are the ones we will spend the next section on: size limits, time limits, and the fact that the plugin has to be installed and working on both ends.

Manual migration
You export the database with a tool such as phpMyAdmin or the command line, copy the files by SFTP or an archive, import the database on the new server, edit wp-config.php, and search-replace the URLs. It is more work, but it has no plugin size limit, and you can see every step. It suits larger sites and anyone who wants control.

Host-assisted migration
Many hosts will move a site for you, especially if you are signing up as a new customer. This is the least effort if it is offered. The risk is that you are trusting someone else's process, so test the result as thoroughly as you would your own work.

Where size limits bite
Size is the first wall most people hit. It appears in more places than you might expect, so it helps to know each one.

Upload limits on the destination
When you import a packaged site through the browser, the file travels as an upload. Your PHP settings, upload_max_filesize and post_max_size, set the largest file the server will accept. Many hosts also set their own web-server limit on top. If the package is larger than the smallest of these, the import fails, often with an unhelpful message.

The standard plugin from All-in-One WP Migration is a good illustration. Its WordPress.org page says plainly that the upload limit is set by the hosting company rather than by the plugin, and that very large backups may not go through that way. It also notes that a paid extension adds uploads designed to get around the host's file-size restrictions. That is an honest description of the situation, and the practical result is that the real limit depends on both the plugin version you run and the server you run it on. If you want a longer walk-through of how that free-tier ceiling shows up in practice and what the choices are, the article on the All-in-One WP Migration free import limit goes into it in more detail. Check the numbers against the current plugin and your own host before you plan around them, because both change.

Ways around an upload limit
You have several options if the package is too large for the browser upload:

Raise the PHP limits through the hosting control panel or ask support to do it. This is often the quickest fix.
Upload the package by SFTP into the plugin's own backup folder, if the tool supports importing from a file already on the server.
Slim the site first. Delete old post revisions, clear spam comments, remove unused themes and plugins, and remove unused media. This makes every later step faster too.
Split the move. Transfer the database in one operation and the uploads folder in another, using SFTP or an archive extracted on the server.
Use a manual migration, which has no upload ceiling because nothing goes through the browser.
Time and memory limits
Size is not the only limit. Importing a database means running a lot of queries, and extracting an archive means a lot of file writes. PHP's execution time and memory limits apply to both. A move that works for a small site can time out on a large one, and the failure may leave you with a half-imported database. If an import stops partway, do not try to patch the result. Delete the partial site and start the import again with higher limits.

Timeouts on the export side
The same limits apply when you create the package on the old host. A plugin export that dies partway can produce an incomplete archive without saying so. Check the size of the file against what you expect. If the uploads folder is a certain size on disk, an archive far smaller than that deserves suspicion. When in doubt, count the files inside, or compare a handful of recently added images.

Set up the destination before you touch the old site
A calm move starts with a destination that matches the source closely enough to run the same code.

Match the environment
Check the PHP version, the database engine and version, and the PHP extensions the site needs. A site that runs happily on one PHP version can show warnings or fatal errors on another, especially with older plugins. If you are changing PHP versions as part of the move, change one thing at a time. Move first on the same version, then upgrade PHP afterwards and test again. That way, if something breaks, you know which change caused it.

Create the database and user
Make an empty database and a database user with permission to it. Note the host name, because it is not always localhost. Put these details in a safe place, not a chat window, and put them in wp-config.php once the import is done.

Use a temporary address
Most hosts give you a temporary URL, or you can edit your own computer's hosts file to point the domain at the new server without touching real DNS. That lets you view the new copy under the real domain name while the public still sees the old site. It avoids a whole class of mixed-address problems, because the site can believe it lives at its real URL from the first moment.

Doing the move, step by step
This is the plain sequence for a manual move. Plugin-based moves compress several of these steps into one, but the checks still apply.

Freeze changes. Tell anyone who edits the site to stop. On a shop, pick a quiet time, or accept that you will need to reconcile orders afterwards.
Take a fresh backup of the old site, database and files, and keep it untouched. This is your way back.
Copy the files to the new server. Verify the count and size afterwards.
Import the database into the new empty database.
Update wp-config.php with the new database details. Leave the table prefix matching the imported tables.
Fix URLs if the domain or protocol changed. WordPress stores addresses in several places, including serialized data, so use a tool that understands serialization, such as WP-CLI's search-replace command, and not a plain text replace. The command is documented at developer.wordpress.org/cli/commands/search-replace.
Flush caches and permalinks. Save the permalink settings once to rewrite the rules, and clear any object or page cache.
Test on the temporary address. More on this below.
Switch DNS and watch.
Why serialized data matters
WordPress and many plugins store settings as serialized strings, which record the length of each value. If you replace a URL inside one of those strings with a different-length URL using a plain text tool, the recorded length no longer matches. The setting is then silently ignored or reset. That is why widgets vanish and page-builder layouts break after a careless search-and-replace. Use a tool built for it.

Testing before the switch
Testing is the step people skip when they are tired, and it is the step that saves the most grief. Spend real time here.

The page tour
Open the home page, the main landing pages, a few posts from different years, a category archive and the search results. Look for missing images, broken layout and wrong fonts. Old posts are worth checking because their images often use older file paths.

The functions that earn money or trust
Submit every form. Log in as a normal user and as an administrator. On a shop, add something to the cart and go as far through checkout as the payment gateway's test mode allows. If you sell memberships, test sign-up and access to protected content. Check that confirmation emails arrive, and look at how they render.

Behind the scenes
Check the admin area loads. Check scheduled tasks are running on the new server. Look at the site's error log for warnings that did not appear before. Confirm that search engines are not blocked: staging copies often have "discourage search engines" ticked, and carrying that over to the live site quietly removes you from search results.

A short written test list is worth keeping. It costs ten minutes to make and makes every future move quicker.

Cutting over with little downtime
The switch is a DNS change, and DNS changes are not instant. Resolvers around the world remember the old address for as long as the record's time-to-live allows.

Lower the TTL in advance
A day or two before the move, reduce the TTL on the relevant DNS records to a few minutes. Then, when you switch, most visitors will see the new server soon after. Raise it again when things settle. This one change turns a vague "give it up to a couple of days" into something much shorter.

Handle writes during the gap
For a few minutes or hours, some visitors will reach the old server and some the new. For a brochure site, that does not matter. For a shop or a site with comments, it does, because orders or comments could land on the old server after the copy was taken. Options include putting the old site into read-only or maintenance mode just before the cutover, or noting the exact time of the copy and re-importing the newer orders afterwards. Pick one before you start, not during.

Keep the old site alive for a while
Do not cancel the old hosting the moment the new site loads. Leave it running, in maintenance mode, for at least a week or two. If you discover a missing file or a broken integration, the original is still there to consult. Cancelling early is how people end up with a perfectly good new site that is missing last year's downloads folder.

Restoring after a failure rather than a planned move
An emergency restore follows the same steps with extra pressure. A few differences are worth knowing in advance.

Decide what to restore
If the problem is a bad plugin update, you may only need to roll back one folder, not the whole site. If a file was deleted, you may only need that file. If the database was damaged, you need that, but restoring an old database also loses everything written since the backup. Restoring everything is simple but heavy-handed, and a partial restore is faster and loses less. This is a major reason to prefer backups that let you restore selectively.

Backup services differ here. backupyoursite's site says its restores run from a web console and can bring back a single file or page, not only the whole site, which is the kind of selective option worth looking for when you compare tools. Whatever you use, ask how a partial restore works before you need one, and whether it overwrites newer content that was written after the backup was taken.

It also helps to decide in advance who is allowed to press the button. A restore overwrites live data. On a client site, agree who approves it, and take a fresh copy of the broken state first, so that if the restore turns out to be the wrong move you can still go back and pull out the one thing you needed.

If the site was hacked
Restoring a clean copy does not close the hole the attacker used. If you put back the same plugin version with the same flaw, the same thing can happen again. Update everything, change all passwords and keys, check for unknown administrator accounts, and look at when the compromise began so you pick a backup from before that date.

Know where to start
The slowest part of many emergencies is simply working out where the backups are and how to begin. If your copies are held by a hosted service, the restore usually starts from that service's control panel, not from the broken site. For people using backupyoursite, for example, the place to begin or to check on a restore is the backupyoursite dashboard. Wherever your backups live, write down the address, the login owner and the steps now, and keep that note somewhere that does not depend on the failed site.

Time how long it takes
If you have never restored, you do not know how long it takes, and neither does your client. Find out on a quiet day. The answer might be twenty minutes or it might be an afternoon, and that is the number you need when someone asks how long the site will be down.

Common failure patterns and what they usually mean
These patterns come up again and again. A quick match against your symptom can save an hour.

The white screen after the move
Usually a PHP error. Turn on debug logging in wp-config.php, read the log, and look for a missing extension, an incompatible plugin or a wrong file path. Developer documentation for debugging is at developer.wordpress.org.

"Error establishing a database connection"
The details in wp-config.php are wrong, the database user lacks permission, the database host is not what you assumed, or the database server is down. Check them in that order.

Links go to the old domain
The search-and-replace was skipped or was not run on all tables. Run it again with a serialization-aware tool, then clear caches.

Images missing
Either the uploads folder did not copy fully, file permissions are wrong, or paths in the database still point to the old location. Check each in turn.

Pages 404 except the home page
The permalink rules were not rewritten, or the server rules file did not come across. Re-save the permalinks and check .htaccess or the nginx configuration.

Logged out repeatedly
Often a mismatch between the site address and the address in the cookie settings, or a caching layer interfering. Check the two URL settings and any security keys that changed.

Frequently Asked Questions
How long does moving a WordPress site take?
For a small site, the copying can take under an hour. The surrounding work, such as testing and DNS, takes longer. For a large site, the transfer alone can take hours. Rehearse once to get your own number.

Do I need a plugin to move a site?
No. A manual move with SFTP, a database export and a search-replace is entirely workable. A plugin just packages those steps and is handy when you do not want to use the command line.

Why does my import stop at a certain size?
The limit is usually set by your host's PHP and web-server settings, and sometimes by the plugin edition. Raise the limits, upload by SFTP, or switch to a manual method.

Will my search rankings drop after a move?
Not if the addresses stay the same and nothing is blocked. Problems appear when URLs change without redirects or when the staging setting that discourages search engines is carried over.

Should I move and upgrade PHP at the same time?
It is safer not to. Move on a matching setup, confirm everything works, then upgrade PHP and test again.

How long should I keep the old hosting?
At least a week or two after the switch, longer for a shop or a site with many downloads.

Conclusion
Moving and restoring share one skeleton: gather everything, build a matching destination, import, fix addresses, test, then switch. The places where it goes wrong are predictable. Size and time limits, incomplete exports, serialized data, and skipped testing account for most of the grief.

The cure is practice. Do a rehearsal on a copy, write the steps down, and keep the note somewhere that survives the site going down. Then a planned move is dull and an emergency restore is merely irritating, which is exactly how you want both of them to feel.

Written as an independent guide to moving and restoring WordPress sites. Product names belong to their respective owners; check vendor documentation for current features and terms.