Why Move Hosts at All
Before we get into how to migrate WordPress to a new host, it is worth being honest about why you would put yourself through it, because the reason shapes how careful you need to be. Most people move hosts for one of a handful of reasons, and knowing yours helps you judge what matters in the new home.
The most common reason is speed. A slow host makes every page crawl no matter how well built your site is, and no amount of optimisation fully rescues a site sitting on an overloaded shared server. If your pages feel sluggish and your host is the bottleneck, moving to a faster one is one of the biggest single improvements you can make. Our guide on speeding up WordPress covers how to tell whether the host is really the problem.
The second common reason is reliability. If your site keeps going down, if support takes days to answer, or if you have outgrown a cheap plan that now buckles under your traffic, a better host earns its keep. A site that is offline is a site that cannot sell or inform anyone, and unreliability quietly costs far more than the price difference between hosts.
Other reasons include price, when a host hikes renewal costs; features, when you need something your current host does not offer; support quality, when you are tired of unhelpful answers; and consolidation, when you want several sites under one better provider. Whatever your reason, the migration process is the same, and the goal is always to move without your visitors noticing anything except, ideally, a faster site afterward. If you are still choosing where to go, our roundup of the best WordPress hosting lays out the options.
It is worth pausing to make sure the host really is the problem before you move, because migrating a slow site to a new server does not fix a site that is slow for other reasons. A page bloated with heavy images, a pile of unused plugins, or a lack of caching will still feel sluggish on a faster host. Run a speed test, and if the numbers point at your host being overloaded rather than your site being heavy, a move is justified. If they point at the site itself, you may fix the problem without migrating at all, or at least go into the move knowing there is other work to do once you land. Either way, moving with clear eyes beats moving on a hunch and being disappointed twice.
What a Migration Actually Moves
A WordPress site is made of two parts, and understanding them makes the whole process far less mysterious. Everything else is detail around these two.
The first part is the files. These are the actual code and content stored on the server: WordPress itself, your theme, your plugins, and your uploads folder full of images and documents. They sit in a folder on the host and can be copied like any other files. When people talk about moving a site by FTP, they mean copying this folder from the old server to the new one.
The second part is the database. This is where WordPress keeps your posts, pages, settings, users, comments, and, for a store, your products and orders. It is not a file you can drag around; it lives in a database system on the server, and it is copied by exporting it to a file on the old host and importing that file into a fresh database on the new host. The database is the heart of the site, which is why every backup and every migration must include it.
A migration is simply moving both of these to the new host, then telling WordPress on the new server how to find its database, and finally pointing your domain at the new server. A plugin does all of this for you behind a friendly button; the manual method does each step by hand. Either way, the underlying job is the same: files across, database across, config updated, domain switched. Keep that mental model and nothing that follows will feel like magic.
Before You Start
A little preparation makes a migration calm rather than stressful. Before you touch anything, get these sorted.
- Access to both hosts. You need your login to the old host and an account on the new one, including the control panel, FTP details, and database tools if you are going manual. Gather these first so you are not hunting for a password halfway through.
- Your domain login. The domain is switched wherever your DNS is managed, which may be the domain registrar or a separate DNS provider. Make sure you can log in there, because you cannot complete a migration without it.
- Know where your email lives. If your email runs on the same host as your site, plan to move it too or you risk cutting it off. This is the single most overlooked part of a migration.
- A recent, complete backup. Never migrate without one. Our guide on backing up a WordPress website covers doing it properly, and a backup is your undo button if anything goes wrong.
- A quiet time to do it. Pick a low traffic period so if anything wobbles during the switch, the fewest people are affected.
With those in hand, the move itself is a matter of following steps in order. The two parts that need real care are keeping the old site alive until the new one is confirmed, and handling your email, so keep both in mind throughout.
Choosing the New Host
If you have not settled on a new host yet, choose carefully, because migrating again in six months because the new host also disappointed you is a waste of everyone's time. The right host depends on your site, but a few things matter for almost everyone.
Speed and the underlying hardware matter most for a busy site. Look for a host built for WordPress specifically, with modern servers and good caching, rather than the cheapest generic shared plan. A host that specialises in WordPress usually tunes its servers for it and gives you fewer performance headaches. Support quality matters just as much: when something breaks, a host that answers quickly and knows WordPress is worth a great deal more than one that is cheap but silent.
Consider whether the host offers the things that make your life easier, such as free SSL certificates, staging sites, automatic backups, and a free migration service. Many good hosts include a migration as part of signing up, which can do most of this guide's work for you. Match the plan to your actual traffic and needs rather than the biggest package, since you can usually upgrade later. Our roundup of the best WordPress hosting and the wider hosting guide compare the options so you can pick with your eyes open.
Give a thought to where your host is located and where your visitors are, since a server physically closer to your audience answers faster. If most of your customers are in one country, a host with servers in or near that region is a small advantage that adds up over every page load. Beyond location, look at whether the host runs recent versions of the software your site depends on, particularly PHP, because an old server version is a common cause of trouble after a move. A host that keeps its stack current spares you a whole category of migration headaches. Read a few honest reviews focused on support response times rather than glossy feature lists, because the day something breaks is the day you learn what a host is really worth, and that day always comes eventually.
Back Up Everything First
This is the step you never skip, no matter how confident you feel or how simple the site looks. A complete backup, taken before you touch anything, is what turns a migration from a nerve wracking leap into a reversible, low risk task. If anything goes wrong at any stage, a backup means you can restore and try again rather than facing a lost site.
A complete backup means both parts of the site: all the files, including your uploads, theme, and plugins, and a full export of the database. A backup of only the files, or only the database, is not enough to rebuild the site, so make sure you have both. Most backup plugins capture everything in one archive, which is the easiest way to be sure, and many good hosts also take automatic backups you can rely on.
Keep the backup somewhere off the old host, such as your own computer or a cloud storage account, not just on the server you are about to leave. A backup that lives only on the host you are migrating away from is no help if that host has a problem. Our dedicated guide on backing up a WordPress website walks through doing this properly, and it is worth reading before a migration if you do not already have a solid backup routine. Think of the backup as the safety net under the whole operation. With it in place, everything that follows is recoverable.
It is also worth actually confirming the backup is good rather than trusting that it ran. A backup file that turns out to be incomplete or corrupted is worse than no backup, because it gives you false confidence. If your backup tool lets you check the archive, or restore it to a test location, take a minute to do so before you rely on it. At the very least, look at the file size and make sure it is plausible for a site of your size rather than suspiciously small. A store carrying years of orders should produce a sizeable backup, and a tiny file is a warning sign that the database did not make it in. Five minutes of checking here can save you from discovering, at the worst possible moment, that your safety net had a hole in it.
The Plugin Method
For most sites, a migration plugin is the easiest and safest route, because it handles the fiddly parts, moving files, moving the database, and rebuilding the site, behind a guided process. Here is how the plugin approach works in broad strokes, without tying you to one specific tool.
You install a reputable migration plugin on your old site and use it to package the whole site, files and database together, into a single downloadable archive or a transfer that goes straight to the new host. Some plugins produce a file you download and then upload to the new server; others connect the two hosts and move the site directly. Either way, the plugin does the copying that you would otherwise do by hand.
On the new host, you set up a fresh, empty WordPress install, then use the plugin's importer to unpack your site onto it. The plugin restores your files, imports your database, and updates the internal settings so the site works on the new server. When it finishes, you have a working copy of your site on the new host, ready to test before you switch the domain.
The advantages are clear: far less manual work, fewer chances to make a mistake, and a process designed for people who are not server experts. The main things to watch are size limits, since very large sites can exceed what a plugin or host will handle in one go, and choosing a well known, actively maintained plugin rather than an obscure one, because this tool handles your entire site. For a typical small business site or a modest store, the plugin method is the route we would point most owners to first.
One habit worth building is to migrate a clean site rather than dragging your clutter to the new home. Before you package everything up, it is a good moment to delete plugins you no longer use, remove old themes you are not running, and clear out spam comments and post revisions that have piled up over the years. A tidier site packages faster, imports more reliably, and starts life on the new host without carrying forward problems you had forgotten about. Think of the move as a spring clean as much as a relocation. That said, do the cleaning on a copy or after your backup is safe, never in a rush right before the move, so a stray deletion cannot cost you anything you needed.
The Manual Method
The manual method moves each part of the site by hand. It is more work and more error prone for a beginner, but it gives you full control and suits very large sites, unusual setups, or situations where a plugin struggles. Here is the shape of it so you understand what the plugins are doing for you.
First, copy the files. Using an FTP program, you connect to the old host, download the entire WordPress folder to your computer, then connect to the new host and upload it all there. This moves WordPress, your theme, plugins, and uploads. It is simple but can be slow if you have thousands of images, which is one reason large sites sometimes prefer the manual route with better tools.
Second, move the database. In the old host's database tool, you export the database to a file. On the new host, you create a fresh, empty database and a database user, then import your exported file into it. Note the new database name, user, and password, because you will need them in a moment.
Third, update the configuration. The WordPress config file, called wp-config, holds the database name, user, password, and host. Because the new server's database details are different, you edit this file to match the new values. This single step is behind one of the most common migration errors, the database connection error, so get these four values exactly right.
Finally, handle the site address and links. If your domain stays the same, this is minimal, but you may need to update references inside the database that point at the old server, especially if the site was on a temporary address during testing. Tools exist to search and replace these safely. The manual method rewards care and punishes haste, so work through it slowly and keep your backup close. If any of this sounds daunting, that is exactly what the plugin method and professional help exist to spare you.
Free Host Migrations
Before you commit to doing the move yourself, check what your new host offers, because many hosts will migrate your site for you at no extra cost as part of signing up. This is one of the best kept secrets of changing hosts: rather than wrestling with plugins or FTP, you hand the new host your old login details or run their official migration tool, and their team or software moves the site onto their servers.
For a straightforward site, this is a genuinely good deal. The host knows their own servers better than anyone, handles the technical parts, and often does it faster and more cleanly than a first timer would. If a free migration is on the table and your site is not unusually complex, it is worth taking, and it saves you most of the work in this guide.
There are limits to be aware of, though. A free migration usually covers one straightforward site, and may not include a large store, several sites at once, careful pre launch testing, or a genuinely zero downtime switch. Read what the service actually promises rather than assuming it covers everything. And whatever the host says, still take your own complete backup first, because your safety net should never depend on someone else's process. If your site is important or complicated, the free migration may get you most of the way while you or a developer handle the careful testing and the clean domain switch.
Testing Before You Switch
This is the step that separates a smooth migration from a public disaster, and it is the one people rush. Once your site exists on the new host, you must confirm it works there before you point your domain at it, and the trick is to view the new copy privately while the rest of the world still sees your old site.
There are two common ways to do this. The first is to use a temporary address the new host provides, a preview URL that shows your site on the new server without touching your domain. The second, and more thorough, is to edit a small file on your own computer called the hosts file, which lets your machine alone treat your domain as if it already points at the new server, while everyone else still reaches the old one. Either way, you get to load your real site as it will behave on the new host, in private.
With that private view open, click through everything that matters. Load the home page and several inner pages, check that images appear, submit a contact form, log into the admin area, and if you run a store, walk through a test checkout end to end. Look for broken links, missing images, or pages that error. This is your chance to catch problems while your live site is still safely running on the old host, so take your time. Testing on a copy like this is the same discipline as using a staging site, and it is worth the extra care. Only when the private test passes cleanly should you move on to switching the domain.
Do not just test the obvious pages. The parts of a site that break in a move are often the ones you use least and notice last: a search feature, a members only area, a download that lives in a protected folder, or a form that sends to an email address. Make a short list of everything your site actually does, not just the pages it shows, and tick each one off on the new host. If your site sends email, such as order confirmations or form notifications, send a test and confirm it arrives, because email sending is configured on the server and does not always carry over cleanly. Catching a broken confirmation email now, in private, is far better than a customer telling you about it after they paid.
Pointing Your Domain Over
Once the new copy is tested and working, the final active step is to point your domain at the new host. Your domain currently sends visitors to the old server through a DNS record, and switching hosts means updating that record to the new server's address. You do this wherever your DNS is managed, which is usually your domain registrar or a separate DNS provider such as Cloudflare.
The change itself is small: you update the record, often an A record pointing at the new server's address, or you change the nameservers if the new host manages DNS for you. The new host tells you exactly what to set. The important thing is to make this change only after your private test has passed, because the moment you update it, real visitors start arriving at the new server.
What follows is the part that requires patience: propagation. The updated record does not reach the whole internet instantly, because networks around the world cache the old answer for a while. For a period that can range from minutes to a day, some visitors see the new site while others still land on the old one. This is normal and unavoidable, and it is exactly why you keep the old site running during this window, so whichever server a visitor reaches, they see a working site. A trick that speeds this up is to lower your DNS record's cache time, its TTL, a day before the switch, so the old answer expires quickly when you make the change.
Avoiding Downtime
Downtime during a migration is almost always self inflicted, and the good news is that it is easy to avoid once you understand where it comes from. The whole safe approach rests on one rule: keep the old site fully alive until the new one is confirmed and the switch is complete.
Downtime happens when people break that rule. They delete the old site the moment they think the new one is ready, then discover a problem with nothing to fall back on. Or they switch the domain before testing, so real visitors hit a broken copy. Or they cancel the old hosting account too soon, killing the old site while DNS is still propagating and some visitors still rely on it. Each of these is avoidable by simply waiting.
The safe sequence is: build the copy on the new host, test it privately, switch the domain, then leave the old host running for several days while propagation finishes and you confirm the new site is behaving under real traffic. Because both servers hold a working site during the switch window, every visitor reaches a live version no matter which server their network sends them to. Only once you are confident, usually after a few days of the new site running cleanly, do you retire the old host. Patience here costs you a few days of paying for two hosts, which is a small price for a migration nobody notices.
There is one subtle trap to be aware of during the switch window: because both sites are live, a store or a busy blog can receive new activity on whichever server a visitor happens to reach. If someone places an order or leaves a comment on the old site after you took your copy, that data lives only on the old host and will not be on the new one. For a quiet brochure site this rarely matters, but for a store it does, which is why a common tactic is to pause new orders briefly during the final switch, or to check the old host for any last activity and carry it across before you retire it. Knowing this ahead of time turns a nasty surprise into a simple, planned step.
After the Move
Once the domain has switched and propagation has settled, a few checks make sure everything really landed well rather than merely looking fine at a glance. Spend a little time here and you avoid discovering a problem weeks later.
Confirm the whole site works on the new host under the real domain: click through pages, test forms and checkout again now that it is truly live, and check that images and downloads load. Make sure your SSL certificate is active so the site loads securely over HTTPS, because a certificate that did not carry over leaves visitors with a security warning. Log into the admin area and confirm you can edit and publish normally.
Check the things that are easy to forget. Confirm your email still works if it was tied to the old host, since this is where email problems surface. Set up backups on the new host so you are protected going forward, and check that any caching or performance features the new host offers are turned on so you actually get the speed you moved for. It is also worth submitting your site to Google's tools again and keeping an eye on your traffic for a week or two to confirm nothing dropped. Only once all of this is confirmed, and after a few days of clean running, should you cancel the old hosting account. Our speed guide helps you make the most of the faster host you moved to.
Troubleshooting Common Errors
Even a careful migration can throw the odd problem, and most fall into a few recognisable groups that are quick to fix once you know where to look.
Error establishing a database connection
This is the classic migration error, and it nearly always means the database name, user, password, or host in the wp-config file does not match the new server. Check those four values against what the new host gave you. Our guide on fixing this exact error covers it in detail.
Broken images or missing files
If images fail to load, the uploads folder may not have copied completely, or links may still point at the old server address. Confirm the uploads folder moved in full, and run a safe search and replace to update any old addresses lingering in the database.
The white screen of death
A blank white page usually means a plugin or theme conflict or a PHP version mismatch on the new host. Check that the new server runs a PHP version your site supports, and if needed disable plugins to find the culprit. Our white screen fix guide walks through it.
Login loops or you cannot reach the admin
This often comes from leftover site address settings pointing at a temporary or old address. Correcting the site and home address values, sometimes directly in the database, usually clears it.
The old site still showing
If you still see the old site after switching, that is usually propagation not finishing yet, or your own browser or computer caching the old answer. Give it time, clear your cache, and check from a different network or device to confirm the new site is really live for others.
Email stopped working
If email tied to the old host went quiet after the switch, the mailboxes did not move with the site. This is why planning email ahead of the migration matters. Restore email service by moving the mailboxes or setting up a dedicated email provider, and update your DNS mail records accordingly.
If a problem survives these checks, the new host's support and your error logs are the next place to look, and there is no shame in bringing in help when a live site is affected. A broken migration costs you visitors and sales every hour it is wrong.
Migration Checklist
Here is the whole process as a checklist you can work through in order.
| Step | What to confirm |
|---|---|
| Backup | Complete files and database backup stored off the old host |
| New host ready | Account, control panel, and empty WordPress ready to receive the site |
| Email planned | You know where email lives and how it will move |
| Files moved | All files, including uploads, copied to the new host |
| Database moved | Database imported and wp-config updated to the new details |
| Private test | Site tested on a preview address, forms and checkout work |
| TTL lowered | DNS cache time lowered a day before the switch |
| DNS switched | Domain pointed at the new host after the test passed |
| Old host kept | Old site left running for several days during propagation |
| Post move checks | SSL active, email working, backups set, then retire old host |
Work through this and your migration will be calm and reversible. The steps people skip most are the backup, the private test, and keeping the old host alive, and those are exactly the three that turn a smooth move into a stressful one, so give them the respect they deserve.
When to Get Help
Plenty of owners migrate a simple site themselves by following these steps, and for a small brochure site the plugin method or a free host migration will usually see you through. But a migration touches your files, your database, your domain, and your email all at once, and a mistake in any of them can take a site offline or lose data. If you run a store where orders keep arriving, a large or complex site, several sites at once, or a site your business depends on, having someone who does migrations regularly handle it is a sensible investment rather than a luxury.
We migrate WordPress sites and stores for a living. We can move your site to the new host, test every path including checkout, handle your email so nothing goes dark, switch the domain with zero downtime, and confirm the whole thing is working under real traffic before we retire the old host. Because we are developers, we can also untangle the awkward cases, a huge database, a custom setup, a store that cannot afford to miss an order, that trip up a plugin. Our migration services and our companion guide on moving WordPress to a new host cover more.
If you want your migration done properly and tested end to end, you can get a free quote and we will handle it and confirm it works before anything switches over. Or book a free consultation and we will talk through your move with no pressure. A site that changes homes without your visitors noticing is worth getting right the first time, and the first step costs nothing. You can also see the full range of what we do on our services page.