How to Transfer a Domain Name Between Registrars Without Downtime

Unlock the domain at your current registrar, get the authorization code, start the transfer at the new one, approve the confirmation email, and wait up to five days. The site stays up throughout — unless your DNS was hosted by the registrar you are leaving.

The process is standardised by ICANN, so it works the same way regardless of who you are moving between. It is also slower than people expect and has two hard blockers that will stop it dead, both of which are worth checking before you begin rather than discovering three days in.

Table of contents

• Check eligibility first
• Move DNS before you move the domain
• The transfer itself
• When it fails, and what to do after
• How this fits the rest of the stack
• FAQ

Check eligibility first

Two ICANN rules block transfers outright, and neither can be waived by asking nicely.

• The 60-day rule after registration or transfer. A newly registered domain, or one transferred in the last sixty days, cannot be transferred again.
• The 60-day change-of-registrant lock. Updating the registrant name, organisation or email address triggers a sixty-day lock. This catches people constantly: they tidy up the contact details in preparation for moving, and lock themselves out of moving.

So if you intend to update contact details and transfer, transfer first, then update. Doing it the other way costs you two months.

Also confirm before starting:

1. The registrant email is one you can read. The approval email goes there, and there is no way to redirect it mid-process.
2. The domain is not expiring within a fortnight. Transfers near expiry are risky, and expired domains cannot transfer at all. Renew first if it is close — the year you pay for carries across.
3. There are no registry-level holds. A domain on a dispute or verification hold will not move until that is resolved.

One reassurance: transferring adds a year to the registration rather than resetting it, so paying the transfer fee is buying a renewal, not paying twice.

Move DNS before you move the domain

This is the step that turns a routine transfer into an outage, and it is missing from most instructions.

If your DNS records are hosted on the losing registrar’s nameservers, those records can disappear when the transfer completes — the registrar has no obligation to keep serving DNS for a domain that left. Your site goes down, your email stops, and you are rebuilding a zone file under pressure.

The safe order:

1. Set up DNS somewhere independent — a dedicated DNS provider, or your hosting platform’s nameservers. Somewhere that is not either registrar.
2. Recreate every record. Export the existing zone if you can. Do not rely on memory: the records people forget are MX and the TXT records for SPF, DKIM and DMARC, and forgetting those breaks email rather than the website, so nobody notices for a day.
3. Point the domain at the new nameservers and wait for propagation.
4. Verify everything works on the new DNS, with the domain still at the old registrar.
5. Only then start the transfer.

Done in that order, the transfer moves nothing but the billing relationship. The domain’s nameservers do not change, so no resolver anywhere notices.

Check the zone before you begin, and check it again afterwards:

dig example.com NS +short
dig example.com A +short
dig example.com MX +short
dig example.com TXT +short
dig _dmarc.example.com TXT +short

The transfer itself

1. Unlock the domain. In the current registrar’s control panel, find the domain and disable the registrar lock — it appears in WHOIS as clientTransferProhibited. This exists to prevent unauthorised transfers, so it is on by default.
2. Get the authorization code. Also called an auth code, EPP code, transfer key or Auth-Info code. Most registrars let you generate and view it in the control panel. If yours does not, request it — under ICANN rules the registrar must provide it within five calendar days.
3. Disable WHOIS privacy if required. Some registries cannot complete a transfer while contact details are masked. Re-enable it once the move is done.
4. Start the transfer at the new registrar, entering the domain and the auth code, and pay the transfer fee.
5. Approve the confirmation email. It goes to the registrant address. Ignoring it is the most common reason a transfer silently fails — an unanswered request eventually expires rather than proceeding.
6. Wait. The losing registrar has up to five days to release the domain. Many release sooner, and some offer an explicit approve button that skips the wait. Some will use the window to email you a retention offer; that is expected.

Watch WHOIS to see where it has got to:

whois example.com | grep -iE 'registrar|status|expiry'

A status of pendingTransfer means it is in the window. clientTransferProhibited still showing means the unlock did not take effect.

When it fails, and what to do after

The common rejection reasons and their fixes:

• Domain is locked — the unlock did not save, or was re-applied. Check WHOIS status rather than the control panel display.
• Invalid authorization code — codes can expire or be regenerated. Generate a fresh one and retry.
• Within 60 days of registration or a previous transfer — nothing to do but wait.
• Within 60 days of a registrant change — same.
• Confirmation email never approved — check spam, and check that the registrant address is one you actually monitor.
• Privacy protection blocking it — disable temporarily.

Once it completes, do the housekeeping straight away rather than adding it to a list:

1. Verify DNS still resolves correctly, including MX and the email authentication records.
2. Re-enable WHOIS privacy if you disabled it.
3. Re-lock the domain. Transfers usually leave it unlocked, and an unlocked domain is one an attacker with access to your email can move.
4. Turn on auto-renew at the new registrar. It does not carry across.
5. Confirm the expiry date includes the extra year you paid for.

The re-lock is the one that gets forgotten and matters most. Domain hijacking generally works through an unlocked domain and a compromised email account, so the lock is doing real work.

How this fits the rest of the stack

The lesson buried in all of this is that DNS and domain registration are separate things that people treat as one. Keeping DNS with a provider independent of your registrar makes transfers boring, which is exactly what you want from them.

Once DNS points somewhere sensible, the site behind it is the interesting part. On RunxBuild, attaching a custom domain to a static site or a web service issues and renews the certificate automatically, with redirects, rewrites and response headers as configuration rather than as server files to maintain. Static sites include 120GB of bandwidth, then $0.10/GB, and services in Node, Next.js, Python, Go, Ruby, Java, .NET or Docker deploy from your GitHub repository with build and runtime logs in one place and rollback to the previous deploy. Managed MySQL and Postgres sit behind them on private networking. To see what a site, a service and a database come to together, the RunxBuild hosting calculator lists them as separate line items.

Useful related references:

• Fully Qualified Domain Name: The Trailing Dot and Why It Matters
• Private Domain: Internal DNS, Public DNS, and When a Name Should Not Be on the Internet
• Free Domain Transfer: IONOS, Cloudflare, and the Right Steps
• Custom domains and certificates on RunxBuild

FAQ

How long does a domain transfer take?

Up to five days, because the losing registrar has that long to release the domain under ICANN rules. Many release sooner, and some provide an explicit approve action that completes it immediately. The domain keeps working throughout, provided its nameservers are not hosted by the registrar you are leaving.

Why can I not transfer my domain?

Most often one of the two sixty-day locks: one after registration or a previous transfer, and one after any change to the registrant name, organisation or email. The second catches people who tidy up contact details before moving. Transfer first, then update the details.

Will my website go down during the transfer?

Not if DNS is hosted independently of the registrar. If your records live on the losing registrar’s nameservers, they can stop being served when the domain leaves — taking the site and email with them. Move DNS to a separate provider and verify it works before starting the transfer.

What is an authorization code?

A per-domain secret that proves you control the registration — also called an auth code, EPP code or transfer key. Most registrars let you generate it in the control panel, and under ICANN rules they must provide it within five calendar days if you have to ask.

Do I lose the time left on my registration?

No. A transfer adds a year to the existing expiry rather than replacing it, so the transfer fee is effectively a renewal. Check the expiry date afterwards to confirm the year was added, and turn auto-renew back on since that setting does not carry across.