DNS Migration Without Downtime: TTL, Order and Checks
How to move DNS records to a new provider without downtime: the right order of steps, when to lower the TTL and what to check after the switch.
rabbitclip teamPublished: 6 min read
Short answer
DNS migration means moving your domain's records (for the website, email and verification) from where you manage them now to another provider, and pointing the domain's nameservers at the new place. Doing it without downtime rests on three steps: first build every record in full at the new provider, lower the TTL (the time records stay cached) before the switch, and change the nameservers only once the records have been checked. The old set-up is left running until the change has finished spreading.
Domain transfer and DNS migration are often confused. A domain transfer changes the registrar, meaning the company where the domain is registered in your name; a DNS migration changes the servers where the records are managed. The two are independent, and either can be done without the other.
This article covers the order in which to migrate DNS, why the TTL matters, what to check afterwards and when the whole exercise is unnecessary. We have a separate guide to how DNS works in general; here we stay with the question of moving.
What is the difference between DNS migration and a domain transfer?
A domain is registered in your name with a registrar, while DNS is the set of records that tell the internet where the domain points. The records can be held at the registrar, at your hosting provider or at a separate DNS service. Your website may sit in one place, your mail in another and your DNS in a third.
So the answer to 'who manages my DNS?' is not always the company where the domain is registered. The way to find out is to look at the domain's nameservers (its NS records), which you can see with our domain and DNS lookup tool. If the registrar and the owner of the nameservers differ, you need to know which panel to log in to when you plan the move.
What is prepared before the move?
Preparation is the least exciting part of a migration and the most important. Take a complete inventory of the records at the old provider; a single forgotten record can turn into a mail or verification problem that goes unnoticed for months. Subdomains, email records and the verification records of third-party services are the ones most often missed.
At the same time, lower the TTL. The TTL sets how long other servers remember a record; a long TTL means a change spreads slowly. Bringing the TTL down to a short value a day or two before the switch narrows the window in which visitors still go to the wrong address.
- Take an inventory of every record at the old provider (screenshot or export)
- Check subdomains, mail (MX) records and verification (TXT) records separately
- Lower the TTL to a short value before the switch and wait for the old value to expire
- If DNSSEC is on for the domain, add it to the plan separately
- Prepare access, permissions and two-step verification at the new provider
What is the right order for a smooth switch?
Downtime comes from getting the order wrong. The right order is this: first create the zone for the domain at the new provider and enter every record exactly; then test that the new nameservers answer correctly by querying them directly; and only after that change the nameservers at the registrar to the new ones.
Changing nameservers before the records are ready is the commonest cause of downtime: the new server answers with an empty zone, and the site or the mail vanishes at once. The same error arises when the site's address is also changing, and two changes are piled onto the same day. If you can, split the DNS migration and the server move into separate days.
After the change, do not delete the zone at the old provider. The cache time of nameserver records is often the longest of all, and some visitors may still ask the old servers for anything from a few hours to a few days; as long as the old zone stays up with the right records, those visitors still reach the right place.
What do you check after the switch?
Checking does not end with seeing that the site opens. Test the site, the www address and the bare domain separately; test sending and receiving mail; and confirm that third-party services that need verification (a search engine tool, an advertising account, an email sending service) still show as verified. Trying from different networks and devices shows whether the change has really finished spreading.
After a few days the TTL is raised back to its normal level, and the zone at the old provider is closed only once everything has been seen to work. Keeping a record of the move helps too: when, who, which change. If a problem appears, that note makes the cause easier to find.
When is DNS migration unnecessary?
Not every change of provider calls for a DNS migration. If you are only moving the website to a new server, it is far simpler and less risky to leave DNS where it is and change only the address record for the site. If you are only changing your mail service, only the mail records are updated.
DNS migration makes sense in these cases: you are leaving the provider that manages your DNS, your current DNS service falls short (speed, management tools, security features), or you want to manage several domains from one place. Without such a reason, leaving it alone is often the safest choice.
What mistakes are common?
The costliest mistake is a missed record. The ones most often overlooked are mail and verification records; because the site appears to open, the problem goes unnoticed for days, and then sent mail bounces or a service loses its verification.
A second group of mistakes concerns timing and access. Frequent mistakes include these.
- Changing the nameservers before the records are fully built
- Lowering the TTL far too early, or not at all
- Leaving DNSSEC on without updating the related record at the new provider; the domain can stop resolving
- Deleting the zone at the old provider straight after the switch
Done in the right order, a DNS migration goes unnoticed: build the records at the new place first, lower the TTL beforehand, change the nameservers only after checking, and keep the old set-up alive for a while. Leaving DNS alone when there is no reason to move it is a perfectly valid decision too. If you would like to plan your switch together, rabbitclip would be glad to arrange a calm discovery conversation.
FAQ
What is TTL and why lower it before the switch?
TTL is the time a DNS record is kept in other servers' caches. If it is lowered beforehand, a change spreads sooner and the window in which visitors go to the old address is shorter.
Will my site be unreachable during a DNS migration?
Not usually, if it is done in the right order. The nameservers are changed after the records are fully built at the new place, and the old set-up is left running for a while. Downtime mostly comes from a missing record.
How long does a DNS migration take?
The work itself is short, but spreading can take anything from a few hours to two days. It varies with cache settings and networks, so it is sensible to repeat your checks a day later.
How do I find out who manages my DNS?
Look at the domain's nameserver (NS) records. They show the company running your DNS, which is often different from the company where you registered the domain. A domain lookup tool will show them.
