We're changing hosting: how long will the site be down? A server migration plan

When you move to a new server or hosting provider, the downtime your visitors experience has less to do with DNS "propagation" than with three decisions nobody made before cutover day: when the TTL was lowered, which machine owns writes while both servers are receiving traffic, and whether the certificate and email records are already in place at the moment you flip the record. Get those three right and the outage your users see is measured in seconds. Get them wrong and the site keeps looking fine while a slice of your orders piles up on the old box, which you usually discover two days later from a customer phone call rather than from a dashboard.

There is no propagation, only the TTL you published yesterday

A DNS change does not spread across the internet. Resolvers keep serving the answer they already have until its TTL expires, then they ask again. So the speed of your cutover is set by the record that was live before you touched anything, not by the new one. If your A record has a TTL of 86400, some visitors will keep hitting the old IP for 24 hours after the change and there is nothing you can do about it during that window. TTL belongs at the top of the migration plan, not at the end.

Google's guide on moving a site without URL changes recommends lowering the TTL "to a conservative low value (for example, a few hours)" and doing it "at least a week in advance." Two steps work well in practice: 3600 seconds a week out, 300 seconds 48 hours before cutover. Remember that the lowered TTL itself has to wait out the old one. A record published yesterday with a TTL of 86400 does not become a five-minute record just because you edited it this morning. Once the move is stable, put the TTL back up. A permanently tiny TTL means constant query load on your authoritative servers and no buffer at all when your DNS provider has a bad day.

Changing nameservers is much slower than changing an A record

The new hosting provider will usually ask you to point your nameservers at them. That single request turns a controllable cutover into a two-day unknown, because the TTL on delegation records is not yours to set. Ask a.gtld-servers.net today and the NS records in the .com zone come back with a TTL of 172800 seconds, two full days. You cannot drop that to 300.

The better sequence is to leave DNS where it is and change only the A and AAAA records at cutover. If the nameservers genuinely have to move, do it weeks earlier with identical zone data on both sides and keep the two providers in parallel for a while. Also budget for negative caching when you create new hostnames: a "does not exist" answer gets cached too. RFC 2308 notes that "values of one to three hours have been found to work well," while "values exceeding one day have been found to be problematic." That is why the new.company.com record you created an hour ago is invisible on some networks for the rest of the afternoon.

Behind a CDN or proxy, cutover stops being a DNS problem

If your traffic goes through something like Cloudflare, what visitors resolve is the proxy's anycast address, not your server's IP. Changing the origin is then a configuration change rather than a DNS change: the cached record stays the same, traffic lands on the new server within seconds, and if something breaks you roll back just as fast. Cloudflare's documentation notes that proxied records carry a fixed TTL of "Auto, which is set to 300 seconds" and cannot be edited.

Two conditions apply. The new server's firewall has to allow the proxy's IP ranges, or your cutover produces a wall of 5xx responses. And if the origin IP is still directly reachable, moving the proxy origin does not stop traffic that bypasses the proxy entirely; blocking direct-to-origin requests is a separate task worth doing before the move, not after.

Issue the certificate before the move, not after

The usual way to get a certificate on a new server, HTTP-01 validation, requires the domain to already point at that server. That creates a deadlock: you need DNS pointed at the new host to get a certificate, and you need a certificate before you can point DNS at it. DNS-01 validation breaks the loop. You prove control with a TXT record, install the certificate days ahead, and cut over without a single minute of untrusted TLS.

Skipping this is expensive. If you send HSTS, the browser will not offer a way past a certificate error. RFC 6797 is explicit that user agents "need to prevent users from clicking through security warnings." A few minutes of certificate warnings is a full outage on an HSTS site, not a cosmetic glitch. Two more checks before cutover: if the new provider uses a different certificate authority, confirm your CAA record actually authorizes it, and confirm renewal automation runs on the new host. Let's Encrypt is moving the default lifetime to 64 days on February 10, 2027 and recommends triggering renewal at roughly two thirds of the lifetime. Renewal scripts that were quietly hardcoded on the old box tend to go silent after a migration, and you find out about it a quarter later. We covered the wider shift in certificate lifetimes separately.

While the old TTL drains, both servers are live

The real risk in a migration is not downtime, it is a split. Until caches expire, some users reach the old server and some reach the new one. If both are writing to their own database, you end up with two versions of reality, and reconciling them afterwards costs more than redoing the whole migration.

