How Domain Transfers Actually Work (and How to Avoid Downtime)

Moving a domain to a new registrar sounds like the kind of thing that could break your website for a week. In practice, the mechanics are well-defined by ICANN policy, and a transfer done correctly causes zero downtime — because your site's DNS keeps resolving the entire time.

What a domain transfer actually changes

A transfer moves who your registrar of record is — the company that bills you and manages your registration — not your DNS records or your hosting. As long as your nameservers and DNS records aren't touched during the process, your site, email, and any other services keep working exactly as before, throughout the transfer.

The things you need before starting a transfer

• The domain unlocked at your current registrar (registrars apply a transfer lock by default; you'll toggle it off in your account settings there).
• An authorization code (also called an EPP code or auth code), which your current registrar provides on request.
• A domain that's at least 60 days past its initial registration or its last inter-registrar transfer — this is an ICANN policy requirement for gTLDs like .com, .net, and .org, and no registrar can waive it.
• Access to the registrant email on file, since the transfer confirmation is sent there.
• WHOIS privacy temporarily disabled if it would otherwise hide or filter that confirmation email.

Step-by-step: how the transfer actually happens

• You request the transfer at your new registrar and submit the authorization code.
• Your current registrar (or the registry) sends a transfer confirmation to the registrant email on file.
• You approve it — or, under ICANN policy, if neither side acts, the transfer auto-approves after 5 days.
• Registrar-of-record changes to the new registrar, typically within a few hours to a day once approved.
• Your nameservers and DNS records carry over unchanged unless you deliberately update them.

The ICANN 60-day rule, and what registrars actually control

ICANN requires a 60-day lock on transferring a domain to a new registrar, both right after initial registration and right after a completed inter-registrar transfer — this applies uniformly across every registrar for gTLDs, including .com, .net, and .org, and it can't be bypassed. What does vary a lot between registrars is everything else: how many extra hoops they make you jump through, how long they sit on an approval before releasing it, and whether the domain is fully active and manageable in your new account the moment the transfer clears, or lingers for days afterward due to slow internal processing.

Common transfer mistakes that do cause downtime

• Letting the domain expire before starting the transfer — start well before your renewal date, not after.
• Forgetting to disable WHOIS privacy when it's filtering out the confirmation email, stalling the whole process.
• Grabbing the auth code and then re-locking the domain before the new registrar has actually submitted the request.
• Changing nameservers and initiating the registrar transfer at the exact same time — stagger them so you can isolate which change caused an issue, if one comes up.

What to check before you hit "confirm transfer"

• Domain is unlocked at the current registrar.
• You have the authorization/EPP code in hand.
• It's been 60+ days since registration or the last transfer.
• The registrant contact email is current and you can access it.
• WHOIS privacy is temporarily off, if needed, to receive the approval email.

“A transfer only feels risky when you don't know which parts are actually ICANN's rules and which parts are just your current registrar being slow.”

Do the prep in the list above, and a domain transfer is one of the most boring, uneventful things you'll do to your website all year — exactly how it should be.