How to migrate your WordPress site to Hostney

Moving a website to a new host sounds like the kind of thing that needs a developer. It usually is not. If you can install a plugin on your WordPress site and copy and paste a code, you can do this yourself, and you can do it without your visitors seeing anything change.

This guide walks through the whole thing from start to finish. It assumes you have already created a Hostney account and nothing else. You do not need to know what DNS is, you do not need to touch a command line, and you do not need to take your current site offline while you work.

There is one decision near the beginning that makes the rest either easy or annoying, and most people get it wrong because nobody tells them about it. We will get to that in step one, because it is the single most useful thing in this article.

The short version#

If you want the whole thing in seven lines:

1. Add your real domain in Hostney and verify it with a TXT record. This does not move your site or affect anything. Your current site keeps running exactly as it is.
2. Start a plugin migration and generate a token.
3. Install the free Hostney Migration plugin on your current site.
4. Paste the token into the plugin, click Connect, then start the migration from your Hostney dashboard.
5. Check the copy of your site on the temporary preview address Hostney gives you.
6. When you are happy, change two DNS records at your domain provider. That is the moment the switch happens.
7. Once the site is live on your own domain, turn the temporary preview address off.

The rest of this article explains each step, what you will see on screen, and what to do when something looks wrong.

Or ask us to do it for you#

Before you start: you do not have to do any of this yourself.

If you would rather hand the whole thing over, open a support ticket and our team will run the migration for you. In your Hostney dashboard, open the profile menu, go to Support tickets, and click New ticket.

It helps if you tell us three things in that first message:

• Which host your site is on now.
• The domain you are moving.
• Whether you want to keep the same domain or move to a different one.

We will tell you what we need from you and take it from there. This is worth doing rather than struggling if your site is large, if it is a shop taking live orders, or if a previous migration attempt somewhere else has already failed. The rest of this guide is for anyone who would rather do it themselves, and it is genuinely not difficult.

Step 1: Add your domain before you migrate, not after#

This is the part that saves you the most trouble, so it goes first.

Every WordPress site has its own web address stored inside its database, in thousands of places. Your images, your internal links, your menus, your page builder content, all of it contains the full address of your site. When a site is copied to a new home, every one of those addresses has to be rewritten to match wherever it landed.

Hostney does that rewrite for you automatically, at the end of the migration. But it rewrites the addresses to point at wherever you migrated to. So the destination you choose is the address that ends up baked into your database.

That gives you two paths:

The easy path. Add your real domain to Hostney first and verify it, then migrate directly onto that domain. Your site lands with its correct, final web address already in place. When you eventually switch over, nothing inside the site needs to change at all. You flip DNS and you are done.

The annoying path. Migrate onto a temporary address first. Your site lands with the temporary address written into it everywhere, and you have to do a second rewrite later to change it to your real domain. It works, but it is an extra step that can go wrong, and it is completely avoidable.

Here is the thing most people do not realise: you can add and verify your domain on Hostney while your site is still live somewhere else, and it changes nothing.

Verification works with a TXT record. A TXT record is a small note you attach to your domain at your domain provider. It is not an address, it does not route anything, and browsers never look at it. It exists purely so Hostney can confirm you actually control the domain. Your live site keeps serving visitors from your old host the entire time, completely unaffected.

So the order that makes life easy is:

1. In Hostney, go to Add domain and enter your real domain.
2. Copy the TXT record it shows you and add it at your domain provider, the company you bought the domain from.
3. Wait a few minutes. Verification usually completes quickly.

Now Hostney knows the domain is yours, and you can migrate straight onto it, even though the domain is still pointing at your old host and will keep pointing there until you decide otherwise.

What if you do not want to use your real domain yet#

Sometimes you genuinely want a separate address. Maybe you are rebuilding a site rather than moving it, or you are testing Hostney before committing, or you are moving a site to a different domain than it currently uses.

That is fine. Every Hostney account is given its own permanent starter address automatically, something like blue-tiger.hostney.cloud . It works immediately, no DNS setup at all, and you can migrate onto it just like a real domain. If you are moving a site to a genuinely different domain later, you will need to update its address afterwards, and our guide on how to change your WordPress domain name covers that.

But if the plan is “same domain, new host”, verify the domain first. It is five minutes now instead of an extra rewrite later.

Step 2: Choose the plugin migration#

In your Hostney dashboard, go to the migrations page and you will see two ways in.

Plugin migration is the one almost everyone should use. It works from any host that runs WordPress, whether that is a shared hosting account, a managed WordPress host, or a small VPS. You do not need any special server access. You install a plugin on your current site, and that is the whole requirement. There is a fuller description of what it does on the WordPress migration plugin page if you want to read it before you start.

