How to Move a Website to a New Host Without Downtime

Most site migrations that go wrong do not fail during the file copy. They fail at 11 p.m. on a Friday, when someone changes the DNS record, sees the new server answer on their laptop, closes the old account, and then learns that half the visitors were still being sent to a machine that no longer exists. When you move a website to a new host, the copy is the easy part. The hard part is the hour where two servers both think they are the real one.

I have done this enough times, for small shops, documentation sites and one stubborn forum, to have a fixed order of operations. It is boring on purpose. Follow it and the people visiting your site will never know anything changed.

Lower the DNS TTL Two Days Before You Move a Website to a New Host

Every DNS record carries a time to live, measured in seconds. Many registrars default to 3600 (one hour) and some to 86400 (a full day). Resolvers around the world cache your record for that long, so if your TTL is a day, some visitors will keep reaching the old server for up to 24 hours after you switch.

Two days before the move, drop the TTL on the A, AAAA and any CNAME records for the site to 300 seconds. Waiting matters: the old, long TTL has to expire from caches before the short one takes effect. If you lower it ten minutes before the switch, you have changed nothing.

While you are in the DNS panel, write down every record that exists today. MX, TXT and verification records are easy to lose if the new host offers to "manage DNS for you" and imports only half of them, which is how mail silently breaks during a website move. If email is involved at all, read how to switch email providers without losing a message before touching anything.

Build the New Server as a Copy, Not an Upgrade

The temptation is to use the migration as a chance to move from PHP 8.1 to 8.3, switch database engines and tidy the folder layout. Resist it. If something breaks after the switch, you want exactly one possible cause.

Match the language runtime version, down to the minor release.
Match the database version, or at least the major version.
Copy the web server configuration, including redirects and headers, not just the files.
Recreate scheduled jobs. Cron entries are the item people forget most often, and nothing complains until the nightly backup or newsletter quietly stops.

Upgrade later, on a calm Tuesday, once the move is finished and proven.

Test the New Server Before DNS Points at It

You can visit the new server under your real domain name without changing public DNS. Add one line to your local hosts file that maps the domain to the new server's IP address. On Linux and macOS the file is /etc/hosts; on Windows it lives at C:\Windows\System32\drivers\etc\hosts.

Now your machine sees the new site while the rest of the world sees the old one. Click through the pages that earn money or matter most: login, checkout, contact form, search, file uploads. Check that the TLS certificate is valid. Many hosts can only issue a free certificate after DNS points at them, so either upload a copy of your current certificate or plan for a DNS based certificate challenge in advance.

Freeze Writes Before the Final Sync

A static site can be copied whenever you like. Anything with a database cannot. Orders, comments and form entries keep arriving on the old server while you copy, and anything written after your last database dump is lost.

The fix is a short write freeze. Put the site into maintenance or read-only mode, take a final database dump, import it on the new server, then switch DNS. For a small site with a database under 2 GB this window is usually under fifteen minutes. Pick the quietest hour in your analytics.

A rough timeline that works

When	Task
Day minus 2	Lower TTL to 300, record every DNS entry
Day minus 1	Build new server, first full file and database copy, test via hosts file
Switch hour	Freeze writes, final dump and import, change DNS
Day plus 1 to 7	Watch logs on both servers, keep the old one running

Why "Just Use the Migration Plugin" Is Weak Advice

Forums love to answer every migration question with a one-click plugin. These tools are fine for the file and database copy. They are not a migration plan. They do not lower your TTL, they do not move cron jobs, they do not know about the redirect rules in your server config, and they cannot tell you if your MX records survived.

They also tend to fail on exactly the sites where failure hurts: large media libraries that hit upload limits, or databases big enough to time out mid-export. A plain database dump and an rsync of the files are slower to learn, but you can see each step succeed. When something goes wrong you know which step it was.

Keep the Old Host Alive for a Week

Even with a 300 second TTL, some resolvers ignore short TTLs and some corporate networks cache aggressively. A few stragglers will hit the old server for days. Keep it running, in read-only mode, for at least seven days.

Check the old server's access logs each day. When traffic falls to only bots and uptime monitors, you can cancel it. Before you do, take one last full backup and store it somewhere that is neither host. If you run your own hardware, the same rule applies; the notes on running a home backup server cover where that copy can live.

After the Switch, Check the Things Nobody Sees

The homepage loading is not proof of success. Go through the less visible parts:

Send a test message through every form and confirm it arrives.
Check that outgoing mail from the site still passes SPF and DKIM, since the sending IP has changed.
Confirm scheduled jobs ran at their next due time.
Look at the error log for the first 24 hours, not just the first ten minutes.
Raise the TTL back to 3600 once you are sure you will not need to roll back.

The SPF point catches many people. If your site sends mail directly and the new server's IP is not in your SPF record, password resets start landing in spam the next morning.

Frequently Asked Questions

How long does it take to move a website to a new host?

For a typical small site, plan about three days end to end: two days of waiting for the lowered TTL to spread, a few hours of building and testing, and a switch window of under thirty minutes. The waiting is most of it.

Will moving hosts hurt my search rankings?

Not if the URLs, content and redirects stay the same and the site never goes offline. Search engines see a new IP address and carry on. Rankings drop when migrations change URLs without redirects or leave the site broken for hours.

Can I roll back if the new server has problems?

Yes, which is the whole reason to keep the old host running and the TTL low. Point DNS back at the old IP, and within about five minutes most visitors return to the old server. Any writes made on the new server need copying back by hand.

The Short Version to Keep

Lower the TTL two days early, copy rather than upgrade, test through your hosts file, freeze writes for the final sync, and leave the old server running for a week. For more step by step help of this kind, the guides section collects the rest.