Migrate a Website Without Downtime
To migrate a website without downtime, keep the old host running, restore a full backup on the new server and test it privately through your hosts file, lower the A record TTL to 300 seconds a day ahead, sync recent data, then change the A record. Cancel the old host only after its logs show no real visitors.
For site owners and agencies moving a live website to a new host or server without visitors seeing errors.
knowledge
- Read time
- 5 min
- Sections
- 7
- Updated
- 14 Nov 2026
- Written by
- WebJi® team
Last editorial update: 14 November 2026. Prices follow the dated sources on this page; checkout confirms current charges.
What does migrating a website without downtime require?
Zero-downtime migration means both the old and new servers can serve the site while DNS caches update, so no visitor reaches a dead server. It rests on three rules: keep the old host running, test the new copy privately before DNS changes, and handle data written during the switch.
- Overlap: the old host stays online until resolvers stop handing out its IP.
- Private test: the new copy is checked through a hosts-file entry before the public switch.
- Fresh data: orders, comments or posts saved after the backup are re-copied or paused during the last sync.
- Small DNS change: move only the A record when only the website moves; changing nameservers also moves mail and every other record.
In what order should a zero-downtime migration happen?
Lower the TTL, back up, restore and test on the new host, sync recent data, switch the A record, then watch the old server's logs before cancelling. Stop at any failed check.
- At least one full old-TTL period before the switch, set the A record TTL to 300 seconds.
- Back up files and every database on the old host while it keeps serving visitors.
- Restore on the new host, match the PHP version, and put a working SSL certificate in place.
- Test privately through the hosts file: home page, an inner page, a form and a login.
- Copy anything saved since the backup, or pause writes briefly, then change the A record.
- Read the old server's access log over the next day; cancel only when real traffic has stopped.
How does DNS TTL decide the length of the switch?
TTL (time to live) is how many seconds a resolver may cache a DNS answer; lowering it to 300 seconds before the move means most visitors pick up the new IP within minutes of the change. The catch is that the old TTL must expire first.
| Change | Affects | Cache window |
|---|---|---|
| A / AAAA record | Website address only | The TTL in force before the change, then the new TTL |
| MX record | Where new email is delivered | Independent of the website records |
| Nameservers | Every record, via a new DNS host | Often hours; allow up to 48 hours |
A record set to 86400 seconds (24 hours) keeps being cached for up to a day after you lower it, so lower it a day ahead. Check what the world sees with dig +short A example.in @8.8.8.8, or the DNS propagation checker. Record types are explained in DNS records explained.
How do you copy and privately test the new server?
Restore a full account backup (files plus databases) on the new host, then add a hosts-file line mapping your domain to the new IP so only your computer sees the new copy.
# macOS / Linux: /etc/hosts Windows: C:\Windows\System32\drivers\etc\hosts
203.0.113.20 example.in www.example.inOpen a private window and check pages, images, forms and the admin login. Remove the line afterwards, or your computer will ignore the public DNS change. The editing steps for each OS are in how to edit the hosts file.
For SSL before DNS points to the new host, copy the existing certificate and key, or issue one through a DNS challenge; HTTP-challenge certificates such as AutoSSL usually issue only after the switch.
How do you avoid losing orders or posts made during the switch?
Choose one of three methods for data written after the backup: a short write freeze, a final database re-sync just before the DNS change, or proxying the old server to the new one during propagation.
| Method | How | Suits |
|---|---|---|
| Write freeze | Maintenance mode for checkout or comments for 10–30 minutes while the final dump is copied | Small shops and blogs |
| Final re-sync | Re-export and import the database, and re-run rsync, immediately before switching | Sites with modest write volume |
| Proxy old to new | After switching, configure the old web server to forward all requests to the new IP | Busy stores; stale-DNS visitors still write to the new database |
The proxy method needs root on the old server, for example an Nginx proxy_pass https://203.0.113.20; with the original Host header. On shared hosting, use the freeze or re-sync method.
How do you keep email working during a website move?
Email follows MX records, not the website's A record, so changing only the A record leaves mail exactly where it is. Move mail as a separate, later step if it is changing at all.
If mail is moving, create mailboxes on the new server first, copy messages over IMAP, then change MX and keep the old server accepting mail for a few days. If your mail is on Google Workspace or Microsoft 365, do not touch MX for a website move. Domain mail on WebJi® is covered by business email hosting.
When can you safely cancel the old host?
Cancel only when public DNS returns the new IP, the site loads normally without the hosts entry, a test email from outside arrives correctly, and the old server's log shows no real visitors for a day.
WebJi® runs approved moves onto a plan you have ordered: free migration is subject to terms and approval and is not instant, and a scoped one-domain move is ₹700 one-time before 18% GST. Start through the website migration service or email support@webji.services, answered 24/7 in Hindi and English. WordPress-specific hosting is on WordPress hosting.
Frequently asked questions
Is "zero downtime" really possible for every site?
For visitors reading pages, yes, because both servers serve the site during the overlap. Sites with constant writes, like busy shops, may need a short write freeze or a proxy step; reads stay available throughout.
Does a CDN like Cloudflare make migration easier?
Yes. With the CDN proxying traffic, you change the origin IP inside the CDN dashboard and the switch takes effect almost immediately, without waiting on visitors' DNS caches. Purge the CDN cache after switching.
Why does my site show the old version after switching DNS?
Your computer, router or ISP may still cache the old IP, or a hosts-file line is still present. Check with dig against a public resolver, remove hosts entries, and clear browser and CDN caches.
Should I change nameservers or just the A record?
Change just the A record when only the website moves; it is faster and leaves mail untouched. Change nameservers when you want the new host to manage all DNS, after recreating every record, including MX, SPF and DKIM, there first.
DNS behaviour per RFC 1035 TTL semantics · WebJi® migration terms as published · Reviewed by the WebJi® team, Jaipur.
Ready to get started with WebJi®?
Join 12,000+ businesses across India and overseas. INR pricing, 18% GST shown before payment and 24/7 email support in Hindi and English — average first reply under 60 minutes.