DNS Cutover Checklist for Moving a WordPress Site Without Downtime

Migrating your WordPress site to a new host is a milestone for any site owner. However, the step where you update your DNS—the DNS cutover—is the moment that determines whether your migration goes smoothly or causes costly downtime. This DNS cutover checklist will walk you through every major decision and action point, helping you safeguard your site’s accessibility, SEO, and user reputation.

Why a Careful DNS Cutover Matters

Downtime and disruption harm your brand and user trust, and even temporary site inaccessibility can impact search rankings. Rushing DNS changes can mean visitors land on an outdated version, see errors, or encounter a broken site. You might lose email connectivity or see SSL errors if you miss a key DNS record. DNS changes themselves are subject to propagation delays, so a step-by-step DNS cutover checklist is vital for WordPress site migration.

Taking time to audit, test, and time your cutover reduces stress, supports thorough testing, and lets you monitor the switchover. In short, a well-planned DNS cutover is essential for a downtime-free WordPress hosting migration.

Pre-Migration: Audit Your Current Hosting and DNS Setup

Start with a clear picture of where your website “lives” and how traffic finds it. Auditing now avoids missed records and email outages during the switch.

1. Identify your domain registrar and active DNS provider. Is your DNS managed by your registrar or a third-party provider?
2. List every current DNS record in use for your site. Document A records, CNAMEs, MX for email, plus any relevant TXT/SPF/DKIM and subdomains.
3. See which services depend on DNS records beyond the site. Email, subdomains, analytics scripts, and security verifications all may need DNS continuity.
4. Use DNS tools such as your provider dashboard, whatsmydns.net, or command-line utilities like dig to copy your settings. Keep a copy as backup.

This careful audit supports a comprehensive DNS cutover checklist and avoids missing records—one of the most common causes of downtime.

Prepare and Test Your New WordPress Host Before Cutover

Never point DNS at a server you haven’t verified. Before you touch any DNS records, make sure your WordPress site is fully migrated and working on the new host.

• Migrate your files and database. Use a plugin, manual export, or your new host’s migration tool. Test login, pages, and images.
• Set up SSL certificates. Don’t assume these will carry over. If your site needs HTTPS, install and validate SSL on the new server now.
• Configure email (if handled by hosting). Some hosts include email services; others don’t. Make sure you know which MX and related records the new setup needs.
• Preview your new site prior to DNS cutover. Use a temporary “hosts file” edit on your PC or a staging domain if your host offers it.
• Check forms, e-commerce, and logins. Any integrations or membership features should work as expected.

If you’re not sure about managed WordPress features, read what managed WordPress hosting means and see if those features streamline the migration.

Lower DNS TTL Values 48 Hours Before Cutover

TTL—time to live—controls how long DNS resolvers cache your records. By default, TTL can be set for hours or even days. If the value is high, changes to your DNS can take a long time to reach users around the world.

Action: At least 24-48 hours in advance, lower the TTL for your main A record (and related records) to something short, such as 300 seconds (5 minutes).

• This ensures that, when you do make the final switch, your changes propagate quickly.
• Remember to reset the TTL back to a stable value after you’re confident in the cutover.

Most DNS providers let you update TTLs directly. Double-check and save changes.

Set Up New DNS Records Without Cutting Over the Main Domain

To maximize zero downtime, pre-create all necessary DNS records for your new host—but don’t change your live domain’s A record just yet.

• Point a testing subdomain (like staging.yourdomain.com) to your new server to confirm that DNS resolve works as expected with your new host.
• Add all important MX, TXT, or SRV records matching your old DNS settings, adjusting only for any change in IP or provider details.
• If you use a CDN or security service (like Cloudflare), integrate it in advance as well.

This step lets you safely verify email routing and third-party services before your users see any change.

Final Sync and Full-Site Testing

With your new WordPress host set up and DNS records prepared, do a last content and data sync. This minimizes lost comments, orders, or posts.

• Temporarily freeze site updates on the old environment during migration—for example, by scheduling the cutover at a planned maintenance window.
• Run through user journeys: page loads, forms, checkout (if e-commerce), and admin logins.
• Confirm SSL is active and all links redirect to HTTPS.
• Test from multiple devices and browsers for consistency.

By now, you’re following a nearly bulletproof WordPress DNS cutover checklist.

Schedule the Cutover for Low Traffic Times

