A cutover is not a switch. There is no instant when everyone moves to the new server, because caches expire at different times.
Once you plan for that window rather than for a moment, the downtime disappears.
Step one: lower the TTL, a day ahead
Set the records you will change to a TTL of 300 seconds, at least one full old-TTL period before the cutover.
Doing this at the moment of the change achieves nothing, caches holding the old value with the old TTL will not ask again until it expires. Understanding TTL walks through why this is the step people get wrong.
Step two: build and test before changing anything
Get the site fully working on the new server while the old one is still serving every visitor.
Test it by IP address, by a temporary hostname, or through a hosts-file entry on your own machine. What matters is that the site is confirmed working before any visitor is sent to it.
Check the specifics rather than just the homepage: a deep page, a form submission, the login, an image, and the certificate. Testing your website after migration covers the list.
Step three: get the certificate first
Issue a certificate for the domain on the new server before the cutover, not after.
If validation requires the domain to point at the new server, that is a genuine chicken-and-egg problem, and the answer is usually DNS-based validation, which works before any traffic moves.
Cutting over to a server without a valid certificate means every visitor gets a browser warning during the window, which is worse than the outage you were avoiding.
Step four: change the records
Change the A record, and the www record if it is separate.
Verify against the authoritative server immediately, then against public resolvers over the following minutes:
dig @ns1.example.com example.com A dig @1.1.1.1 example.com A +short
Using dig and nslookup deals with reading the results, and the answer you want from the second is the new address.
Step five: leave the old server running
This is the step that gets skipped and the one that causes outages.
For several days after the change, some visitors are still being directed to the old server: resolvers that ignore short TTLs, corporate networks with their own caches, machines that have not restarted.
Keep the old server serving. Ideally have it serve the same content, so a visitor reaching it sees a working site rather than an error.
Taking it down on cutover day converts a smooth transition into an outage for a shrinking but real fraction of your visitors.
Mail is the part people forget
If the MX record changes too, mail will be delivered to both servers during the overlap.
Anything landing on the old server sits in a mailbox nobody is watching, and decommissioning it deletes correspondence that arrived after the cutover, which is exactly the correspondence people will ask about later.
Before shutting the old server down, check every mailbox on it, or forward mail from the old server to the new one for the duration of the window. Migrating email to a new host walks through doing it properly.
Write during the window, carefully
If the site accepts data (orders, form submissions, registrations) then during the overlap some of it lands on each server.
The clean answer is to make the old server read-only for the window, or to point its database at the new one so there is a single place data goes.
The alternative is reconciling two databases afterwards, which is worse than it sounds. For a store, this is the deciding constraint on how the cutover is done at all. See migrating a WooCommerce store safely.
Afterwards
Once traffic has fully moved, check the old server's access log until it goes quiet: raise the TTL back to an hour or more.
Then decommission the old server deliberately: take a final backup, confirm mail was collected, and keep the backup for longer than you think you need it.
Test the new server before any DNS changes
You can reach the new server by name without changing anything, which turns the whole cutover from a hope into a verification.
curl -sI --resolve example.com:443:203.0.113.99 https://example.com/ | head -5 curl -s --resolve example.com:443:203.0.113.99 https://example.com/some/deep/page | head -20
That asks the new address for the site as if the DNS had already moved: certificate and all. For browser testing, the same effect comes from a hosts-file entry on your own machine.
Check more than the homepage: a deep page, a form, the login, and anything the application generates rather than serves as a file. A homepage that renders proves very little on its own.
Nameserver changes are slower than record changes
If the migration also moves DNS hosting, that is a different mechanism with a different timescale.
Changing an A record is governed by your TTL. Changing which nameservers a domain uses is governed by the parent zone, whose values you do not control and which are typically measured in days.
So a cutover that involves both is slower than the TTL suggests, and the two should not be done in the same hour. Move the records first, confirm everything works, and change nameservers as a separate operation afterwards. Changing nameservers sets out that half.
Have a way back
Before changing anything, write down the current records exactly as they are:
for t in A AAAA CNAME MX TXT NS; do echo "== $t"; dig example.com $t +short; done > /tmp/before.txt
Rolling back is putting the old A record back, and with a short TTL that takes effect within minutes. But only if you know what it was: reconstructing a zone from memory during a failed cutover is how a bad hour becomes a bad day.
Keep the old server running and unchanged so there is something to roll back to. A cutover where the old server was decommissioned the same morning has no reverse gear.
Watch both servers afterwards
tail -f ~/logs/example.com # on the new server tail -f ~/logs/example.com # on the old one
Traffic should appear on the new server immediately and taper off on the old one over the following days. Two things are worth watching for.
Errors on the new server that were not present in testing: usually a path, a permission or an integration that only real traffic exercises.
Traffic still arriving at the old server after a week. That means something is still resolving to it: a hard-coded address in an application, a monitoring check, or a second record you did not change. The old server's log tells you exactly what.
Only when that log goes quiet is the cutover genuinely finished, and only then is it safe to raise the TTL and decommission. Decommissioning a server safely explains the last step.