How to Migrate WordPress to a New Host

Why Move to a New Host

People move WordPress to a new host for a handful of practical reasons, and knowing yours helps you pick the right destination. The most common trigger is speed. Cheap shared plans pack hundreds of sites onto one server, so your pages crawl during busy hours no matter how well the site is built. A move to a faster plan or a managed WordPress host often fixes load times overnight.

Reliability is the next reason. If your current provider has frequent outages, slow support, or a control panel that fights you at every turn, the daily friction adds up. A host that answers tickets quickly and keeps servers online is worth the effort of moving.

Other common motives include outgrowing a plan as traffic grows, consolidating several sites under one account, moving closer to your audience for lower latency, escaping a price increase at renewal, or leaving a host after a security incident. Whatever the cause, the migration itself follows the same path, so the work you learn here applies to every scenario.

Signs it is time to move

A few clear signals tell you the host, not the site, is holding you back. If your pages are slow even after you have compressed images and trimmed plugins, the server is the limit. If your host cannot run a current PHP version, you are stuck on old software that plugins are dropping support for. If you regularly see resource limit warnings, the account is capped and every traffic spike risks an outage. If support takes days to answer a simple ticket, the relationship is not serving you. And if a security incident happened because the host would not help you clean it up, that alone is reason enough to leave. When two or more of these describe your situation, planning a move is the sensible next step rather than fighting the same problems every month.

Before you commit to a move, be honest about whether hosting is really the problem. A bloated theme, unoptimized images, or too many plugins can make any host feel slow. If speed is your only complaint, read our guide on how to speed up a WordPress website first, because sometimes a tune up beats a move. When the host truly is the bottleneck, the rest of this guide gets you to a better one safely.

Before You Start: A Checklist

A calm migration is a prepared migration. Rushing is what causes lost data and long outages, so spend twenty minutes gathering everything you need before you touch a single file. Here is the short list that keeps a move on track.

• Access to the old host: SFTP or file manager login, and database access through phpMyAdmin or the control panel.
• Access to the new host: account created, a place to upload files, and the ability to create a fresh database and database user.
• Domain registrar login: where you manage DNS, because the final step points your domain at the new server.
• A recent full backup: both files and the database, stored somewhere off the server.
• Your current PHP and WordPress versions: so the new host matches or exceeds them.
• A quiet window: pick a low traffic time to reduce the chance that orders or comments arrive mid move.

Write down the database name, database user, and table prefix from your current site now. You will find these in the wp-config.php file, and having them handy saves hunting later. If your site sells or collects data, put the store into maintenance mode or plan for a short freeze so nothing new is written during the copy. A migration is really just a careful copy, and copies go wrong when the source keeps changing underneath you.

Back Up Files and Database

Never start a migration without a complete backup you can restore. A WordPress site has two halves, and you need both. The files include WordPress itself, your theme, plugins, and the uploads folder full of images and media. The database holds your posts, pages, products, settings, users, and comments. Lose either half and your site is broken, so treat this step as non negotiable.

Backing up your files

Connect to your current host over SFTP with a client such as FileZilla, or use the file manager in your control panel. Download the entire WordPress directory, which usually sits in a folder named public_html or www. The important pieces are the wp-content folder, which holds your themes, plugins, and uploads, along with wp-config.php at the root. On a large media library this download can take a while, so start it early.

Backing up your database

Open phpMyAdmin from your control panel, select your WordPress database on the left, then choose the Export tab. The quick export in SQL format works for most sites. Save the resulting .sql file with the rest of your backup. This single file contains everything WordPress stores in the database, and it is what you will import into the new server.

If clicking through SFTP and phpMyAdmin feels fiddly, a backup plugin can package both halves into one archive for you. Our full walkthrough on how to back up a WordPress website covers plugin and manual methods in detail. Either way, verify that your backup actually contains the uploads folder and a database file before you go any further. A backup you have not checked is a hope, not a safety net.

Choosing a New Host

Where you land matters as much as how you get there. Pick the wrong host and you will be doing this again next year. When you compare providers, weigh a few things that make a real difference to a WordPress site.

• Performance: look for modern PHP, adequate memory, SSD or NVMe storage, and server side caching. Managed WordPress hosts tune all of this for you.
• Server location: a server near your visitors lowers latency. For a Canadian audience, a Canadian or northern United States data centre helps.
• Support quality: read recent reviews about response times. When something breaks, fast support is worth a lot.
• Staging and backups: built in staging and automatic daily backups save you future headaches. See our note on staging sites for why this matters.
• Room to grow: make sure the plan above yours is a simple upgrade, not another migration.

Shared, managed, or VPS hosting

