Advertisement
Migrating a website to a new host or a new server is often framed as a highly risky operation. People assume there is an inevitable gap where the old site goes offline and the new one isn't fully ready yet.
There doesn't have to be. The actual technique for a zero-downtime migration isn't exotic. It is entirely about sequencing: get the new server completely working first, verify it thoroughly while the old one is still serving real traffic, and only then make the cutover—with a DNS TTL that was significantly lowered days before you even started.
Days before: Lower the TTL
DNS records have a TTL (time to live) that tells local resolvers exactly how long to cache an answer. If a domain's A record has a TTL of 24 hours and you change the IP, some visitors will blindly keep hitting the old server for up to an entire day.
Lowering the TTL to something extremely short—like 300 seconds—a few days before the migration gives that old, stubborn TTL time to naturally expire everywhere first:
example.com. 300 IN A 203.0.113.10
By the time the actual cutover happens, every resolver's cached answer is at most five minutes old. That is the difference between "the switch takes effect in five minutes" and "the switch takes effect sometime tomorrow, maybe."
Build and verify the new server completely, before touching DNS
This is the step that actually removes the risk, and ironically, it is also the step that usually gets rushed. The new server should have the application fully deployed, the database restored from a recent backup, and be 100% testable—all without public DNS ever pointing at it.
The proper way to test a server that isn't live yet is to override DNS resolution locally on your own machine:
# /etc/hosts on your own machine
203.0.113.10 example.com
With that single line in place, visiting example.com in your browser hits the new server, while the rest of the world continues to hit the old one. This is exactly where you want to find the problems: a missing environment variable, a file upload path that wasn't migrated, or a background service that needs to be restarted. You find them while there is zero pressure and zero visitors affected. If something is broken, fix it and test again. There is no rush, because nothing is live yet.
The database: The part that actually needs care
Static files and application code can be copied ahead of time and re-synced right before the cutover with a simple rsync.
The database is trickier because it constantly changes on the old server right up until the exact moment of the cutover. The most straightforward approach: take a final backup and restore it to the new server right at cutover time. You accept a very short window (the time it takes to dump, transfer, and restore) where the site should ideally be forced into maintenance mode or made briefly read-only for writes specifically.
# On the old server, right before cutover
mysqldump --single-transaction myapp_db | gzip > final-dump.sql.gz
scp final-dump.sql.gz new-server:/tmp/
# On the new server
gunzip -c /tmp/final-dump.sql.gz | mysql myapp_db
For large sites where even a few minutes of read-only state is absolutely unacceptable, database replication (setting the new server up as a real-time replica of the old one ahead of time, then promoting it at cutover) closes that gap. But for most small-to-medium sites, a few minutes of "the site loads but new comments and orders are paused" during a planned, low-traffic maintenance window is an incredibly reasonable tradeoff against the massive complexity of configuring replication for a one-time move.
The actual cutover
With the new server thoroughly tested via /etc/hosts, the TTL already dropped to 300 seconds, and a final database sync completed, the actual DNS change is almost an anticlimax:
example.com. 300 IN A 198.51.100.20
Within the five-minute TTL window, global traffic smoothly shifts to the new server.
The old server stays running and completely untouched for a day or two afterward. It serves as an immediate fallback if something unexpected surfaces under real production traffic. It also ensures that any stray visitors still hitting it via a badly-behaved cached DNS answer are not met with a dead server.
Why this works without special tools
None of this requires expensive, migration-specific software. The actual source of "downtime" in a rushed migration is doing the testing after the DNS switch, finding critical problems while the new server is already the only one live.
Reversing that exact order—fully ready and tested first, DNS change last, and a TTL that was already shortened by the time it mattered—is exactly what makes the cutover itself a total non-event. The preparation is the migration. The DNS change is just the last, smallest step.
Advertisement