"Migrating a domain" can mean a couple of different things, and they don't carry the same risks or timelines. This guide explains what actually happens, what visitors and email services might notice, and how to keep the disruption small - whether you're doing the move yourself or having someone do it for you.
The first is a registrar transfer: moving the domain's registration from one company to another - say, from GoDaddy to Cloudflare. This changes who you pay and manage the domain through. On its own, it doesn't move your website or email anywhere.
The second is a DNS change: pointing the domain at a new website host and/or a new email provider. This is the move that actually relocates your site and mail and it's where any downtime comes from. The domain registration can stay exactly where it is.
People often do both at once - "I'm switching everything to a new provider" - but it helps to think of them separately, because the registrar transfer is the slow-but-safe part and the DNS change is the fast-but-visible part.
To move a domain to a new registrar you'll usually need to unlock it at the current registrar, turn off WHOIS privacy long enough to receive a confirmation email, and copy an authorization code (also called an EPP or transfer code). You hand that code to the new registrar and approve the transfer.
From there, it's mostly waiting. ICANN, which sets the rules for most domain types, gives the losing registrar up to about five days to release the domain, so a transfer commonly takes five to seven days to finish. Domains can't be transferred within 60 days of being registered or of a previous transfer.
Throughout that wait, your website and email keep working. A registrar transfer doesn't touch your DNS - with one caveat: some registrars apply their own default nameservers when a domain lands with them, which would point the domain away from your current setup. If your new registrar does that, copy your existing DNS records over before the transfer completes, or set them right afterward.
This is done through DNS records - the settings that tell the internet where to find your site and where to deliver your mail. You either update individual records (an A or CNAME record for the website, MX records for email) or change the domain's nameservers so the whole zone is managed somewhere new.
Changes don't take effect everywhere at once. Networks around the world cache the old values for a period set by each record's TTL (time to live), so updates roll out gradually as those caches expire. This is "propagation," and it typically settles within a few hours, occasionally up to 24-48. If you can plan ahead, lowering each record's TTL a day or two before the move (to five minutes, say) makes the cutover much quicker.
The safest sequence is to have the new home fully ready - site live at the destination, email accounts created - before you change the record that points at it, so visitors and mail move to something that's already working.
For a website, downtime is usually brief or unnoticeable if the site is already serving at the new host before you flip the record. As caches expire, visitors move over a few at a time. The rough patch is when a record changes while the destination isn't ready yet - then some visitors get errors until it is.
Email is the part to be careful with. While MX records are propagating, some messages route to the old mail server and some to the new one, and anything sent to a server that no longer has your mailboxes can bounce or sit in a queue. Getting email fully working at the new provider before changing MX records - and keeping the old mailboxes alive for a few days after - avoids nearly all of that.
Set up your accounts, aliases, and any forwarding at the new provider first and confirm you can send and receive using its servers directly. Only then update the MX records at your DNS host.
Your deliverability records need to move too. SPF, DKIM, and DMARC are DNS entries that let receiving servers confirm your mail is really from you; if they still describe the old provider after a move, your outgoing messages are more likely to land in spam. The new provider will give you the exact values to publish.
For a day or two after the cutover, keep an eye on both the old and new inboxes so nothing sent during propagation gets missed.
When we move a domain for a client, we start by mapping the current setup - registrar, DNS host, website, and where email lives - to make sure nothing is lost in the move.
We schedule the switch for a low-traffic time, update records, and then verify the real thing: pages loading, forms submitting, and mail sending and receiving both ways. We re-add your SPF, DKIM, and DMARC records at the new host, watch propagation until it settles, and write up the final setup so there's a clear record of where everything lives. If something comes up afterward, we'll work with you to sort it out.