Hosting comes in a few shapes, and the right one depends on your traffic and how hands on you want to be. Shared hosting is the entry level option where many sites share one server. It is inexpensive and fine for a small brochure site or a new blog, but performance suffers under load because you compete with your neighbours for resources. Managed WordPress hosting costs more, and in return the host tunes the server for WordPress, handles caching and updates, and usually includes staging and daily backups. For most growing businesses this is the sweet spot, because you get speed and support without becoming a server administrator.

A virtual private server, or VPS, gives you a dedicated slice of a server with root access and full control. It suits high traffic sites and teams that have technical help, but it also means you are responsible for security patches and server configuration unless you pay for a managed VPS. If you are not sure which tier fits, think about your traffic today and where you expect it to be in a year. Buying too much capacity wastes money, and buying too little means another move sooner than you want. When in doubt, a managed WordPress plan with clear upgrade steps is the safest starting point.

Match the new environment to your current one or better. Note your existing PHP version and WordPress version, then confirm the new host meets or exceeds both. Moving from PHP 8.1 to an older PHP 7.4 environment, for example, can break plugins, so aim to move up, not down. If you are unsure what your site needs, a managed WordPress plan removes most of the guesswork because the host configures the server specifically for WordPress.

Plugin vs Manual Migration

There are two honest ways to move a WordPress site. A migration plugin packages your whole site and rebuilds it on the new host, and the manual method copies files and the database by hand. Both work. The right one depends on your site size, your comfort level, and how much control you want.

For most small and medium sites, a plugin is faster and far less error prone. For very large sites, restrictive hosting, or situations where a plugin package is too big to import, the manual route is more dependable. Here is a side by side comparison to help you decide.

If you are new to this, start with a plugin and keep the manual method as your fallback. If a plugin package refuses to import because the site is too large, switch to manual for the files and database and you will get there. We cover the general moving process from another angle in our guide to migrating a WordPress website, which pairs well with this host focused walkthrough.

Migrate With a Plugin

Migration plugins do the heavy lifting. Two well known options are Duplicator and All-in-One WP Migration. Both create a copy of your site that you rebuild on the new host, and both spare you from touching the database directly. The general flow is the same, so pick the one you prefer.

Using Duplicator

Duplicator bundles your site into a package plus a small installer file. On your current site, install and activate Duplicator, then create a new package. The plugin scans your site, builds an archive of your files and database, and gives you two downloads: the archive and an installer.php file. Download both.

On the new host, create an empty database and a database user, and note the name, user, and password. Upload the archive and the installer to the new server, usually into the public_html directory. Then visit yourdomain.com/installer.php in your browser, either through a temporary URL your host provides or after pointing your domain. The installer unpacks the archive, imports the database, and updates the configuration for you. Follow the prompts, enter your new database details, and let it run.

Using All-in-One WP Migration

All-in-One WP Migration takes an even simpler path. On the old site, install the plugin and choose Export, then export to a file. This downloads a single archive of your entire site. On the new host, do a clean WordPress install, add the same plugin, choose Import, and upload your archive. The plugin rebuilds the site, database and all, and handles the URL updates. It is close to a one click move for typical sites.

Watch for size limits

The main snag with plugin migrations is file size. Hosts cap the maximum upload size, and a media heavy site can produce an archive larger than that cap. If your import fails or stalls, you have three choices: raise the upload limit on the new host if it allows, use the plugin extension that handles larger files, or fall back to the manual method for a site that is simply too big for a single package. Do not force a broken import. A partial database is worse than starting the step again.

The Manual Method Step by Step

When you want full control, or a plugin cannot handle your site, the manual method never lets you down. It has more steps, but each one is simple, and you always know exactly what has moved. Work through these in order and do not skip ahead.

Step 1: Upload your files to the new host

Connect to the new server over SFTP and upload the entire WordPress directory you downloaded earlier. Place the files in the correct web root, usually public_html. Keep the folder structure identical, so wp-content, wp-admin, and wp-includes all land where they belong. On a large site this upload is the slow part, so let it finish completely before moving on. A half uploaded site will throw confusing errors.

Step 2: Create the database on the new host

In the new host control panel, create a fresh MySQL database, then create a database user and give that user full permissions on the new database. Write down three things: the database name, the user name, and the password. You will need all three in a moment. Many control panels prefix the names with your account, so record the exact full values, not just the part you typed.

Step 3: Import your database

Open phpMyAdmin on the new host, select the empty database you just created, and choose the Import tab. Upload the .sql file from your backup and run the import. For a large database file that exceeds the upload limit, you can compress the file, raise the limit, or import through a command line tool if your host offers one. When the import finishes, you should see all your WordPress tables listed on the left.

Step 4: Point the configuration at the new database

This is where the manual method needs care, and it is the step covered in full in the next section. In short, you edit wp-config.php so WordPress connects to the new database using the new name, user, and password. Then, if your site is moving to a different domain or a temporary URL, you update the site address stored in the database. Get these two things right and your site will load on the new host.