SSH migration is the other option, and it is faster, but it only works if you have direct server access to your current host and know how to use it. If the phrase “SSH credentials” does not mean anything to you, that is not a problem you need to solve. Use the plugin.

Click Generate plugin token.

You will be asked to pick a destination, which is the website slot on Hostney that your site will land in. If you verified your domain in step one, it will be in this list. The destination has to be empty, because a migration overwrites what is there. If Hostney tells you no destinations are available, it means every slot on that domain already has a WordPress site or an app in it, and you need to add a new one first.

Generate the token. You will get a long code. Keep the page open.

A few things worth knowing about that token:

• It is single use. It authorises one migration and nothing else.
• It expires after 24 hours. If you get distracted and come back next week, just generate a new one.
• It is revoked automatically once the migration finishes.

Step 3: Install the plugin on your current site#

Now go to your existing site, the one you are moving away from, and log in to its WordPress admin as you normally would.

Go to Plugins, then Add new, and search for Hostney Migration. Install it and activate it.

Install it this way rather than hunting for a download link. Hostney Migration is a published plugin in the official WordPress.org directory, which means it is the same install process as any other plugin you have ever added, it updates itself automatically, and its source code is public for anyone to inspect. That last point matters more than it sounds: a migration plugin reads your entire database, including your users. Being able to point at a public listing and a public codebase is a reasonable thing to expect before you install something like that. If your current host blocks the plugin directory for some reason, there is a ZIP download available as a fallback, but the directory is the better route.

Step 4: Connect and start#

Open the Hostney Migration plugin on your current site, paste in the token you generated, and click Connect.

Note the direction here, because it trips people up: the token is created in Hostney and pasted into the plugin on your old site. Not the other way around.

Once it connects, go back to your Hostney dashboard. The migration will now show as connected, and a Start migration button appears. Click it.

From here it runs by itself. You will see live progress for the two things being moved:

• Database tables, which hold your posts, pages, settings, users and comments.
• Files, which are your images, uploads, themes and plugins.

You will also see how much data has actually arrived. On a large site this can take a while, and that is normal. You can leave the page and come back. You can also pause the migration and resume it later if you need to.

Your old site stays fully online and working throughout. Visitors continue to see it as normal. Nothing about this step touches your live site beyond reading from it.

If your site is large#

Hostney checks your database size against your plan when the plugin connects, again when you press start, and once more on our side while it runs. If your database is too large for your current plan, you will be told at the first of those checks rather than discovering it halfway through a transfer.

The migration itself is built to survive slow and restrictive hosts. It pulls your data in small pieces rather than building one enormous archive, it checksums each piece on arrival, and it retries anything that fails rather than starting over. That is the difference between this and the more common approach, and it is the reason migrations that failed elsewhere tend to complete here. The migration plugin page goes through that design in more detail. If you want the technical explanation of why archive-based migrations break so often, we wrote about why most WordPress migrations fail in detail.

Step 5: Check the copy before anyone else sees it#

When the migration finishes, your site exists on Hostney. Your visitors are still going to the old one, because you have not changed anything about where your domain points.

So how do you look at the new copy?

Hostney gives every website a second address on its own domain, ending in hostney.app . It points at the same site, and you can use it to browse the migrated copy in a normal browser while your real domain is still serving from your old host. It is a proper HTTPS address, so nothing looks broken.

That preview address also serves instructions telling search engines not to index it, so you are not at risk of Google finding a duplicate of your site and getting confused about which one is real.

Take a proper look around. A sensible checklist:

• Load the homepage and a few inner pages.
• Log in to the WordPress admin.
• Check a page built with your page builder, if you use one.
• Check that images are loading, not just showing as broken boxes.
• If you run a shop, load a product page and the cart.
• Check a contact form still submits.

If something is missing, you have not broken anything. Your real site is still running on your old host, untouched. You can fix things on the copy, or start a fresh migration, with no pressure and no downtime.

If you want a permanent version of this arrangement for future changes rather than just for the move, Hostney has a proper staging feature that clones your live site to a separate hidden copy, which is covered in how to create a WordPress staging site.

Step 6: Go live#

This is the only step that actually changes what your visitors see, and it happens at your domain provider, not in Hostney.

You need to change two records:

• One for your domain itself, for example yoursite.com .
• One for the www version, www.yoursite.com .

Both are A records, and both need to point at the IP address Hostney shows you on your dashboard. An A record is simply the setting that says “this web address lives at this server”. Changing it is what moves your traffic.

Two things to note, because they cause unnecessary panic:

