Most migration outages are self-inflicted and follow the same pattern: the DNS is changed before the new site is ready, or the old site is deleted before the change has propagated. Doing it in the right order makes downtime effectively zero.
The principle
DNS changes do not take effect everywhere at once. For a period after a change, some visitors reach the new server and some still reach the old one. Your job is to make sure both are working during that window, which means the old site stays live and untouched until the new one has fully taken over.
The order that works
- Lower the TTL first. Several days before the move, reduce the time-to-live on the records you will change — typically to 300 seconds. TTL controls how long resolvers cache the old answer, and lowering it late does nothing, because the old, long TTL is already cached. This is the step people skip and then regret.
- Copy everything to the new server. Files and database. Take the copy at a moment you can identify, and note it.
- Test the new server before any DNS change. Override name resolution on your own machine using your hosts file so that only your computer sees the new server. Click through the site properly: forms, logins, checkout, image uploads. Do not skip this and do not test only the home page.
- Freeze changes on the old site. Announce a window during which nobody posts, orders or edits. Then take a final copy of anything that changed since step two — usually the database.
- Change the DNS. Either update the A record or switch nameservers. Switching nameservers moves every record at once, so make sure the new nameservers already hold your MX and TXT records or you will take email down along with the site.
- Watch both servers. Check the logs on both. When the old server stops receiving traffic, propagation is done.
- Wait, then decommission. Leave the old hosting in place for at least a week after traffic stops. It costs one more billing period and it is the only real safety net you have.
The things that catch people out
- Email. If MX records point at the old host's mail server and you switch nameservers, mail follows the website. Confirm the MX and any mail-related TXT records exist on the new nameservers before switching.
- SSL. Issue the certificate on the new server before the switch where possible. Otherwise the first visitors after propagation get a certificate warning.
- Hard-coded URLs. Content management systems store absolute URLs in the database. If the domain is changing as well as the host, those need rewriting.
- Cron jobs and scheduled tasks. They do not migrate with the files. List them before you move.
Ask us first
If the site takes payments, or if downtime has a real cost, open a ticket before you start rather than after something breaks. Tell us the domain, the current host and when you want to cut over.
