Avoiding downtime during migration

Why migrations go down

A website migration (new hosting, new server, new region) normally fails because one of three things changes at the same time:

• DNS moves the domain from the old host's IP to the new one, and propagation is not instant.
• The application changes (new server versions, moved files, a different PHP or node platform) while the domain still points at it.
• The cutover is done in one irreversible step, so any mistake means a down site for the whole audience, not just an hour.

The fix is the opposite: make DNS and the cutover separate, make the new environment identical, and keep a rollback path that works in minutes.

The pre-cutover checklist (do all of this before you point DNS)

• Build the new server as a clone: same PHP/node version, same modules, same config as the old one. A difference in one setting, such as a different upload_max_filesize or a missing mod_rewrite, surfaces later as a confusing bug.
• Copy files, then copy the database as a snapshot: a consistent mysqldump or pg_dump at a known point, not a live tail.
• Test the new environment by hostname, not through the domain: edit your local hosts file or use a staging URL so you see the new server while DNS still points at the old. Verify pages, forms, uploads, cron, email, and any payment webhook.
• Know your DNS TTL before the switch. The TTL tells you how long old resolvers will keep the old address. Set the TTL low (300 to 600 seconds) 24 to 48 hours before cutover if your provider allows, so propagation at swap time is minutes instead of a day.

The cutover

1. Point the DNS records you control (A/AAAA, any CNAME) at the new host.
2. Freeze writes on the old origin first. Do this before or at the moment of the flip, so no two databases both claim to be the truth. In practice: stop the old site from accepting new writes (maintenance mode, read-only DB user, or blocked outbound on the old host), export the final delta of anything written since the original snapshot, and import it into the new database.
3. Flip at a quiet time (check the access log for the busiest hours first).
4. Monitor both sides. With a short TTL most visitors follow within minutes; with a long TTL the old host must still serve the stragglers correctly.

What to monitor after

• Visit the site from a clean browser and from a browser with a stale cache.
• Check dig or nslookup against several public resolvers still returning the same IP, so you know propagation completed.
• Run the business checks again on the live host: core pages 200, forms send, no fatal, no mixed content.
• Watch the error log on the new host, not only the old one.
• Keep the old host running for at least the old TTL, ideally several days, so anything still resolving to it cannot hit a wall.

Rollback if things go wrong

• Keep the old host untouched; do not delete files or close the account for 7 to 14 days.
• If the new host has a fatal, flipping DNS back to the old IP restores service for everyone still on the old address, and the new resolvers follow. The wait is bounded by the new TTL.
• If the new server's application is broken but the old one was healthy, flipping DNS back is the fastest rollback. Do not fix the new server live during an outage; make it right on staging, then replay the cutover.

When the go-live window is shorter

The total downtime is the sum of the TTL you cannot reduce and the settings-change time. If the old and new hosts share the provider and the DNS record can change in seconds, the cutover is minutes. If a registry or nameserver change is involved, budget a day, not an hour. Reduce the risk in advance by lowering the TTL and doing the application swap first, then the domain flip.

Prevention

Migrations fail less often from the mechanics of clicking buttons and more often from unknown differences between the environments. The habit that prevents most downtime is the staging loop: the staging to live article describes the release drill, and the DNS TTL explanation quantifies the propagation side. Nothing in a migration beats testing the new host against a copy of the real data before an audience can feel a thing.