Premium hosting, support and maintenance for Australian businesses

Website Management ServicesWMSWEBSITE MANAGEMENT SERVICES
Log in

Insights & resources

Website Migration Without Downtime: A Step-by-Step Plan

A long aisle between rows of open metal server and equipment racks in a large, light-filled hall

Key takeaways

  • A website migration without downtime works because the old and new hosts run side by side until every visitor has moved across.
  • Lower your DNS “time to live” (TTL) days before the move, so the switch takes minutes to spread instead of hours.
  • Test the site on the new host privately before you change any DNS, and freeze edits and orders during the final copy.
  • Email is the part most often forgotten. Check your MX records and mailboxes before and after the switch.
  • Keep the old hosting until its traffic has stopped and you hold a final backup.

You can move a website to a new host without your customers noticing. The trick is to build and test the new copy first, then switch your domain across while the old host keeps running. Done in the right order, the only visible change is that your site gets faster or more reliable.

This guide sets out that order as a step-by-step plan, with a flowchart you can follow. It suits WordPress, WooCommerce and most other sites. If you’d rather not do it yourself, every WMS hosting plan includes a free website migration.

What causes downtime during a website migration?

Most migration downtime comes from three mistakes. The domain is pointed at the new host before the site there is ready. The old hosting is cancelled too early. Or email records are changed (or forgotten) along the way.

The internet finds your website through DNS, the system that turns your domain name into a server address. DNS answers are saved (cached) by networks around the world. The time to live, or TTL, on each record tells those networks how long to keep the saved answer before asking again (Cloudflare).

So when you change a record, some visitors reach the new server straight away, while others keep reaching the old one until their cached answer expires. That overlap is normal. It only causes downtime if the old server has already gone, or if the two copies of the site differ.

The zero-downtime cutover, step by step

Here is the whole sequence on one page. The sections below explain each phase in plain English.

Website migration cutover flowchart Four phases. Prepare: take stock, then lower the DNS TTL. Build and test: copy the site to the new host, test it privately, and fix any problems before going on. Cutover: freeze changes and do a final sync, then switch DNS to the new host. Parallel run: both hosts run while caches expire; check the site, forms and email, and point DNS back if something is wrong; then raise the TTL, watch the old server until its traffic stops, take a final backup and cancel the old hosting. 1. Prepare (a week or more before) 2. Build and test (visitors see nothing) 3. Cutover (quiet time of day) 4. Parallel run and clean-up Take stock Lower the DNS TTL Copy the site to the new host Test it privately Everything works? Freeze changes, do a final sync Switch DNS to the new host Run both hosts side by side Site, forms and email OK? Raise the TTL and monitor Final backup, cancel old hosting Site, email, DNS records, forms, logins For example to 300 seconds, then wait Files, database, mailboxes, SSL Hosts file or temporary address Pause edits and orders, copy latest data Change A records or nameservers; keep MX Old host serves visitors until caches expire Watch old server logs until traffic stops Keep the backup somewhere safe Fix the problem, then test again. DNS not touched. Point DNS back to the old host, then fix and retry. Yes No Yes No
The cutover sequence. Nothing changes for visitors until step 3, and the old host stays live as a safety net until step 4 is finished.

Phase 1: How do you prepare for a website migration?

Take stock of everything the domain does

Before anything moves, write down what your domain actually runs. Most owners think only of the website. In our experience, the surprises are usually elsewhere.

  • The website itself, plus any staging copies or subdomains (shop.yourdomain.com.au).
  • Email: who hosts it, and the MX, SPF, DKIM and DMARC records that make it work.
  • Every DNS record, exported or screenshotted, so you can rebuild it exactly.
  • Contact forms, payment gateways and anything that sends email from the site.
  • Scheduled tasks, such as backups, feeds or WooCommerce subscriptions.
  • Logins for the registrar, the old host, the new host and the website admin.

Lower the TTL early

Find the TTL on the records you’ll change (usually the A records for the domain and www). If it’s 14,400 seconds, that’s four hours of caching. Lower it to something short, such as 300 seconds (five minutes).

Then wait at least as long as the old TTL before you switch, so the old, longer value has expired everywhere. Google’s own advice for host moves is to lower the TTL ahead of time, ideally about a week before (Google Search Central).

One catch: if you’re changing nameservers rather than individual records, part of the delay sits with the domain registry, not with you. Allow a longer overlap in that case. Our domain and DNS management team can tell you which kind of change your move needs.

Phase 2: How do you test a site before switching DNS?

Copy the files, the database and (if they’re moving) the mailboxes to the new host. For WordPress, the details are in our guide to migrate a WordPress site safely.

