Advertisement
A website migration, new host, new server, sometimes a new stack entirely, gets framed as risky because the assumption is that there's a moment where the old site goes away and the new one isn't ready yet. There doesn't have to be. The actual technique for zero-downtime migration isn't exotic, it's sequencing: get the new server completely working first, verify it thoroughly while the old one is still live and serving real traffic, and only then make the switch, with a DNS TTL that was lowered well before any of this started.
Days before: lower the TTL
DNS records have a TTL (time to live) that tells resolvers how long to cache an answer. If a domain's A record has a TTL of 24 hours and you change it, some visitors will keep hitting the old server for up to a day. Lowering the TTL to something short, 300 seconds, a few days before the migration, gives that old, long TTL time to 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, which is the difference between "the switch takes effect in five minutes" and "the switch takes effect sometime in the next day, depending on the visitor."
Build and verify the new server completely, before touching DNS
This is the step that actually removes the risk, and it's also the one that gets rushed. The new server should have the application deployed, the database restored from a recent backup or, ideally, kept in sync via replication up to the cutover, and be fully testable, without DNS pointing at it yet. The way to test a server that isn't live yet is to override DNS resolution locally:
# /etc/hosts on your own machine
203.0.113.10 example.com
With that in place, visiting example.com in a browser hits the new server while everyone else still hits the old one. This is where you find the problems, a missing environment variable, a file upload path that wasn't migrated, a service that needs to be restarted, while there's no pressure and no visitors affected. If something's broken, fix it and test again. There's no rush, because nothing is live yet.
The database: the part that actually needs care
Static files and code can be copied ahead of time and re-synced right before cutover with something like rsync. The database is trickier because it keeps changing on the old server until the moment of cutover. The straightforward approach: take a final backup and restore it to the new server right at cutover time, accepting a short window (the time it takes to dump, transfer, and restore) where the site should ideally be read-only or briefly unavailable 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 sites where even a few minutes of read-only is unacceptable, database replication (setting the new server up as a replica of the old one ahead of time, then promoting it at cutover) closes that gap further, but for most small-to-medium sites, a few minutes of "the site works but new comments/orders are paused" during a planned, low-traffic window is a reasonable tradeoff against the complexity of setting up replication for a one-time migration.
The actual cutover
With the new server fully tested via /etc/hosts, the TTL already low, and a final database sync done, the DNS change itself is almost an anticlimax:
example.com. 300 IN A 198.51.100.20
Within the TTL window, traffic shifts to the new server. The old server stays running and untouched for a day or two afterward, both as a fallback if something unexpected surfaces under real traffic, and so any visitors still hitting it via a stale cached DNS answer aren't met with a dead server.
Why this works without special tools
None of this requires migration-specific software because the actual source of "downtime" in a rushed migration is doing the testing after the switch, finding problems while the new server is already the only one live. Reversing that order, fully ready and tested first, DNS change last, and a TTL that was already short by the time it mattered, is what makes the cutover itself close to a non-event. The preparation is the migration; the DNS change is just the last, smallest step.
Advertisement