Why moving feels riskier than it is

People stay with hosts they dislike for years because moving feels dangerous. It is not — a website move done in the right order has no downtime at all, because for a short while your site simply exists in two places at once.

The fear is understandable. Your site is live, it is earning links or customers or readers, and the move involves DNS — the part of web infrastructure most people understand least. Horror stories about days of downtime circulate freely.

Almost all of those stories share the same root cause: the site was deleted from the old host before the new copy was confirmed working. Do it in the order below and there is no moment at which your site does not exist somewhere. Visitors during the transition reach either the old copy or the new one, and both work.

The whole process, for a typical WordPress or HTML site, takes an afternoon — most of which is waiting, not working.

Take an inventory before you touch anything

Ten minutes of writing things down prevents the two most common migration surprises: forgotten email accounts and forgotten subdomains.

List every mailbox on the domain. Email is the piece people forget, because it works invisibly until the day it does not. Note every address, and warn anyone using them that mail may need re-downloading after the move.

List every site and subdomain. A blog at blog.yourdomain.com, a staging copy, an old landing page — anything that resolves needs a plan, even if the plan is “let it die deliberately”.

Note your PHP version and any special configuration. If the old site runs PHP 8.1 with a raised memory limit and specific extensions, the new host needs to match or better it. Mismatched PHP versions are the most common reason a moved WordPress site shows errors on arrival.

Find your domain registrar login. Not your hosting login — the place the domain itself is registered. If hosting and registration are with the same company you are leaving, check now that you can transfer or at least edit the nameservers. This is the one item that can genuinely block a move, and you want to discover it on day one, not day three.

Lower your DNS TTL first — the step everyone skips

Every DNS record carries a TTL — time to live — telling the world's resolvers how long they may cache the answer. If your records have a TTL of 24 hours, some visitors will keep being sent to the old server for up to a day after you switch. That is where “propagation takes 48 hours” folklore comes from.

You can shrink that window to minutes. A day or two before the move, log into wherever your DNS is managed and lower the TTL on your main records to 300 seconds. Then, when you change the records later, the old cached answers expire within five minutes and nearly everyone lands on the new server almost immediately.

This costs nothing, takes two minutes, and is the single biggest difference between a seamless switch and a ragged one. If DNS is new territory, our plain-English DNS guide covers what each record type does.

Copy the site: files, database, email

Files. Download everything from the old host — a compressed backup from the control panel if offered, otherwise the full public_html directory over FTP. Upload it to the same location on the new host. For a hand-written HTML site, this step is the entire migration.

Database. For WordPress and most other applications, export the database with phpMyAdmin (Export → SQL is fine at typical sizes). On the new host, create a fresh database and user, import the file, and update the application's config — for WordPress that is the database name, user and password in wp-config.php. If the new host's database server is localhost, as it almost always is, nothing else changes.

Email. Recreate each mailbox from your inventory on the new host, with the same addresses. Old messages live wherever they were downloaded to; if a mailbox was IMAP-only, download its contents before the old account closes, because mailbox contents do not travel with DNS.

Many hosts, ourselves included, will handle this copying step for you if you ask — it is routine work. But it is worth understanding even if someone else does it, because you are the only person who knows whether the result is complete.

Test on the new server before touching DNS

This is the step that makes the whole process safe. You want to see the site working on the new server while the world is still being sent to the old one.

The cleanest method is a hosts-file override. Add a line to your computer's hosts file pointing your domain at the new server's IP address, and your machine — and only your machine — will load the site from the new host. Click through it properly: pages, images, forms, the admin area, anything that touches the database.

Some control panels also offer a temporary preview URL, which is quicker but can confuse applications that care about their own address — WordPress among them. The hosts-file method tests the site under its real domain, which is what you actually need to know works.

Fix anything broken now, at leisure, with zero visitors affected. Only when the new copy is demonstrably right do you move on.

The switchover, and what happens during it

Now the anticlimax. At your registrar, either change the nameservers to the new host's, or — if you manage DNS separately, for instance at Cloudflare — update the A record to the new server's IP. Because you lowered the TTL earlier, resolvers pick up the change within minutes.

During the changeover window, some visitors briefly reach the old server and some the new. Both serve a working site, which is why nobody notices anything. If your site takes orders or comments, you can put the old copy into a read-only or maintenance state just before switching so that nothing is written to a database you are about to abandon — for most sites this is unnecessary caution, but for a busy shop it is worth the five minutes of maintenance page.

Once DNS resolves to the new server, request or confirm the SSL certificate there. On hosts with automatic issuance this happens on its own once the domain points correctly; check the padlock rather than assuming.

After the move: wait before you cancel

Keep the old account alive for two to four weeks. It costs a few pounds and buys you a complete fallback copy while stragglers — search crawlers, mail servers with long caches, that one visitor whose ISP ignores TTLs — finish arriving at the new address.

In that window: raise your TTLs back to something normal (an hour is fine), take a fresh backup from the new host and confirm it restores, and watch the new server's logs for 404s that reveal anything the copy missed.

Then cancel the old service — the service, not the domain. Your domain registration is separate and continues untouched, which is exactly why owning it yourself matters: the entire move you have just done was possible because the address was yours to point wherever you liked.

If you are weighing up a destination, our free 30 days exists for precisely this situation — you can build and test the copy on a live Traxio account before deciding anything, with no card details taken and the full specification published so you can check it against your inventory first.