Moving a Website to a New Host Cleanly

1. Moving house is not the same as rebuilding

Two situations get mixed up. In one, the addresses stay identical and the same site simply runs on a different machine, usually because the old host is slow, expensive or unreliable. In the other, the site is redesigned and the URL structure changes along with it.

The risk levels are nowhere near each other. A redesign that changes addresses needs every old URL mapped and redirected, and getting that wrong wipes out search traffic outright. That job is involved enough to deserve its own article, and there is already one on this site covering the URL mapping and the redirects. This one stays with the case where addresses do not change, so none of that is repeated here.

2. Inventory before you touch anything

The inventory belongs at the start, not halfway through. The list below is what gets checked line by line on a real move, and every item on it has caught somebody out.

The value of the inventory is not in how complete the list looks. It is in asking the same question of every line: once this is on the new host, who is responsible for keeping it working. Items you can answer are done. Items you cannot are the ones that will break next week.

3. Stand it up on the new host and check it there first

The right order is to build the whole site on the new host, verify it through a temporary address, and only then change DNS. Cutting over and fixing as you go means testing on live traffic.

Google publishes guidance for exactly this kind of move where the URLs stay the same, and it recommends the same order: copy first, test fully, then switch. It flags one thing in particular. While you are testing on a temporary address, block search engines from it, so the temporary address is never indexed and never ends up competing with the real site as duplicate content.

Checking is not clicking through a few pages to see whether the layout survived. Use the site for real: place an order, submit the contact form, log into the admin, upload an image, publish a test post. Those actions touch database writes and file permissions, which is where a new environment goes wrong. Read-only pages almost always pass first time. It is the things that write that fail.

4. The cutover, and how to avoid going dark

Nearly all the downtime risk in a host change is concentrated in the few hours around the DNS change. DNS is cached: once networks around the world have your record, they keep it for a set period before asking again, so after a switch some visitors reach the new host and some are still on the old one.

Two things shorten that window. First, about a week ahead, lower the value on your DNS records that says how long to keep an answer before asking again. The Google guidance recommends this as well, and it means the new location propagates quickly on the day. Second, do not shut the old host down after the switch. Let both stay alive.

When can the old host be switched off? Google's advice is to watch the logs and wait until traffic to the old provider reaches zero. In practice keeping it another week or two is calmer, and a month of rent is far cheaper than moving twice. During that period do not change anything on the old host either. Its only job now is to be a spare.

5. What to verify once it has landed

Verification needs a written list, run once on cutover day and again the following day. Some items only reveal themselves after a day has passed, scheduled jobs above all.

Rows three and five are the ones people skip, because neither leaves a mark on the site. Everything looks perfect while order confirmations have quietly not been sent for a fortnight, and you find out through a complaint.

6. The four things most often missed, and what it costs

Scheduled jobs, mail, certificates and upload permissions account for the overwhelming majority of post-migration problems. Jobs and certificates are covered above, so here are the other two.

Mail deserves the space. Many sites send their notifications straight from the web server, and the receiving side checks whether your domain has authorised that machine to send on its behalf. The mechanism is called SPF, defined in RFC 7208, and it works by listing the permitted senders in your domain settings. Changing host means changing the machine that sends, and if the list is not updated, notifications land in spam or bounce.

Upload folder permissions are the quietest failure of the lot. The files copied across, but the ownership or permissions do not match how the new host is configured, so uploading an image from the admin fails or older images stop displaying. Uploading one image proves it in seconds, which is precisely why it keeps getting skipped.

On price, quotes for a migration vary on three things. How complicated the site is, since a brochure site and a membership site with payments and integrations are worlds apart. Whether the new environment has to be built from scratch. And how hard you want the downtime pushed towards zero. A straightforward WordPress site moving to a comparable host is usually under a day of work. Handling scheduled jobs, mail and a cutover with no visible gap is quoted separately. When you ask for a price, confirm whether it includes building the environment and running the verification afterwards, because those two often outweigh the copying.

When can you do it yourself? A simple site with no members or orders, on a host that offers a one-click migration tool, is entirely reasonable to move yourself and not worth paying for. If the site takes payments, runs scheduled jobs or talks to third-party services, or if you are honestly not sure what else is running on the old host, it is worth bringing somebody in. Not for the copying. For the inventory and the verification.