DNS Cutover Planning for Live Sites: Reduce Downtime When Moving to a New Host

DNS updates don’t usually take a site down on their own. Trouble starts when traffic shifts to a server that isn’t ready, or when users bounce between two environments that don’t share the same data. This guide covers DNS cutover planning for live sites so you can move to a new host with predictable behavior, minimal user-facing issues, and a rollback you can actually execute.

You’ll focus on three levers: reduce caching risk (TTL planning), run old and new in parallel (validation), and control writes (freeze or shared backend) during the cutover window.

What you’ll achieve (and what “downtime” means here)

During a host move, “downtime” usually looks like one of these:

• Hard downtime: visitors hit 5xx errors or time out because the new server can’t serve requests.
• Soft downtime: pages load, but logins break, carts reset, or form submissions vanish because traffic is split and data isn’t synced.
• Partial downtime: one region/ISP resolves the new IP while another still reaches the old host.

Your goal in 2026 isn’t “zero propagation” (it doesn’t exist). Aim for zero surprises: you know what will change, you can see it changing, and your app stays consistent while it does.

Prerequisites and tooling (15 minutes)

Before you touch DNS, collect the basics. If you’re hunting for credentials mid-cutover, you’re already behind.

• Domain access: permission to edit records at your DNS provider (or registrar DNS).
• Current DNS zone export (a text copy works).
• New host endpoint: a new IPv4 (and IPv6 if used), or a load balancer hostname.
• SSL plan: how TLS certs will be issued on the new host (ACME/Let’s Encrypt, existing cert import, or managed certs).
• CLI tools on your workstation: dig, curl, openssl, and optionally mtr.

If you’re moving to a VPS where you control the stack, build it early and test without a deadline. A Hostperl VPS works well for migrations because you can stage the new environment, keep the old host live, and switch DNS only after you’ve verified everything.

Step 1: Inventory your DNS records (and find hidden dependencies)

Start by capturing every record that affects web traffic and email delivery. Most “DNS cutover downtime” stories come down to missing TXT/CNAME records or a forgotten subdomain.

Checklist: records to capture

• A / AAAA: apex (@) and www, plus any app subdomains.
• CNAME: CDN endpoints, www aliasing, verification records.
• MX + mail A/AAAA: if you host email yourself or via a provider.
• TXT: SPF, DKIM, DMARC, Google/Microsoft verification, ACME challenges (sometimes).
• CAA: can block certificate issuance on the new host if not compatible.
• SRV: less common, but critical for some services (SIP, XMPP, etc.).

Email auth deserves extra care. If you change anything about mail routing, re-check SPF/DKIM/DMARC alignment. Hostperl’s cPanel walkthrough is a solid reference: How to Configure SPF, DKIM & DMARC in cPanel.

Quick command: confirm what the world sees

Query public resolvers (Cloudflare and Google are fine) so local caching doesn’t mislead you:

dig +short A example.com @1.1.1.1
dig +short A www.example.com @1.1.1.1
dig +short AAAA example.com @8.8.8.8

dig +short MX example.com @1.1.1.1

dig +short TXT example.com @1.1.1.1

Save the output with your migration notes. If you need to roll back, this is your “known good” reference.

Step 2: Decide your cutover strategy (A/AAAA switch vs. proxy vs. blue/green)

Pick a strategy based on how your site handles sessions and writes. The “right” choice is the one that matches your failure modes.

• Simple A/AAAA switch: best for mostly static sites, or apps that can tolerate a brief write freeze.
• Proxy cutover (Nginx/HAProxy): point DNS to a proxy first, then shift upstreams without additional DNS changes. This cuts down the uncertainty later.
• Blue/green with shared backend: old and new web nodes use the same database/cache; DNS only flips which web tier serves requests.

If the proxy pattern fits your setup, you can run Nginx in front of multiple upstreams. This Hostperl tutorial is a good starting point: Nginx Reverse Proxy Setup for Multiple Apps Debian 13.

Step 3: Lower TTL safely (without breaking your zone)

TTL planning is what makes a DNS cutover controllable. Lower caching time before you flip records so most resolvers re-check during your window.

What TTL values to use in 2026

• 48–72 hours before cutover: lower TTL for the records you’ll change to 300 seconds (5 minutes).
• Busy commerce/logins: consider 120 seconds if your DNS provider and traffic patterns tolerate it.
• Don’t set 0: many providers reject it, and some resolvers handle it poorly.

Only lower TTL on the records you’re actually switching (usually A/AAAA and sometimes www). Leave MX and long-lived TXT records alone unless you’re moving email.

Pitfall: the “negative cache” timer

If a resolver queries a record and gets NXDOMAIN, it can cache that absence. If you’re adding new records (like api), create them well ahead of time so you’re not fighting negative caching during launch.

Step 4: Build the new host so it can accept production traffic

DNS should be the final flip, not the moment you discover missing services. Make the new environment production-ready first.

Minimum production readiness checklist