A person at a desk reviewing a website dashboard on a laptop, with a coffee cup in the foreground
Test the new copy properly before any visitor reaches it. This is where most migration problems are found and fixed. Photo: Gabriel Weyand on Unsplash

Now test the new copy without touching public DNS. There are two common ways. Your host can give you a temporary address, or you can add a line to your computer’s “hosts” file so only your computer sees the new server. Either way, the public keeps using the old site.

Work through the site as a customer would:

  1. Open the main pages, including on your phone.
  2. Submit every contact form and confirm the emails arrive.
  3. Log in to the admin area and save a test change.
  4. If you sell online, run a test order and refund it.
  5. Check the SSL certificate is ready, or know how your host will issue it.

On SSL: free certificates from Let’s Encrypt are often issued by checking a file on the web server, which only works once the domain points there (Let’s Encrypt). A good host issues the certificate the moment DNS switches, or uses a DNS check to issue it earlier. Ask which one yours does.

If anything fails, fix it and test again. You haven’t changed DNS yet, so nothing is at risk.

Phase 3: What happens on cutover day?

Freeze changes, then do a final sync

Pick a quiet time. Ask everyone to stop editing pages, and pause new orders if you run a shop. Then copy the latest database and any new uploads across. This closes the gap between your test copy and the live site.

For a brochure site, the freeze may last only a few minutes. For a busy shop, schedule it outside peak trading and tell staff in advance.

Switch DNS

Update the A records (or nameservers) to the new host. If your email is staying where it is, make sure the MX records still point to your current email provider. If email is moving too, update MX at the same time and check that SPF, DKIM and DMARC match the new service.

A person holding a coffee and a phone beside a laptop showing a login screen, checking email and access after a website move
After the switch, check email on more than one device, and log in to the site from a network outside your office. Photo: Viva Reella on Unsplash

Phase 4: How long should you keep the old hosting?

Keep the old hosting running while caches expire. With a low TTL, most visitors reach the new server within minutes. A few networks hold on to old answers longer, so the old copy keeps serving them in the meantime. That is why there’s no downtime.

During this window, check the live site, forms, checkout and email. If something is wrong, point DNS back to the old host. Because the TTL is low, the rollback spreads quickly too.

When all is well, raise the TTL again (an hour or more is common). Google suggests watching the logs on both servers and shutting the old one down only once its traffic reaches zero (Google Search Central). Take a final backup of the old account before you cancel it.

If email moved, also check the old mailboxes for a few days. Messages sent during the overlap can land there.

Will a host migration hurt my Google rankings?

Not if your web addresses stay the same. Google treats a change of host with no URL changes as a routine event. It notes that a temporary drop in how often Googlebot crawls the site is normal straight after the move (Google Search Central).

Changing platforms is different, because page addresses often change. If you’re also leaving a website builder, read our guide on moving from Wix to WordPress first, as that needs redirects as well as a move.

If you’re still choosing where to move to, compare our hosting plans. Every plan includes free SSL and a free migration.

Frequently asked questions

How long does a website migration take?

The copying and testing usually takes a day or two for a small business site, and longer for large shops. Preparation adds time, because you should lower the DNS TTL several days ahead. The cutover itself takes minutes. The old hosting then stays on for a few more days while the change spreads and you confirm everything works.

What is DNS propagation, and can I speed it up?

“Propagation” is really caching. Networks save DNS answers for as long as the record’s TTL allows, then ask again. You can’t force other networks to forget early, but you can lower the TTL days before the move. Then the cached answers expire in minutes rather than hours when you make the switch.

Will my email stop working when I change hosts?

Not if you plan for it. If your email stays with its current provider, keep the MX records exactly as they are. If email is moving too, set up the new mailboxes first, update MX and the SPF, DKIM and DMARC records together, and check the old mailboxes for a few days afterwards.

Do I need to tell Google when I change hosts?

No. If your page addresses stay the same, Google simply starts crawling the new server. Its guidance says a short dip in crawling right after the move is normal. Keep Search Console verified so you can spot errors. A change of domain or URLs is different and needs redirects.

What if something goes wrong after the switch?

That’s why you keep the old hosting running. Point the DNS records back to the old server, and because the TTL is low, most visitors return to the old copy within minutes. Fix the problem on the new host, test again, then repeat the switch at another quiet time.

Sources

  1. Changing your web hosting and SEO, Google Search Central, accessed 13 November 2026
  2. Time to Live (TTL), Cloudflare DNS documentation, accessed 13 November 2026
  3. Challenge types, Let’s Encrypt, accessed 13 November 2026

Want us to look after this for you?

Hosting, updates, backups and security, handled by an Australian team, so you can get back to running your business.

See Maintain & Protect
See hosting