Moving a WordPress site to a new host is one of the most common migrations there is, and one of the most approachable — WordPress is designed to be portable, and the whole site comes down to a folder of files plus one database. The anxiety people feel is almost always about not knowing the sequence; once you see the site as ‘files plus database, copied and reconnected,’ the move becomes a clear, repeatable procedure you can follow with confidence.

This cornerstone guide walks through migrating a WordPress site end to end: the two things every WordPress site is made of, your options for moving (host-assisted, plugin, or manual), the full step-by-step of the move, how to test before going live, the DNS cutover, and the post-migration checks. By the end you will understand every stage and be able to move your WordPress site to a better host cleanly, with little or no downtime.

What a WordPress site is made of

The key to a confident WordPress migration is understanding that the entire site is only two components. First, the files: everything in your WordPress folder — the core WordPress software, your themes, your plugins, and your uploads (images and media) in the wp-content directory. Second, the database: a single MySQL database holding all your content (posts, pages, comments) and settings. That is the whole site.

Migrating a WordPress site, therefore, means copying both of these to the new host and reconnecting them: uploading the files, importing the database, and telling WordPress (via the wp-config.php file) how to find the database on the new server. Everything else in a migration is preparation, testing, and the DNS switch around this core copy-and-reconnect.

So hold this mental model throughout: files plus database, copied and reconnected. Whether you use an automated tool or do it by hand, that is fundamentally what is happening under the surface. Understanding it demystifies every step — when you update wp-config.php, you are reconnecting the files to the database; when you run a search-and-replace, you are fixing URLs stored in the database. The two-component model makes the whole process legible.

Your three options for moving

There are three broad ways to migrate a WordPress site, and choosing the right one for your situation shapes how much work you do:

• Host-assisted (free) migration: your new host’s team or automated tool moves the site for you — the easiest option, and often free, ideal for most people.
• Migration plugin: a plugin packages your whole site into a movable file and unpacks it on the new host — a good balance of control and automation.
• Manual migration: you move the files by FTP and the database by phpMyAdmin yourself — the most hands-on, giving full control and understanding.

For most people, the host-assisted route is the best first choice: it is usually free, and experienced people (or proven tools) handle the transfer, removing most of the effort and risk. A migration plugin is the natural next option if you want to do it yourself with automation, and the fully manual method is for those who want complete control or are moving a setup a tool cannot handle. The steps below describe the general flow common to all three, which the manual method makes most explicit.

Step 1: back up and prepare

Before moving anything, take a complete backup of your WordPress site — both the files and the database — and verify it is restorable. This is your safety net: if anything goes wrong during the migration, you can restore to exactly where you started. Never begin a WordPress migration without this, because a mistake without a backup can mean losing your site.

With the backup secured, prepare the new host: sign up, and have your new hosting account ready to receive the site. If you are using the host-assisted route, this is often where you simply request the migration and provide your old host’s details. If you are doing it yourself, make sure you have access to the new host’s file storage (FTP or file manager) and its database tools (usually phpMyAdmin) and can create a new, empty database there.

It is also a good moment to clean up before you move: delete unused themes and plugins, clear out spam comments, and remove old backups cluttering your files, so you are moving a lean site rather than years of accumulated junk. A tidy site copies faster and starts fresh on the new host. Preparation done, you are ready to copy the two components across.

Step 2: copy the files and database

Now you move the two components. For the files, download your entire WordPress folder from the old host (via FTP or the file manager) and upload it to the new host’s web directory. This includes WordPress core, your wp-content folder with themes, plugins, and all your uploads, and the wp-config.php file. On a large site this is the slowest part, since media can be gigabytes.

For the database, export it from the old host (using phpMyAdmin, you export the database to a .sql file — a complete dump of all your content and settings). Then, on the new host, create a fresh empty database and import that .sql file into it, recreating all your data on the new server. Now both components exist on the new host, but they are not yet connected.

If you are using a migration plugin or host-assisted service, this whole copy step is automated — the plugin packages files and database together and unpacks them, or the host’s team does the transfer. But conceptually the same thing is happening: your files and your database are being copied from old host to new. With both in place, the next step is to reconnect them so WordPress runs.

Step 3: reconnect and configure

With files and database on the new host, you connect them by editing the wp-config.php file — the file that tells WordPress how to reach its database. Update it with the new host’s database name, database username, and password (the credentials for the new database you created), so WordPress on the new host knows where its data lives. This single reconnection is what brings the copied site to life on the new server.

There is often one more crucial step: fixing URLs stored in the database. If your site’s URLs are changing at all (even temporarily, or if the old URLs are hard-coded), you run a search-and-replace on the database to update old references to new ones — otherwise the migrated site can point back at the old location for images, links, and settings. Tools and plugins exist to do this safely; it is a standard part of a WordPress move.

Also confirm file permissions are correct on the new host, so WordPress can read and write as needed. Once wp-config.php points at the new database, URLs are corrected, and permissions are right, your WordPress site is fully assembled and running on the new host — but crucially, your domain is not yet pointing there, so the public still sees the old site. That gap is exactly what lets you test safely before going live.

Step 4: test before going live

This is the step that separates a smooth migration from a public disaster: test the migrated site on the new host before you point your domain at it. Because your domain still resolves to the old host, you need a way to preview the new site specifically — commonly by editing your computer’s hosts file to point your domain to the new server’s IP for your machine only, or by using a temporary URL the new host provides.

With a preview method in place, click through the migrated site thoroughly: check that pages and posts load with correct content, images and styling appear, internal links work, forms submit, logins function, and any e-commerce or dynamic features behave. This is where you catch the classic problems — missing images from unfixed URLs, a database-connection error from wrong wp-config credentials, or broken styling — while they are still invisible to the public. Only once the migrated site is genuinely working on the new host do you proceed to the cutover. Never point your domain at an untested site.