• HTTP behavior: correct redirects (HTTP→HTTPS, apex↔www), no redirect loops.
• TLS: correct certificate chain, modern ciphers, HTTP/2 or HTTP/3 if you use it.
• App health: database connections, cache, background workers, cron jobs.
• Uploads and media: either migrated or stored on shared object storage.
• Email sending: if the app sends mail, ensure SMTP credentials work and DNS includes required SPF/DKIM.
• Observability: access logs, error logs, basic uptime checks.

If you’re moving a performance-sensitive WordPress site, validate caching and CDN behavior on the new server before you cut over. This guide helps you spot APAC-specific latency and edge cache quirks: Troubleshooting WordPress Performance Issues Unique to New Zealand Hosting.

Step 5: Test the new server with hosts-file overrides (no DNS changes yet)

A hosts-file override lets you browse the new host using the real production domain. That matters because many apps behave differently based on the Host header, cookies, and absolute URLs.

On macOS / Linux

sudo nano /etc/hosts

Add:

203.0.113.10   example.com
203.0.113.10   www.example.com

Then flush DNS cache:

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# systemd-resolved (many Linux distros)
sudo resolvectl flush-caches

On Windows

Edit C:\Windows\System32\drivers\etc\hosts as Administrator, then:

ipconfig /flushdns

Validate with curl and openssl

curl -I https://example.com
curl -I https://www.example.com

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject -dates

Confirm the certificate, status codes, and redirects match what you expect. If you still see the old certificate or old headers, you’re not reaching the new host yet.

Step 6: Plan for “split traffic” during propagation (sessions and writes)

Even with a low TTL, some users will land on the old host while others hit the new one. That overlap is where broken sessions and lost writes show up.

Pick one of these write strategies

• Short maintenance window: freeze writes (read-only mode) during a defined cutover period. Works well for WordPress/WooCommerce, CMS edits, and many small SaaS apps.
• Shared backend: point both environments at the same database and shared uploads (requires careful security and network rules).
• Replication + final sync: run database replication, then stop writes, promote, and switch. Common for MySQL/Postgres at larger scale.

If you choose a maintenance window, keep the message clear and the window tight. “Checkout disabled for 10 minutes” beats a cart that quietly fails for an hour.

Session storage: fix the classic login bug

If sessions live on disk and your two servers don’t share session storage, users can bounce between “logged in” and “logged out” while DNS settles. Common fixes:

• Central session store (Redis is common).
• Sticky sessions at a proxy (only applies if you have a proxy layer).
• Short cutover + forced re-login (often acceptable if you communicate it).

For Redis on Ubuntu, Hostperl’s setup guide is easy to adapt for sessions and caching: How to Configure Redis Cache on Ubuntu 24.04.

Step 7: Prepare monitoring that tells you when DNS is “mostly switched”

During cutover you need two answers, fast: who is still reaching the old host, and whether the new host stays healthy under real traffic.

Practical monitoring setup

• Enable distinct server headers so you can tell which host served a request.
• Watch access logs on both hosts for traffic shifting over time.
• Run external checks from 2–3 regions if you serve an international audience.

If you want something quick and self-hosted, deploy Uptime Kuma and add checks for the homepage, login, and a key API endpoint. Start here: Install and Configure Uptime Kuma on Debian 13.

Quick header trick (Nginx example)

Set a different header on each server so you can see where a request landed:

# /etc/nginx/conf.d/site.conf (or inside server block)
add_header X-Origin-Server "old-host" always;

And on the new host:

add_header X-Origin-Server "new-host" always;

Then:

curl -sI https://example.com | grep -i x-origin-server

Step 8: Execute the cutover (a safe, timed runbook)

Pick a window where you can watch the whole change end-to-end. For single-region traffic, that’s usually a low-traffic local period. For global traffic, choose a time your on-call team can actually respond.

Runbook: 30–60 minutes before switching DNS

1. Confirm TTL is already low (set 48–72 hours ago).
2. Re-test new host via hosts-file override or direct IP with Host header.
3. Warm caches (hit key pages, prime application cache if applicable).
4. Set your “write strategy”: maintenance mode or write freeze steps ready.
5. Capture a final backup/snapshot of database and uploads on the old host.

Runbook: the actual DNS change

1. Enable maintenance mode (optional but recommended) if your app cannot tolerate split writes.
2. Update A/AAAA records for @ and www (or update the CNAME target if that’s your pattern).
3. Verify authoritative DNS shows the new values immediately.
4. Validate from multiple resolvers until you see a majority return the new endpoint.

Commands to confirm the change

First, check the authoritative nameservers for your domain (replace with yours):

dig NS example.com +short

Then query each NS directly for the new record:

dig A example.com @ns1.yourdnsprovider.tld +short
dig A www.example.com @ns1.yourdnsprovider.tld +short

Finally, check common public resolvers to estimate propagation:

dig A example.com @1.1.1.1 +short
dig A example.com @8.8.8.8 +short
dig A example.com @9.9.9.9 +short

Step 9: Handle TLS during the cutover (avoid certificate surprises)

