Moving Hosts Without Going Offline
Downtime during a host switch is usually a planning problem, not a technical one. This is the seven-step order of operations that keeps both servers live until the traffic has moved.
Written by Tom George · How we research hosts
Why Downtime Is Usually Optional
When a migration goes wrong, people blame DNS. Kinsta's guide to DNS during site migrations makes the opposite point: most downtime comes from the gaps between DNS, hosting and the application, such as an SSL certificate that is not ready, a mistyped IP address or a forgotten record. It also recommends keeping both environments running during the move and pausing edits and orders during the switch, so nothing is written in 2 places and no data is lost.
All of those are preventable with the right order of operations. This page is that order, written as a checklist you can follow for any host switch.
Where a step comes from a host's own documentation, we say so. Where it is our own judgment, we say that instead. If you already know your source host, the host-specific guides linked at the end go deeper.
Keep both servers live until traffic has clearly moved. Overlap is what turns a risky cutover into a boring one, and it is also your rollback plan.
Treat DNS as the last step, not the first. Build the new site, test it, get SSL ready, freeze edits, and only then change the records.
Moving to a managed host? Most offer a migration service, compared in free migration services, or start with our Kinsta, Rocket.net and Pressable reviews.
The Timeline at a Glance
| When | What you do |
|---|---|
| 12 to 24 hours before | Lower the TTL on the records you will change |
| Migration day, first | Copy the site to the new host; keep the old one live |
| Before any DNS change | Preview and test the new site, and get SSL ready |
| Cutover window | Freeze edits and orders, sync, change only the A/AAAA/CNAME records |
| First hours after | Watch traffic, SSL, logs and mail; expect mixed results |
| Several stable days later | Restore normal TTL, then cancel the old host |
Step 1: Lower the TTL a Day Ahead
TTL (Time to Live) is how long other servers may reuse your DNS answer before asking again. A short TTL means that when you change the record, visitors move to the new server sooner.
Kinsta's migration documentation recommends lowering your domain's TTL to 300 seconds 12 to 24 hours before migration, and raising it back to around 3600 seconds after launch. Its DNS guide says to lower it at least 24 hours before the switch, calls 300 to 600 seconds a good balance, and warns that a last-minute change does not help because caches already holding the old value keep it until it expires. It also notes that very low values do not guarantee instant updates and that some resolvers ignore them.
In our judgment, lowering it a full day ahead satisfies both Kinsta pages.
After you change it, confirm the new value is live with a DNS lookup tool before you rely on it. If you use Cloudflare for DNS, Kinsta's documentation says you do not need to change TTL.
Step 2: Build the New Site and Keep the Old One Live
Use the new host's migration tool or team to copy your site, as in our Kinsta free migration checklist, or move it yourself with one of the WordPress migration plugins. Compare what each host offers in our free migration services comparison.
The key rule is that the old site stays live and untouched while the copy is made. That overlap protects your visitors and gives you a rollback path.
Step 3: Preview the New Site Before Touching DNS
You can see exactly what visitors will see without changing public DNS. There are two ways.
Use the host's preview tool
Some hosts give you a temporary URL or preview mode. Kinsta's Site Preview tool, for instance, can be enabled for 1, 4, 8 or 24 hours and lets you test the site on your live domain.
Edit your hosts file
WP Engine's support documentation describes the hosts-file trick: pair a server IP address with your domain in the hosts file on your computer, flush your DNS cache and fully restart your browser. Its example uses a WP Engine IP address; for your move, use the new host's IP. Your computer then loads the new site for that domain while everyone else still sees the old one.
The steps below follow that approach. The file locations are standard operating-system details and are not from WP Engine's page, which links to editor tools instead.
- Get the new host's IP address from its dashboard.
- Add a line in the format
ip-address yourdomain.comto your hosts file. On Windows the file isC:\Windows\System32\drivers\etc\hosts; on macOS and Linux it is/etc/hosts. - Flush your DNS cache, then fully restart your browser.
- To undo it, delete the line or comment it out, flush DNS and restart the browser.
The change is local to your machine only and is easy to reverse. Remember to remove it afterwards, or you will keep seeing the new server and wonder why nothing matches what visitors report.
What to test
Open the key pages, log in to the admin, submit a contact form, run a test checkout if you have a store, and check that images and links work. Our TTFB check also works on a preview, which tells you whether the new host is actually faster for your visitors.
Step 4: Get SSL and the Other Records Ready
Kinsta's DNS guide lists SSL misalignment as a frequent cause of downtime: DNS points to the new server, but the certificate is not installed or does not cover the domain yet, so browsers block access and visitors experience an outage.
Generate or upload the certificate on the new host before the cutover. Then list every record on your current DNS: the main A record, the www record, mail (MX) records and any verification records. Overlooking mail or www records causes partial outages.
Step 5: Freeze Edits, Then Switch Only What Must Change
DNS does not move data. If your site takes orders, comments or sign-ups, anything written to the old site after the copy was made will not be on the new one. Pause orders and edits, make a final sync or a second migration if the host supports it, and only then change DNS.
Change only the records that need to point to the new server, usually the A, AAAA or CNAME records. In our judgment, nameserver changes are only needed when you switch DNS providers, and most migrations do not require one. Also in our judgment, leave MX records alone unless you are also moving email.
After you save the change, check it with direct DNS queries and not only a browser, since your own browser or device may still hold a cached answer.
Step 6: Watch the Rollout, Expect Mixed Results
Kinsta's guide notes that DNS changes are picked up as caches expire, so two people can briefly see different versions of the site. It also says the old "24 to 48 hours" rule oversimplifies the picture: many visitors see the update within minutes, others later.
Success means new traffic keeps resolving to the new server without errors. Check SSL on all your domains, test your redirects, watch for spikes in 404 and 500 errors, and confirm your email still arrives. Clearing your own browser cache does not change what other people's resolvers hold.
Step 7: Keep a Rollback Path, Then Clean Up
In our judgment, the best rollback plan is simply not shutting the old server down early. If something breaks, you point the records back at the old IP address. With a low TTL the change usually reaches visitors sooner, though the exact time depends on TTL and resolvers.
The catch is data. Any orders or edits made on the new site while you were live on it have to be copied back, so decide in advance who owns that task.
As a rule of thumb of our own, once the new site has been stable for several days, restore the normal TTL and then cancel the old host. Cancelling the same day you switch removes the safety net you built in step 2.
Where Switches Usually Go Wrong
- Wrong or mistyped IP address. DNS resolves correctly to the wrong server, so it looks like downtime.
- SSL not ready. The site loads on the new server but browsers refuse to open it.
- Forgotten mail or www records. Part of the site, or all of your email, stops working.
- Edits during the move. Data written to the old site after the copy goes missing.
- Cancelling the old host too soon. You lose both the overlap and the rollback path.
Pick the Guide for Your Move
This checklist works for any host. For a specific route, these go deeper on the problems unique to each source.
- WP Engine to Kinsta — the LargeFS, SSL and WooCommerce cutover issues.
- Leaving WP Engine — how to migrate without losing rankings or traffic.
- SiteGround to Kinsta — the renewal shock and what breaks on the way out.
- GoDaddy to Cloudways — what breaks and how to fix it.
- Bluehost to Rocket.net — whether the speed gain is worth the price jump.
Choosing the destination first? Read the Kinsta review and the Rocket.net review, and check each host's pricing history with our price history method before you commit.
See Kinsta Plans → Read the Rocket.net Review →
Frequently Asked Questions
How long does DNS propagation really take?
It varies. Many visitors see a change within minutes, while others keep an old answer for longer because resolvers and devices cache DNS results for different lengths of time.
The old 24 to 48 hour rule oversimplifies it. Lowering your TTL in advance shortens the window.
What TTL should I set before a migration?
Kinsta's documentation recommends 300 seconds, set 12 to 24 hours before the migration, then raised again to around 3600 seconds after launch. Its DNS guide says at least 24 hours before and describes 300 to 600 seconds as a good balance.
In our judgment, a full day ahead satisfies both, because a long-lived cached record will not shorten until it expires.
Do I need to change nameservers to switch hosts?
In our judgment, usually not. Nameserver changes are only needed when you switch DNS providers.
Most migrations only change the A, AAAA or CNAME records that point to the site, which keeps your email and other records untouched.
How do I test my site on the new host before going live?
Use the host's temporary URL or preview tool, or edit the hosts file on your computer so your domain points to the new server's IP address.
The change is local and reversible, and only you see it. Flush your DNS cache and restart your browser afterwards.
How do I roll back if something goes wrong?
In our judgment, keep the old host running and untouched until the new site has been stable for several days. If something breaks, point the DNS records back at the old server's IP address.
With a low TTL the change usually reaches visitors sooner, though the time depends on TTL and resolvers, and any orders or edits made on the new site in the meantime need to be copied back.
The Bottom Line
A zero-downtime switch is mostly about sequence: lower the TTL, build and preview the new site, get SSL ready, freeze edits, change only the records that must change, then wait before shutting anything down.
Do those in order and the cutover becomes the least dramatic part of the move.
Sources: Kinsta, "How DNS really works during a site migration" (kinsta.com/blog/dns-site-migration/) and Kinsta migration documentation (kinsta.com/docs/wordpress-hosting/wordpress-migrations/migrating-to-kinsta/), both read 26 October 2026. WP Engine support, "Emulate DNS Locally with the Hosts File Trick" (wpengine.com/support/emulate-dns-change-with-the-hosts-file-trick/), read 26 October 2026; the hosts-file locations are standard OS details, not from that page. The rollback timing, nameserver and MX advice are our own judgment.