The manual method rewards patience. If a step does not work, resist the urge to change five things at once. Check one value, reload, and check the next. Nearly every manual migration failure comes down to a wrong database credential or a URL that was never updated, both of which are quick to fix once you know where to look.

Update wp-config and the Database

The wp-config.php file is the bridge between WordPress and its database. When you move hosts, the database details almost always change, so this file needs an update or your new site shows an error connecting to the database. Open wp-config.php on the new server and find these four lines near the top.

• DB_NAME, the name of the database
• DB_USER, the database user name
• DB_PASSWORD, that user password
• DB_HOST, usually localhost, but some hosts use a specific server name

Replace each value with the new host details you wrote down when you created the database. Save the file. The DB_HOST value is the one people miss, because most hosts use localhost but a few require something different. If you get a database connection error after everything else looks right, check the host documentation for the correct DB_HOST value.

Updating your site URLs

If your domain is staying the same, you may not need to change any URLs. If you are testing on a temporary URL, or moving to a new domain, WordPress still has the old address stored in the database, and that mismatch causes broken links and login loops. You have a few safe ways to update it.

• The two options rows: in phpMyAdmin, open the wp_options table and update siteurl and home to the new address. This gets you into the dashboard.
• A search and replace tool: for a full URL change across posts and settings, a proper search and replace handles serialized data safely. Migration plugins do this automatically, and standalone scripts exist for manual moves.
• wp-config constants: you can temporarily define the site URL in wp-config.php to reach the dashboard, then set it properly and remove the lines.

Do not run a plain find and replace with a text editor across a database dump. WordPress stores some settings in a serialized format that records the length of each value, and a blind replace breaks that format, which corrupts settings and widgets. Always use a tool that understands serialized data. This single rule prevents one of the most frustrating post migration messes.

DNS Cutover: Point Your Domain

Once the site loads correctly on the new host, the last step is telling the world where to find it. Your domain uses DNS records to route visitors to a server, and right now those records still point at the old host. The cutover changes them to the new host, and it is the moment your live traffic actually moves.

Lower the TTL first

DNS changes are not instant. Each record has a value called the time to live, or TTL, which tells other servers how long to cache it. A day or two before your planned cutover, log into your DNS manager and lower the TTL on your main records to a short value such as a few minutes. This means that when you make the switch, the change spreads quickly instead of lingering for hours. Set the TTL back to a normal value once the move settles.

Find the new host IP and update the records

Your new host gives you an IP address for your account. In your DNS manager, update the A record for your root domain to that new IP, and update the record for the www subdomain the same way, whether it is an A record or a CNAME. If you use email on the domain, leave the MX records alone so mail keeps flowing. Save the changes.

Propagation

After you save, the change propagates across the internet. With a lowered TTL this is quick for most visitors, though it can take longer in some regions. During this window, some visitors see the old server and some see the new one, which is exactly why you keep both sites running until propagation completes. Do not cancel the old hosting the moment you change DNS. Give it at least a couple of days so no one lands on a dead server.

Test Before You Go Live

The safest migrations are tested before any live traffic touches the new server. Most hosts give you a temporary URL or a way to preview your site on the new server before you change DNS. Use it. Testing early means you find problems while the old site is still serving visitors, so a broken link on the new server hurts no one.

Work through a short checklist on the new server before the cutover.

• Home page and key pages load without errors or missing styling.
• Images and media appear, confirming the uploads folder moved and URLs are correct.
• You can log into the dashboard and the admin area works.
• Menus and internal links work and do not bounce back to the old domain.
• Forms submit and contact or checkout flows complete.
• For a store, run a test order and confirm payment and email steps.
• Permalinks work, and if internal pages give a not found error, resave the permalink settings.

Testing on a temporary URL

Loading a WordPress site on a temporary URL has one wrinkle worth knowing. Because WordPress stores its real address in the database, some links and assets may point back at the live domain even while you preview on the temporary address. That is normal and does not mean the migration failed. A common trick is to add a line to your computer hosts file that maps your real domain to the new server IP, which lets you browse the new site at its real address on your machine only, while the rest of the world still sees the old server. This gives you the most accurate preview without touching public DNS, and you simply remove the line when you are done.

If everything on this list passes on the temporary URL, you can cut over with confidence. If something fails, fix it now while the pressure is off. It is far easier to troubleshoot a site no one is using than to firefight after you have already moved live traffic.

How to Avoid Downtime

Zero downtime is achievable if you sequence the move correctly. The trick is to never take the old site offline until the new one is fully live and tested. Downtime happens when people do the steps in the wrong order, usually by changing DNS before the new site is ready, or by cancelling the old host too soon.

Here is the order that keeps a site available the entire time.