Choose an off-peak hour for your actual DNS switch. Late night or weekend windows usually mean lighter traffic. Let your contributors, stakeholders, or team know about the scheduled window so they avoid key updates during this time. If you have your analytics data, compare which parts of the week are quietest for your audience.

For more guidance on migration and timing, see the hosting hub, which curates guides for stress-free moves.

Update Main DNS Records to Point to the New Host

When ready:

1. Update your domain’s A record to the new server IP address. Make sure this points to the new host.
2. Modify any CNAMEs, MX, or TXT records as needed for your new platform and ensure email routing is not interrupted.
3. Keep other services like analytics, verification, and CDN records up to date.

Because you lowered the TTL beforehand, global propagation should complete within minutes to a few hours rather than days.

Monitor Propagation and Site Availability

After updating your DNS, watch carefully for issues:

• Use whatsmydns.net or dig to check global DNS status.
• Test the site from several devices/networks. Confirm you’re seeing the new site.
• Confirm emails send/receive, forms, and login all work.
• Keep an eye on your error logs and analytics for unusual drop-offs or spikes.

If you need specialized hosting for larger content sites, you may want to review our Cloudways review, which discusses features for scaling safely.

Restore TTLs and Complete the Clean-Up

Once you’ve confirmed that site visitors around the world reach your new host—usually after 24-48 hours—it’s time to set your TTL values back up. TTLs between 1 to 4 hours (3600-14400 seconds) are typical. This reduces DNS lookup load on your provider and helps performance.

• Finalize any lingering DNS configuration (such as removing legacy staging subdomains or test entries).
• Close down your old hosting account only after you’re confident no legitimate traffic or service still depends on it.

Double-Check Email and Ancillary Services

Email downtime or loss is one of the most frustrating DNS migration errors. Double-check that your MX records and authentication records (SPF, DKIM, DMARC) point to the correct servers. If you changed hosting and DNS, ensure your mail provider—whether standalone or bundled—is current in your records. Test both inbound and outbound email after the migration, especially for contact or support addresses.

For broader comparisons of hosting setups and additional guidance, see our premium WordPress hosting comparison.

Common Pitfalls and How to Avoid Them

1. Long DNS Propagation Delays

Even with shortened TTL, some ISPs cache older records aggressively. Be transparent with your team and users that rare delays may occur up to 48 hours. Always check from multiple networks or use a mobile hotspot for quick double-checks.

2. Overlooked DNS Records

It’s easy to forget about secondary records like DKIM, email forwarding, or custom API subdomains. Your DNS cutover checklist should include each type of record in your initial audit.

3. SSL Certificate or Mixed Content Warnings

Not installing new SSL certificates on your new server is a classic cutover mistake. Confirm SSL before switching DNS, and check browser console logs for mixed content errors immediately after.

4. Missed Content Updates During Migration

If a user posts a comment or an order during your migration window, it could be lost. Either freeze user-generated updates or plan your cutover during periods of low engagement.

Conclusion: Managing Risk With a DNS Cutover Checklist

Migrating your WordPress site can be seamless when you lead with a checklist-driven approach. The DNS cutover checklist outlined above helps reduce downtime risk, supports full data integrity, and protects your SEO. By lowering TTLs before migration, testing your new environment thoroughly, and monitoring after cutover, you greatly increase your chances of a zero-downtime migration.

Remember, DNS cutover is as much about communication as technical controls. Keep your stakeholders aware, confirm every step, and don’t decommission your old infrastructure until the new setup proves stable for at least 48 hours.

Explore the hosting hub for additional upgrade advice, or learn how managed hosting options can further streamline your migration in our best WordPress hosting guide.

Frequently Asked Questions

How long does DNS propagation take during a WordPress migration?

DNS propagation typically takes from a few minutes up to 48 hours, depending on DNS TTL settings and how aggressively ISPs cache existing records. Lowering your TTL before cutover usually leads to faster propagation.

What if visitors see the old site after DNS changes?

This is commonly due to DNS caching at the user’s ISP or in their browser. Wait for full propagation, advise users to clear their browser and DNS cache, and check from different devices or mobile networks to validate the switch is complete.

Can I migrate WordPress without changing the domain’s DNS records?

You can test your WordPress migration using temporary URLs, test subdomains, or direct IP addresses, but your domain’s DNS must eventually point at the new host for a true cutover. Proper planning and a careful DNS cutover checklist ensure this happens seamlessly.