TLS is where migrations fail in subtle ways: everything looks fine from your desk, but specific clients break on chain issues or missing intermediates.

Three common TLS cases

• Let’s Encrypt HTTP-01: ensure port 80 routes correctly on the new host and that redirects don’t interfere with the challenge path.
• DNS-01 validation: safer during cutover because it doesn’t depend on HTTP routing, but you must be able to create TXT records quickly.
• Existing cert import: confirm you imported the full chain, not just the leaf certificate.

If you see handshake errors, fix them before you call the migration “done.” This Hostperl guide covers common causes and fixes: How to Fix SSL Handshake Failed Error.

Step 10: Post-cutover validation (what to check in the first 2 hours)

After DNS starts shifting, don’t shut down the old server right away. Keep it serving for at least the previous TTL window—often 24–48 hours—because some clients cling to stale answers longer than they should.

Validation checklist

• Homepage + key landing pages return 200 and correct content.
• Login flow works and stays stable across page loads.
• Checkout / form submits create real records in the database.
• Media uploads write to the correct location and are retrievable.
• Background jobs (queues, cron) are running on the new host only.
• Email from the app sends successfully (and SPF/DKIM align).

Spot stale traffic quickly

Use the custom header you added earlier:

for i in {1..10}; do curl -sI https://example.com | grep -i x-origin-server; sleep 2; done

If “old-host” keeps showing up frequently after your TTL window, you likely have additional records still pointing to the old endpoint (common with api, app, cdn), or you’re behind a proxy/CDN with its own origin configuration.

Step 11: Rollback plan (write it down before you need it)

A rollback is “just DNS” only if your data stayed consistent. The moment writes land in two places, rollbacks get messy.

Rollback rules that avoid data loss

• If you froze writes: rollback is usually safe—switch DNS back and re-open writes.
• If you allowed writes on the new host: rolling back may discard new orders, comments, or user actions unless you replicate data back.
• If you shared the database: rollback is mostly a web-tier switch; lower risk.

At minimum, take a database snapshot right before the cutover and right after you re-enable writes. That gives you a clean before/after boundary if you need to investigate.

Step 12: Restore TTL to normal and clean up old dependencies

After the new host proves stable, raise TTL back to a sane value. For most sites, 3600 seconds (1 hour) is a good baseline in 2026. If you deploy changes often, 900–1800 seconds is a reasonable middle ground.

Then clean up:

• Remove temporary hosts-file entries from your workstation.
• Turn off maintenance mode permanently.
• Verify cron/queue workers aren’t still running on the old host.
• Keep the old server reachable (but locked down) until you’re past your comfort window.

Practical notes for common scenarios

WordPress / WooCommerce

• Use a short maintenance window during the final DB sync.
• Make sure object cache/session behavior is consistent after cutover.
• Check payment webhooks: some gateways cache DNS aggressively, and some validate TLS fingerprints.

APAC audiences and region moves

If you move your origin closer to New Zealand or Australia, you’ll often see better TTFB and fewer long-tail latency spikes during peak ISP congestion. Region choice affects more than speed; it changes resolver paths and where your monitoring should run. Use this tutorial to plan the region side of the move: How to choose between New Zealand, Australia, and Singapore hosting regions for APAC customers.

Apps behind Nginx (multiple services)

If you serve multiple apps (for example, app.example.com, api.example.com, admin.example.com), list every hostname and cut each one over intentionally. A partial switch is a fast way to end up with mixed-origin CORS errors and broken OAuth callbacks.

FAQ: DNS cutover planning for live sites

How long does DNS propagation take in 2026?

It depends on TTL and resolver behavior. With TTL set to 300 seconds for 2–3 days before cutover, many clients refresh within minutes. Some networks and devices can still hold stale results longer, so keep the old host available for at least 24–48 hours.

Should I switch the apex record first or www first?

Switch both in the same change window if they point to different records. If www is a CNAME to the apex, switching the apex is often enough. Validate your redirect logic so you don’t create loops during split traffic.

Can I avoid DNS propagation issues entirely?

You can reduce them by cutting over to a stable proxy or load balancer hostname, then shifting upstreams behind it. DNS still exists, but you use it less often for origin moves.

What’s the safest way to prevent data loss during propagation?

Freeze writes during the cutover (maintenance mode) or run both old and new web nodes against the same backend for a short period. If neither is possible, use replication and a final sync step so you have a clear “stop writes → promote → switch” sequence.

When can I shut down the old host?

After you’ve seen near-zero requests in old-host access logs for at least one full business day, and you’ve completed post-cutover checks (payments, logins, uploads, email). If you’re risk-averse, keep the old host in a locked-down standby state for a week.

Summary: a low-drama cutover is a planned cutover

DNS cutovers stay calm when you lower TTL early, validate the new host using the real domain, and control writes during the overlap. Do those three things and “propagation” stops being a mystery and starts being a measurable, manageable transition.

If you’re moving a production site in 2026 and want a stable target platform, start with Hostperl VPS or step up to Hostperl dedicated servers for higher sustained traffic and tighter isolation.