What is DNS Cutover?

DNS cutover is changing a domain's DNS records—typically A, AAAA, or CNAME records—to point traffic from an old server to a new one. It's the final step in most website migrations, platform swaps, and CDN onboarding. The key variable is TTL (Time to Live): if your existing records have a TTL of 86400 seconds (24 hours), some resolvers will cache the old IP for up to a full day after you make the change. That's why pre-cutover TTL reduction is standard practice. I've done DNS cutovers on 50+ projects ranging from simple Vercel deployments to complex multi-region AWS setups with CloudFront distributions. A typical use case is migrating a client's marketing site from WordPress on shared hosting to a Next.js app on Vercel—where the cutover itself takes seconds but the DNS propagation window determines real downtime risk.

How it works

A DNS cutover follows a predictable sequence:

TTL reduction (48–72 hours before cutover): Lower the TTL on your existing DNS records to something short—300 seconds (5 minutes) is my default. This ensures that by the time you flip records, most resolvers worldwide have stopped caching the old value for long periods.
Validation on the new environment: Before touching DNS, confirm the new server responds correctly. Use curl -H "Host: example.com" https://<new-ip>/ or set up a /etc/hosts override to test the new destination with the real domain.
Record update: Change the A/AAAA/CNAME record at your DNS provider (Cloudflare, Route 53, etc.). For example:

# Using Cloudflare API to update an A record
curl -X PUT "https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_records/{record_id}" \
  -H "Authorization: Bearer {token}" \
  -H "Content-Type: application/json" \
  --data '{"type":"A","name":"example.com","content":"203.0.113.50","ttl":300,"proxied":false}'

Propagation monitoring: Use tools like dig, nslookup, or dnschecker.org to watch propagation across global resolvers. Most traffic shifts within minutes when TTL was pre-lowered. But some ISP resolvers (looking at you, certain Asian and South American ISPs) ignore TTL and cache for longer.
Post-cutover TTL restoration: Once confirmed stable (I usually wait 24–48 hours), raise the TTL back to 3600–86400 seconds to reduce lookup load.

The old server should stay live and serving valid responses throughout the propagation window. This is non-negotiable for zero-downtime cutovers.

When to use it

DNS cutover applies any time you're changing where a domain resolves. Specific scenarios:

Yes: Migrating hosting providers (e.g., moving from WP Engine to Vercel or Netlify)
Yes: Onboarding a CDN like Cloudflare or AWS CloudFront in front of your origin
Yes: Swapping staging and production environments (blue-green deployments at the DNS level)
Yes: Moving email providers when MX records are involved (though that's a separate concern from web traffic)
No: If you're deploying within the same platform (e.g., pushing a new build on Vercel)—the platform handles routing internally
No: If you control the load balancer or reverse proxy and can re-route at that layer instead—DNS cutover is slower and less controllable than an nginx/HAProxy swap
No: For A/B testing or gradual rollouts—use weighted routing (Route 53 weighted records or Cloudflare load balancing) instead of a hard cutover

DNS Cutover vs alternatives

Method	Granularity	Rollback speed	Downtime risk	Best for
DNS Cutover	Domain-level	Minutes to hours (TTL-dependent)	Low if TTL pre-lowered	Cross-provider migrations
Load balancer swap	Request-level	Seconds	Very low	Same-infrastructure deployments
Reverse proxy rewrite	Path/route-level	Seconds	Very low	Incremental/partial migrations
IP aliasing/failover	IP-level	Seconds	Very low	HA setups within one provider

DNS cutover is the bluntest instrument here. It's necessary when you're changing providers entirely, but if you can do the switch at a layer you control (proxy, LB), that's always preferable. The fundamental problem with DNS is that you don't control every resolver's caching behavior. My preferred approach for large sites: put Cloudflare in front first, then do the origin swap behind Cloudflare's proxy—so the DNS records never change from the public's perspective.

Real-world example

I migrated a B2B SaaS marketing site (~400 pages, 180k monthly visits) from a legacy WordPress instance on SiteGround to a Next.js 14 app on Vercel. DNS was managed in Cloudflare. Seventy-two hours before cutover, I dropped TTL from 3600 to 300 seconds. On cutover night, I updated the CNAME to point to cname.vercel-dns.com. Within 8 minutes, 95% of global resolvers returned the new record per dnschecker.org. I kept the old WordPress server running for 72 hours post-cutover as a safety net. Total observed downtime: zero. Lighthouse performance scores jumped from 38 to 94 after the migration, but that was the Next.js rewrite—not the DNS cutover itself. The cutover was the boring 30-second part of a 3-month project.

Frequently asked questions about DNS Cutover

Is DNS cutover the same as DNS propagation?

No. DNS cutover is the action you take—updating DNS records to point to a new destination. DNS propagation is what happens afterward: the time it takes for recursive resolvers worldwide to pick up the new record. Propagation time depends on the previous TTL value, resolver behavior, and caching policies. You control the cutover; you don't fully control propagation. That's why lowering TTL 48–72 hours in advance is critical—it shrinks the propagation window from potentially 24 hours down to minutes.

When did DNS cutover become standard practice for migrations?

DNS cutover has been the standard method for domain-level traffic redirection since the early days of the web, but the formalized best practices around TTL pre-reduction and parallel server operation became widely adopted in the mid-2000s as hosting migrations grew more common. The DNS protocol itself dates to RFC 1035 (1987). The modern practice of lowering TTL before a cutover became a commonly documented pattern around 2005–2008 as cloud hosting (AWS launched EC2 in 2006) made cross-provider migrations routine rather than rare.

What's the alternative to DNS cutover for site migrations?

The main alternative is performing the switch at a layer above DNS. If you already have a CDN or reverse proxy like Cloudflare, AWS CloudFront, or nginx in front of your origin, you can change the origin server at that layer without touching public DNS records. This gives you instant rollback capability (seconds vs. minutes-to-hours with DNS). Another option is using your DNS provider's weighted routing to gradually shift traffic—Route 53 and Cloudflare both support this. For same-provider moves, load balancer target group swaps are faster and more predictable.

How long does a DNS cutover take to complete?

The record update itself is nearly instant—typically under a minute at your DNS provider. The propagation phase depends entirely on the previous TTL. If you lowered TTL to 300 seconds 48+ hours in advance, most global resolvers will pick up the new record within 5–15 minutes. Without TTL pre-reduction, you could be waiting up to 24–48 hours for full propagation. Some ISP resolvers are known to ignore TTL values and cache longer regardless. In practice, on projects we've run, 95% of traffic shifts within 10 minutes when TTL was properly pre-lowered.