How to Move a Domain Between Registrars Safely
Moving a domain between registrars is a two-role operation that most people misunderstand as one. Understanding the split is what makes the process safe, because the risk is not that your site breaks — it is that you become unable to move the domain for two months.
Registrar and DNS provider are separate jobs
ICANN’s own material draws the distinction explicitly, listing “registrar,” “DNS hosts (that manage your DNS records)” and “web hosting” as three different roles a single company may fill.
This matters immediately, because of what it means for the risky part: your nameservers do not have to change. You can move the registration from one registrar to another while your DNS continues to be served by the same provider, unchanged.
ICANN’s guidance makes the point in a different way — noting that you “may also update your domain name’s nameservers or change the hosting IP address” as an alternative to a full inter-registrar transfer, which is only coherent if the two are independent.
So the honest version of “is my site at risk during a transfer?” is: not from the transfer itself. Record changes are a separate operation, and if you make none, there is nothing for a visitor to notice.
A caveat on citation: the role separation is documented, but ICANN does not publish a sentence reading “transfers do not change nameservers” that I could find. Use the roles to make the argument rather than attributing a quote that does not exist.
The locks that stop you
The single most useful thing to understand before you start is that a domain carries EPP status codes that can prohibit transfer outright.
RFC 5731 defines them, and the wording is absolute: for clientTransferProhibited and serverTransferProhibited, “Requests to transfer the object MUST be rejected.”
The two differ in who controls the lock. client* statuses are set by your registrar and can be changed on request. server* statuses are set at the registry and generally cannot.
Find out which one you have before you begin:
whois example.com | grep -i "status"
If you see clientTransferProhibited, ask your registrar to remove it. ICANN’s policy obliges them, on the registrant’s first request, to supply the auth code and remove the client transfer lock within five calendar days.
If you see serverTransferProhibited, the transfer is not available to you, and no amount of form-filling changes it.
Every documented reason a transfer gets denied
ICANN publishes the list of situations in which a registrar may deny an outbound transfer. Condensed:
- Evidence of fraud
- A pending UDRP proceeding
- A court order
- A reasonable dispute over the registrant’s identity
- The domain is on hold because the registrant has not paid
- The registrant has expressly objected in writing
- The domain is in a locked status
- Within 60 days of the domain’s initial registration
- Within 60 days of a previous transfer
Some of those are discretionary — a registrar may deny. Two categories are stronger: the policy specifies situations where a registrar must deny, including a pending UDRP or URS, a court order, a pending transfer dispute, and the registrant-change lock described in the previous article.
Read the list once and you can see the pattern: almost every denial is about identity, payment, legal status, or timing — not about the registrar being difficult. The timing rules are the ones that most often catch people, because they are invisible until you try.
The published framing is blunt: “You may not transfer your domain name to a new registrar within the first 60 days after initial registration, or the first 60 days after a transfer.”
The one that catches people who just bought a domain
If you registered a domain last month because a project was starting, and you now want to move it to a different registrar for cost reasons — you cannot, yet. The 60-day clock from initial registration has to run out first.
The same applies after a change of registrant. Update the owner name or company on a domain and the registrar must lock transfers for 60 days, with the only relief being an opt-out offered before the change is applied.
Practical sequencing follows directly:
If you need to consolidate a portfolio — transfer first, change registrant details second. Doing it in the other order puts a mandatory lock on the domain you were about to move. If the details genuinely must change first, take the opt-out when it is offered, and understand that you are accepting a period with reduced protection against unauthorised transfers.
The procedure, in order
- Confirm the domain is out of any 60-day window and that no
serverTransferProhibitedstatus is present. - Unlock the domain and obtain the auth/EPP code from the current registrar.
- Start the transfer at the gaining registrar, not the losing one. They will require the auth code and payment.
- Respond to the authorisation request. Note that the auth code alone is not the authorisation — the policy documents these as separate requirements, and a transfer that relies on the code alone will stall.
- Wait. The losing registrar has a window in which to respond, and there is a five-day waiting period in the standard process.
- Confirm the domain now shows the new registrar in
whois, and that your nameservers are unchanged.
That last verification is the one that matters. Check both — registrar and nameservers — because the transfer succeeded is not the same as your DNS survived.
The one thing not to do: let it expire mid-transfer
There is a documented failure mode that ends the attempt: the authorisation request becomes invalid if the domain expires before the transfer completes.
That is worth planning around, because a domain near expiry is exactly when people decide to move registrars. If the expiry date is within a few weeks, renew it first, at the current registrar, and move it afterwards.
Renewing first costs you nothing in the long run — the transfer itself extends the registration by a year, subject to a ten-year ceiling on the total unexpired term.
When to leave it alone
- The transfer is only about price. Do the three-year arithmetic first, including the year the transfer adds. The gap is often smaller than the effort, and at-cost registrars have narrowed it further.
- You are inside a 60-day window. Nothing to do but wait.
- Your DNS provider and registrar are now different companies after a merger. The roles are separate; you may not need to move anything.
- The domain is load-bearing for email. A transfer does not touch MX records, but if anything goes wrong during the process, the diagnosis is harder with mail in the path. Migrate on a quiet week.
Written by TestedHost. Every recommendation on this site comes from running the setup described, on a live deployment — not from a vendor spec sheet. Spotted something out of date? Tell us.