Domain transfers and registrar migration, without downtime or losing the domain
Lesson 2 already established that a registrar and a DNS provider are genuinely separate relationships. This lesson covers the specific, real mechanics of changing the REGISTRAR itself — a less common operation than changing DNS providers, with its own real rules and real, avoidable ways to get it wrong.
Intermediate
3 min read
Why you'd transfer a domain to a different registrar at all
Moving a domain to a different registrar (cheaper renewal pricing, consolidating several domains under one account, better security features like hardware-key-backed 2FA) doesn't require touching the domain's actual DNS configuration or nameservers at all if you don't want to — the registration and the DNS authority are, per lesson 2, genuinely separate, and a transfer only changes who you renew the registration through, not necessarily where DNS is managed.
The actual mechanics: an EPP/auth code is the real key
1. Unlock the domain at the CURRENT registrar (domains are
often locked by default, specifically to prevent unauthorized
transfers)
2. Request the domain's AUTH CODE (also called an EPP code) from
the current registrar
3. Initiate the transfer at the NEW registrar, providing that
auth code
4. The current registrar must approve (or the transfer auto-
completes after a waiting period if they don't respond)
The auth code (EPP code) is a secret string only the current registrar can provide, acting as proof you actually control the domain and genuinely intend the transfer — without it, a transfer request simply can't proceed, which is a deliberate anti-hijacking safeguard, not an arbitrary bureaucratic step.
The 60-day lock: a real, common surprise
Most registries (per ICANN policy) impose a 60-day lock on a domain after it's registered or after it's transferred — during this window, it generally cannot be transferred to yet another registrar again. A team that just registered a domain, then immediately wants to move it somewhere else, often discovers this lock the hard way; the practical fix is simply waiting out the window, since there's no legitimate way around it.
Does a transfer cause any downtime for the live site or email?
A domain transfer, done correctly, changes who bills you for registration — it does not, by itself, touch nameservers, DNS records, or anything actually serving traffic, as long as nameservers are left pointing wherever they already were throughout the process. A site going down during a transfer is almost always a self-inflicted, separate mistake (someone also changed nameservers at the same time, for unrelated reasons) rather than something transferring itself causes — keeping the transfer and any DNS changes as two genuinely separate actions, not bundled together, is the practical way to avoid this.
Letting a domain lapse entirely: the real, permanent risk worth naming explicitly
Unlike a transfer (which keeps the domain under your control the whole time), failing to renew a domain at all eventually returns it to the public pool — after the grace and redemption periods lesson 1 named, anyone can register it. A domain that's core to a product's identity, its email, and every inbound link pointing at it lapsing is a genuinely severe, often difficult-to-reverse incident — auto-renewal, enabled deliberately rather than left to a default that might be off, is the real, practical defense against this specific failure mode.