• Build the new site quietly on the new host using a temporary URL, while the old site keeps serving every visitor.
• Test the new site fully before touching DNS, so you know it works.
• Freeze changes on the old site during the final sync, or copy any new content added since your backup, so nothing is lost.
• Lower your TTL ahead of time so the DNS switch spreads fast.
• Change DNS only when the new site is confirmed good.
• Keep the old host running for several days while DNS propagates, then cancel it.

The most common cause of lost data is content that arrives between your backup and your cutover. If a customer places an order, or someone leaves a comment on the old site after you took your database export, that record lives only on the old server. For busy sites, either freeze new activity during the move or do a final database sync right before the switch so nothing slips through the gap.

Common Errors and Fixes

Even careful migrations hit a snag or two. The good news is that the errors are predictable, and each has a known fix. Here are the ones you are most likely to meet and how to clear them.

Error establishing a database connection

This almost always means the details in wp-config.php do not match the new database. Recheck DB_NAME, DB_USER, and DB_PASSWORD against the exact values you created on the new host, including any account prefix. If those are right, try a different DB_HOST value from your host documentation, since a few providers do not use localhost. Also confirm the database user actually has permission on the database.

White screen with no content

A blank white page usually points to a PHP error or a memory limit. Turn on WordPress debugging temporarily to see the message, raise the PHP memory limit on the new host, and confirm the new server runs a PHP version your plugins support. Our guide to the white screen of death covers this failure in depth.

Missing images or broken styling

When images vanish or the layout looks bare, either the uploads folder did not fully transfer, or the site URLs still point at the old address. Confirm wp-content/uploads is present and complete on the new server, then run a proper search and replace to update any old URLs to the new domain.

Pages return a not found error

If the home page loads but internal pages give a not found message, your permalink rules did not carry over. Log in, open Settings, then Permalinks, and simply click save. That rewrites the rules for the new server without changing anything, and it fixes most not found errors after a move.

Login redirect loop

Being bounced back to the login screen over and over usually traces to a URL mismatch between the stored site address and the address you are visiting. Set siteurl and home correctly in the wp_options table, clear your browser cookies, and try again.

The site still shows the old server

If you changed DNS but keep seeing the old site, it is propagation, not a bug. Your local network may still cache the old record. Wait for the TTL to expire, flush your local DNS cache, or check from a different network or your phone on mobile data. Give it time before you assume something is wrong.

After the Migration

Once the new site is live and DNS has settled, a few finishing tasks lock in the move and keep the site healthy. Skipping these is how a smooth migration turns into a slow leak of problems weeks later.

• Confirm SSL is active. Make sure your certificate is installed on the new host so the site loads over HTTPS. If pages warn about mixed content, update any lingering insecure URLs.
• Reset the TTL. Put your DNS TTL back to a normal value now that the cutover is done.
• Set up fresh backups. Your old backup schedule lived on the old host. Configure automatic backups on the new one right away.
• Review security. A new home is a good moment to tighten things. Our guide on securing a WordPress website is a useful next read.
• Check performance. Test load times on the new host and enable its caching. If speed was your reason for moving, confirm you actually got faster.
• Cancel the old host. After a few days of stable traffic on the new server, and one final confirmation that nothing new is being written to the old site, you can safely cancel the old plan.

Protect your search rankings

If you kept the same domain, your rankings usually carry over without drama, because as far as search engines are concerned the site simply responds from a different server. Still, there are a few things worth checking so you do not lose visibility. Make sure your permalinks match exactly what they were before, so no page changes its address. If any URL did change during the move, set up a redirect from the old address to the new one so visitors and search engines land in the right place. Confirm your site is reachable over HTTPS and that the non secure version redirects to the secure one, since a broken certificate can scare off visitors and hurt trust.

It also helps to submit your sitemap again in your search console account and to watch your coverage reports for a week or two after the move. A brief dip in crawl activity while search engines revisit the new server is normal and settles quickly. If you moved to a much faster host, you may even see improvement, because speed is a factor in how pages are judged. Keep an eye on your analytics so you can spot any page that suddenly stops getting traffic, which is the fastest way to catch a stray broken link or a missing redirect before it costs you.

Keep a light eye on the site for a week. Watch that forms still deliver email, that any scheduled posts publish, and that no error notices pile up. If your site is a store or a lead source, that first week of quiet monitoring is cheap insurance. Building a brand new site instead of moving one? Our walkthrough on how to make a WordPress website starts from scratch.

Migrations reward preparation and order. Back up both halves, move files and database, fix the configuration, test on a temporary URL, then cut over DNS while both hosts run. Do it in that sequence and downtime stays near zero. If you would rather not spend a weekend on SFTP and phpMyAdmin, our team moves WordPress sites cleanly and quickly. Have a look at our maintenance services or get a free quote and we will take the whole migration off your plate.