How to Move a Website to a New Host Without Downtime

The question behind how to move website to new host is usually not technical, it's nervous: will my site go dark while this happens? It doesn't have to. Done in the right order, how to switch web hosting without downtime comes down to one principle. You build and finish the site on the new server first, while the old one keeps serving customers, and the domain only moves at the very end when the new home is already working.

The downtime people experience comes from doing it backwards: cancelling the old host, or pointing the domain at an empty server and then starting the upload. This is the order we use on client migrations, and it's the same for leaving a host that got expensive or one that got worrying.

How to switch web hosting without downtime: the DNS-first method

Here's the whole plan on one page. Each step is expanded below.

Copy everything before you cancel anything

First rule of any host move: you never cancel the old account until the new one has been live and stable for a while. Second rule: get a complete copy in your own hands, not just in the new host's migration tool. That means the files, the database, and a written record of your DNS. Our step-by-step on getting your website files from your hosting company covers the cPanel and SFTP routes.

Worth knowing: most decent hosts will do the migration for you free as part of signing up. Ask before you start. Their team does this daily, they have tooling you don't, and it costs nothing. You still take your own backup first, because their tool failing halfway is your problem, not theirs.

Test on a temporary address before the domain moves

This is the step that makes the whole thing safe, and it's the one people skip. There are two ways to look at the new site while your real domain still points at the old one.

• A temporary URL from the new host. Most hosts give you a preview address or a staging subdomain, and this is the one to use if you've never done anything like this before. It's easy, but it isn't a perfect test: on WordPress in particular, a site running under a different address can behave differently from one running under its real name.
• Your computer's hosts file, if you're comfortable with it. This is the more accurate test, but it means editing a system file, so it's worth having a developer do it if the wording below means nothing to you. You add one line locally that says "for me, this domain lives at this new IP address," and your browser then loads the new server using the real domain name while the rest of the world still sees the old site. On Windows the file is in C:\Windows\System32\drivers\etc, and on a Mac you edit /private/etc/hosts from the Terminal. Kinsta publishes a clear walkthrough for both.

Whichever you use, actually test. Click through every page, submit the contact form and confirm the email arrives, log in to the admin, check the site on a phone, and try the checkout if you sell anything. Ten minutes here saves a day of firefighting.

Lower the TTL, and understand what it buys you

TTL stands for time to live, and it's the number that decides how long the rest of the internet is allowed to remember your old settings. Change your DNS with a high TTL and computers around the world keep sending visitors to the dead server until their cached copy expires.

The numbers matter here. AWS notes that a typical TTL on the nameserver record is 172,800 seconds, which is two days, and warns that without lowering it your domain could be unavailable for up to two days if something goes wrong mid-migration. Cloudflare's own DNS migration guidance is to lower the TTLs on all critical records at least 24 to 48 hours before the migration window, and says a common short TTL for a migration is 300 seconds, or five minutes.

Copy every DNS record, because email is what actually breaks

Here's the mistake that turns a smooth migration into a bad week. Switching nameservers hands control of your entire DNS zone to the new host, and the new host has no idea what your old records were. GoDaddy states it plainly in their own instructions: changing your nameservers may break existing connections to your website or email. Cloudflare warns that an automatic scan of your existing records is not guaranteed to find all of them, and tells you to pay special attention to your mail records before you activate.

So before you change anything, take a screenshot or export of the current DNS zone and account for every line of it.

1. 1MX records. These route your email. If they're missing on the new side, mail bounces from the moment the nameservers change.
2. 2TXT records. SPF, DKIM and DMARC live here, plus verification records for Google, Microsoft and various tools. Drop these and your mail still flows but starts landing in spam.
3. 3CNAME records. Things like a webmail subdomain, a booking system, a help desk, an email marketing tracking domain.
4. 4A records for subdomains. A staging site, a client portal, an old app that only one department uses and only notices on the third day.
5. 5Anything you don't recognise. Do not delete it because you don't know what it does. Copy it across and investigate later.

If the safer path appeals, you can leave DNS where it is and just change the A record to the new server's IP address instead of switching nameservers. That moves only the website and leaves email untouched. We wrote a whole guide on switching hosting without losing email because it's the part that costs businesses real money.

WordPress specifics: which migration plugin

If you're on WordPress you have good options, and all of these are real plugins currently listed on WordPress.org with large install bases. The differences that matter are size limits and whether migration is in the free version.

After the move, go to Settings then Permalinks in your WordPress admin and just click Save, which resets the site's internal links for the new address. Check that images are loading from the new address rather than the old one. If something still looks odd, the migration plugins above have a built-in search-and-replace for leftover old server paths, or a developer can run one in a few minutes. Most WordPress migration weirdness is an address that got left behind somewhere.

What breaks most often

• Contact forms. The new server's mail configuration is different, so forms submit successfully and quietly deliver nothing. Always test a real submission after the switch, and consider sending form mail through a proper SMTP service rather than the server.
• SSL, for a few minutes. Free certificates from Let's Encrypt are usually issued by proving control over the domain through a file served at that address, which cannot work until the domain already points at the new server. In practice, expect a short certificate warning right after cutover. If that's not acceptable, ask the new host's support to issue the certificate through a DNS-based check instead, which can be set up before the switch. That part is worth leaving to them.
• Email. Covered above, and worth checking twice.
• Anything hardcoded. Scripts, integrations or apps that referenced the old server's IP address rather than your domain name will stop.
• Cron jobs and scheduled tasks. Backups, imports and report emails set up on the old server do not travel with the files.
• Redirects and rewrite rules. These live in server config files that a migration tool may or may not carry over. Spot-check a few old URLs.

Keep the old host running for a week

Resist the urge to cancel the moment the new site loads. Two reasons. First, DNS is not instant for everyone: GoDaddy's guidance is that most changes take effect within a few hours but can take up to 48 to update globally, and some internet providers refresh their cached records only every two or three days regardless of your TTL. Second, the old host is your rollback. If something serious surfaces on day two, pointing the domain back is a five-minute fix while the old server is still there, and an impossible one after you've cancelled.

A week is a sensible minimum. A month costs one more billing cycle and buys a lot of calm. Once you're sure, download one final backup from the old host, then cancel.

If you'd rather hand the move to someone

A small brochure site is a genuinely doable afternoon if you're comfortable with a control panel, and the new host's free migration service will often do most of it. Where we'd steer you away from DIY is a site with a store, a booking system, business email on the same account, or anything where an hour offline costs real money. If that's you, managed hosting is part of our care plans from $99 a month and includes moving your existing site over from whatever host it's on now, with the DNS and email handled as part of the job. The maintenance plan is what keeps it looked after afterwards.

If the reason you're moving is that the current host has gone quiet or is winding down, read what happens if your web host goes out of business first, and the warning signs worth watching for if you're still deciding.