Quick answer: Run old and new servers in parallel, lower DNS TTL to 300 seconds a day ahead, test the new site via hosts file, then cut over with a final delta sync inside a short write freeze at your quietest hour. The old server keeps serving until DNS moves — visitors never meet an empty server.
Overview
Downtime during migration is not caused by copying data — it is caused by switching before the copy is proven, or by DNS caching pointing users at a dead server. Both are preventable with sequencing: prove first, switch second, and never turn the old server off on migration day.
Before you start
- Both servers running in parallel with the site deployed on the new one.
- Analytics data identifying your lowest-traffic window.
- DNS access and TTL already lowered (see step 1 — this needs a day's head start).
Step-by-step guide
- 24+ hours ahead: lower the TTL of the A records you will change to 300 seconds. Old cached values expire before cutover.
- Prove the new site with a hosts-file test — pages, forms, admin, SSL.
- Schedule the cutover in the quiet window and freeze writes (content, orders, uploads) on the old site just before it.
- Final delta: rsync changed files and re-import changed database tables — with a prior full copy this takes minutes.
- Switch DNS and verify immediately with
dig +short example.comagainst a public resolver. - Keep the old server alive and monitor both access logs; traffic drains to the new server as caches expire.
Common issues
- TTL lowered too late: resolvers honor the OLD TTL until it expires — lowering it an hour before cutover does nothing for most visitors.
- Writes during the freeze that were not frozen: API clients and cron jobs do not read banners — stop services, not just human editing.
- Old server shut down same-day: stragglers on cached DNS get connection errors; keep it up several days.
When to contact support
If your site cannot tolerate even a short write freeze (busy stores, SaaS), describe the workload in a migration request — we will plan a staged cutover with you.
Frequently asked questions
What causes downtime during a hosting migration?
Almost always sequencing: switching DNS before the new server is proven, or shutting the old server down while cached DNS still points visitors at it. Both are avoidable.
How far ahead must I lower the DNS TTL?
At least one full old-TTL period before the cutover — in practice 24 hours. Resolvers honor the previous TTL until it expires, so a last-minute change has no effect.
Do I really need a write freeze for a small site?
If nothing writes to the site (no orders, comments or uploads), you can skip it. Any user-generated content means a short freeze during the final sync, or you risk losing it.
Related articles
- How to migrate WordPress without downtime
- How to migrate WooCommerce without losing orders
- How to test a website before the DNS switch
- How to roll back a migration
Ready to move? Order a VPS at Cloud2Y →