You are only changing A records. You are not changing your nameservers. This matters because your email, if you use email on this domain, is controlled by different records entirely. Leave those alone and your email keeps working exactly as it does now.

Your certificate is issued after you point the domain, not before. The security certificate that puts the padlock in the browser can only be issued once your domain actually reaches Hostney, because that is how the verification works. So there can be a short window right after you switch where the certificate is still being set up. It sorts itself out on its own within a few minutes. Do not panic and change things back.

Hostney’s dashboard will keep checking both records and tell you when each one is reaching us properly, so you are not guessing.

Why there is no downtime#

DNS changes do not happen instantly everywhere. For a period after you make the change, some visitors will still be sent to your old host while others reach the new one. This is normal and unavoidable with any host change.

The reason it does not cause downtime here is that both copies of your site are live and working during that window. Someone who lands on the old host sees your old site. Someone who lands on Hostney sees the migrated copy. Both work. Nobody sees an error page.

The practical consequence is worth understanding: for those few hours, anything written to your site could land on either copy. If you run a shop or accept comments or form submissions, do not take orders in that window if you can avoid it, or accept that a small number might arrive on the old site. Most people switch in the evening for exactly this reason.

Once it has settled, keep your old hosting for a couple of weeks before cancelling. It costs one more month and it is cheap insurance.

If your own computer still shows the old site after everything else has switched over, that is almost always your local cache rather than a real problem, and how to flush your DNS cache will clear it.

Step 7: Turn off the temporary address#

Once your real domain is live and working, the temporary hostney.app preview address has done its job. It is still there, and it still works, which means your site now answers on two different addresses when it only needs one. Turn it off.

Do this after you have confirmed the real domain is working, not before. Until the switch is complete the preview address is your way back into the site, so it is the last thing you close, not the first.

Here is where to find it:

1. In your Hostney dashboard, go to Subdomains.
2. Find the website you migrated in the list.
3. Click Manage on that row.
4. Choose HUC URL from the menu. HUC is just what we call this alternative address internally, and it is the same one you used to preview the site.
5. Switch Enable HUC URL off.
6. Click Update HUC URL.

The change takes about a minute to apply. Once it has, the row shows an HUC off badge so you can see at a glance that it is disabled. If you ever need the preview address again, for example before making a big change to the site, come back to the same place and switch it back on.

One exception: if you migrated onto your Hostney starter address rather than your own domain, there is nothing to turn off here, and the option will not appear. That address is not a preview of your site, it is your site’s actual address, so leaving it on is the whole point.

What can go wrong, and what to do#

The plugin will not connect. The usual cause is an expired token. They last 24 hours. Generate a new one and paste it again.

There is no destination to migrate into. The slot you want already has something in it. Migrations need an empty destination so they cannot overwrite an existing site by accident. Add a new website slot, or clear the one you meant to use.

The migration stops partway. Pause and resume it. It picks up from where it stopped rather than starting again from the beginning.

Some images are missing on the copy. Check whether they are actually present on your old site, since it is very common for a site to have broken images that nobody noticed until a migration made them obvious.

The site is on Hostney but visitors still see the old one. Then your DNS has not been changed yet, or it has not spread yet. Check your A records at your domain provider.

You migrated to a temporary address and now need the real one. This is the annoying path from step one, and it is fixable. See how to change your WordPress domain name.

You turned off the preview address too early and cannot reach the site. Go back to Subdomains, open Manage, then HUC URL, and switch it on again. Nothing was deleted.

You are stuck and would rather someone else finished it. Open a support ticket. There is no prize for doing this alone, and a half-finished migration is a completely normal thing to hand over. Tell us where you got to and we will pick it up from there.

If you would rather do it by hand#

Some people want to understand every step, or are moving something unusual that a plugin will not handle cleanly, such as a multisite install or a site with a heavily customised setup.

The manual route is to export the database, copy the files over, import the database on the new host, update the configuration file, and rewrite the URLs yourself. It is entirely doable and we have written it up in how to migrate WordPress to another hosting provider. If you want to understand the general shape of a site move before you start, what is website migration and how does it work explains the concepts without assuming a specific host.

If you are on a host that makes even backups awkward, which is a common reason people finally leave, how to backup a WordPress site from IONOS covers getting your data out of a restrictive environment.

A note on the order of operations#

Almost every piece of migration advice on the internet tells you to move the site and then deal with the domain. That advice is a holdover from when hosts could not verify a domain without you pointing it at them first.

You can verify without pointing. That one change flips the whole process around and removes the step that causes the most trouble, which is rewriting your site’s address twice.

So if you remember one thing from this article: add your domain and verify it first, then migrate onto it. Everything after that is just clicking through the steps and checking your work.