Three approaches hold up. The simplest is a short write freeze: put the application in maintenance mode, run the final sync, flip the record. The second keeps the old application running but moves the database first, so the old server writes into the new database and nothing is lost whichever box a user lands on. The third turns the old server into a reverse proxy at cutover, forwarding every request to the new address, so a visitor with a stale cache still reaches the new application without knowing it. That third option gives you the most control and the least reconciliation work.

Whichever you pick, there is a list of things to stop on the old machine: scheduled jobs, queue workers, anything that sends email, webhook handlers. An invoicing job running on both servers issues the invoice twice, and the same reminder lands in the customer's inbox twice. File uploads are the quiet version of the same problem: without shared object storage, files uploaded during the window sit on the wrong disk. The database and schema side of this is the same discipline described in zero-downtime deployments and migrating data from a legacy system.

Email does not travel with hosting

Changing web servers does not change your MX record, but if your mailboxes live on the old provider's infrastructure, cancelling the hosting contract ends your email too. Treat email as its own line in the plan: where the mailboxes will live, whether MX changes, how existing archives get moved.

Application email is a separate question again. If the new server sends mail, your SPF record has to include the new IP or the new sending service, DKIM signing keys have to move with matching selector names, and DMARC alignment has to survive the change. We went through the mechanics of those records in the SPF, DKIM and DMARC guide. Sending from a brand new IP with no reputation history has a measurable effect on delivery, and it is one of the most common reasons password resets and order confirmations start landing in spam the week after a move. The structural fix, as covered in transactional email deliverability, is to send through a dedicated service rather than from whatever server happens to host the app.

Your old IP is written down in places you have forgotten

This is the line item that produces the most surprises. Over the years your server's IP address gets added to other people's allowlists: the bank's payment gateway, an e-invoicing provider, a logistics API, a customer's corporate firewall, a supplier's SFTP server, a VPN tunnel to a partner. For most of those parties, updating an IP means a form, an approval, and sometimes a week.

Inventory both directions at least two weeks before the date: who connects to you, and which outbound services authenticate you by source IP. Where possible, get both IPs allowlisted before the move so there is an overlap window instead of a hard switch. The circuit breaker and retry patterns from surviving third-party outages are what stop one missed allowlist entry from turning into lost orders while you wait for someone's change request.

Cutover day: order of operations and the rollback window

Cutover day does not reward improvisation. Write the steps down in order, with an owner and a success criterion next to each one. A sequence that works: take a backup and a snapshot, stop writes on the old server, run the final sync, test the new server through a hosts file entry using the real domain name, change the A record, verify from outside your network, switch the old server into proxy mode.

That hosts file test is the cheapest insurance in the whole plan. Without touching DNS, you point your own machine at the new IP and run the real flows: login, checkout, file upload, outbound email, search. The post-cutover verification list should be written the same way, before the day. If nobody is watching error rate and latency graphs, your customers will be the ones telling you whether the migration worked; teams with an SLO and error budget in place make that call in minutes. Your rollback window equals your TTL: with 300 seconds you can reverse a bad migration in five minutes, as long as the old server is still running and its data is still consistent. Prove your backups actually restore before the move rather than during it.

The old server's access log tells you when to switch it off

The migration is not finished when the record changes. Google's guidance is to keep the old provider running "until the traffic to the old provider reaches zero," which is a good practical test. Watch the access log on the old machine and you will see a tail that runs for days: corporate resolvers holding a long TTL, a partner who pinned the address in a hosts file, an integration with the old IP hardcoded. Shutting down before that log goes quiet means dropping that traffic silently.

The same guide carries a warning that gets ignored a lot: remove the temporary crawl blocks you put on the new server during testing. A robots.txt copied from staging, or a stray noindex left in the templates, is the best known reason for traffic collapsing the day after a move. Check that your Search Console verification file exists in the new copy as well. A temporary dip in Googlebot's crawl rate right after launch is normal and recovers over the following days. If URLs are changing too, the job is considerably larger, and we covered that case in protecting SEO during a redesign or migration.

What to do first this week

Three things can be checked today. Find the current TTL on your A record (dig +noall +answer company.com A takes a second), write down where your DNS is actually managed and who holds the nameservers, and start the list of external parties that may have your server's IP on file. Those three answers largely determine whether this migration is an evening of work or a two-week preparation.

If a move is coming up, send us your current DNS records, how certificates are managed today, and the list of integrations that connect in either direction. We will come back with a cutover sequence and a rollback window you can actually hold to.