Step 5: cut over the DNS

With the migrated site verified on the new host, you make it live by pointing your domain at the new server — the DNS cutover. You do this by updating your domain’s DNS: either changing its nameservers to the new host’s, or updating the A record to the new server’s IP address. This is the moment the public starts being routed to the new site instead of the old one.

Remember that DNS changes do not take effect instantly everywhere — they propagate over a window of hours (up to 48 in rare cases) as caches around the internet refresh. During this window, some visitors reach the new site and some still reach the old one, which is exactly why you keep the old host running throughout. If you lowered your DNS TTL a day or two before, this propagation happens much faster.

So cut over by updating DNS, keep the old host alive through propagation, and understand that the switch is gradual, not instant. Because you tested the new site first and both old and new are working during propagation, no visitor ever meets a broken site. The cutover is the least dramatic step precisely because all the risky work was done and verified beforehand — you are simply flipping the pointer to a site you already know works.

Step 6: verify and finish up

Once DNS has propagated and your domain resolves to the new host, run a final round of checks on the live site to confirm the migration succeeded. Load your key pages, verify images and styling, test a form and a login, send and receive a test email on your domain, and if you run a shop, place a test order. Confirm your analytics and search-console tracking are still recording. Essentially, re-verify on the live site what you checked in the preview.

Then handle the finishing tasks. Reconnect or confirm anything that lives outside the core files-and-database, such as scheduled tasks or third-party integrations, and make sure email is flowing (its MX records point to the right mail server). Clear any caches so visitors see the fresh site, and keep an eye out for error reports over the next few days.

Finally — and only once everything is confirmed stable and DNS has fully propagated, typically after a few days — cancel your old hosting. Retiring the old host too early is a classic mistake, because visitors still in the propagation window would hit a dead site. Wait until you are certain the new host is serving everyone correctly. When your WordPress site loads, works, tracks, and emails from its new home, the migration is genuinely complete — files and database, copied, reconnected, tested, and live.

FAQs

How do I migrate a WordPress site to a new host?

A WordPress site is just files (WordPress core, themes, plugins, uploads) plus one database. Back up first, set up the new host, copy the files (FTP) and database (export/import via phpMyAdmin), reconnect them by editing wp-config.php with the new database credentials, fix stored URLs with a search-and-replace if needed, test the site privately before going live, then cut over DNS and verify. Or let your host do it for free.

What is the easiest way to migrate WordPress?

The host-assisted route — many quality hosts migrate your WordPress site for free, with their team or automated tools copying files, database, and settings and reconnecting everything. It’s usually the easiest and lowest-risk option for most people. A migration plugin is the next easiest if you prefer to do it yourself with automation; fully manual gives the most control.

Will I lose data migrating WordPress?

Not if you back up first and follow the steps. Take a complete, verified backup of files and database before you start, so any mistake is reversible. The migration copies (not moves) your data, and you keep the old host running until the new one is verified, so your original site stays intact throughout. Data loss only happens when people skip the backup.

How do I migrate WordPress without downtime?

Copy the site to the new host and test it there privately — via a hosts-file preview or the host’s temporary URL — before touching your domain. Only once verified do you cut over DNS, keeping the old host running through propagation so visitors always hit a working site (new if they’ve switched, old if not). Lowering your DNS TTL beforehand speeds the switch.

What is wp-config.php and why does it matter in migration?

wp-config.php is the file that tells WordPress how to connect to its database. After copying your files and importing your database to the new host, you edit wp-config.php with the new host’s database name, username, and password so WordPress can find its data there. This reconnection is what brings the copied site to life on the new server — a wrong value causes a database-connection error.

Do I need to update URLs after migrating WordPress?

Often yes, via a database search-and-replace, especially if URLs change or old ones are hard-coded — otherwise the migrated site can point back at the old location for images, links, and settings. Tools and migration plugins do this safely. For a pure host move keeping the same domain, it may be minimal, but checking for and fixing stored old references is a standard migration step.

The bottom line

Migrating a WordPress site to a new host is far less daunting once you hold the right mental model: the entire site is just two things — a folder of files (WordPress core, themes, plugins, and uploads) and a single database — and migrating means copying both to the new host and reconnecting them. You have three ways to do it: the host-assisted route, where your new host moves the site for you (usually free and the easiest, best choice for most people); a migration plugin that packages and unpacks the whole site; or the fully manual method with FTP and phpMyAdmin, which makes every step explicit. Whichever you choose, the same flow underlies it all.

That flow is a clear sequence: back up and verify first so any mistake is reversible; set up the new host and clean up your site; copy the files and export-import the database; reconnect them by editing wp-config.php with the new database credentials and fixing stored URLs with a search-and-replace; test the migrated site privately, before your domain points to it, catching any problems while they are invisible to the public; cut over by updating DNS while keeping the old host alive through propagation; and finally verify the live site, confirm email and integrations, and only then — after a few days, once everything is stable — cancel the old host. Files and database, copied, reconnected, tested, and switched: follow that rhythm and you move your WordPress site to a better home cleanly, with little or no downtime and your content fully intact.

When you are ready, you can start with Hostinger and use code PROTIPS for the reader discount. A WordPress site is files (core, themes, plugins, uploads) plus one database. To migrate: back up, set up the new host, copy files (FTP) and database (phpMyAdmin export/import), reconnect via wp-config.php and fix URLs with search-and-replace, test privately before going live, cut over DNS while keeping the old host alive through propagation, verify, then retire the old host. Or let a host like Hostinger migrate it free.