How to Transfer a Domain Without Taking Down Your Site

You can transfer a domain to a new registrar without your site going down for a minute — a registrar transfer changes who bills you, not where your site lives. Domain transfer downtime happens when DNS gets rebuilt mid-move. This guide covers the order of operations that keeps your site and email up the whole way through.

This guide focuses on the checks a small-site owner can make safely. It also points out where a host, registrar, email provider, or developer needs to take over. Read how to choose a web host if you need the broader setup, our domain transfer checklist for the pre-flight steps, and our migration guide before changing live infrastructure.

Before you transfer a domain, take an inventory

Make an inventory before you start: every DNS record on the domain, where email is hosted, subdomains, and any service that verifies you by TXT record. Export or screenshot the current zone — the list catches the small dependencies a transfer confirmation email cannot see.

Make a short note with account names, domain names, the expiry date, and the last known working state. Do not put passwords or recovery codes in the note. You want enough detail to retrace the work without creating a new security risk.

What a registrar transfer actually changes

A registrar transfer moves the domain's billing and management to a new company. It does not change your nameservers or your hosting — your site keeps resolving from the same DNS throughout. Downtime creeps in when the new registrar swaps in its own default nameservers during the move, so untick that option if it is offered.

If a DNS record does change, note the TTL and allow the old answer time to expire before assuming the change failed. Use a private browser window or a separate device after a change, so cached answers don't confuse the result.

Test the result like a visitor

Keep access to the old registrar account until the transfer completes and DNS has settled. The old login is cheap insurance for the short period when you may need to compare records or roll back a nameserver choice.

Test the normal path first, then the part that has the most consequence. For a store, that is checkout. For a form, it is receiving the email. For a domain move, it is mail continuing to arrive. A test should answer one question rather than produce a vague impression.

When to stop and ask for help

Stop when the next action could overwrite data, change production mail, or remove access to the account. Send support the domain, time in UTC, exact error, and the changes you made. Include a screenshot when it shows the error, but do not include private keys, passwords, or full payment information.

ICANN's registrant FAQ has useful background on your rights during a transfer: ICANN's registrant FAQ. Use it to understand the terms, then return to the small, reversible next step.

A sensible maintenance habit

Put the final configuration and the result in a short maintenance note. Domain problems repeat because nobody remembers which registrar owns which record or when the transfer lock re-engages. A dated note turns the next incident into a lookup instead of an investigation.

Keep the change auditable

Use a short before-and-after record. Write the setting you found, its old value, the exact time you changed it, and the result of the test. If the change has a delay, such as a DNS TTL, write the time you expect the new answer to be visible. This record is useful even when everything works. A few months later, it tells you why a setting has an unusual value.

Do not confuse an account dashboard with evidence from the live site. A dashboard can show that a transfer was accepted or a record saved. The visitor still needs to receive the page, email, redirect, or certificate you intended. Test from outside the account, and use a second connection if a cached answer could mislead you.

If you hand the task to someone else, give them the record rather than a conclusion. "The domain move broke something" is hard to investigate. "Mail stopped after the transfer completed, and the MX records at the new registrar differ from the export" gives the next person a useful starting point.

One last check

Before you close the ticket or move to the next task, load the site, send a test email to the domain, and confirm the DNS records at the new registrar match your export. If anything differs, note it and keep troubleshooting from that point. A quiet confirmation now is much easier than discovering the missed record during a launch or an outage.

Leave a useful handoff

Save the final test result with the date and both registrar accounts involved. If someone else needs to revisit the work, they should be able to see what changed without reconstructing the whole transfer from browser history.

Bottom line

To transfer a domain without downtime, export the DNS zone first, keep the existing nameservers through the move, and confirm the records afterward against your copy. Keep evidence, keep the old registrar login until things settle, and ask support before a routine step turns into an outage.

Frequently asked questions

Do I need to move DNS and hosting at the same time as the transfer?

No. Change one thing at a time — transfer the domain first with nameservers untouched, test, and only move DNS or hosting later once the transfer is stable.

What information should I give support if a domain transfer stalls?

Give the domain, both registrars involved, UTC time, the exact status or error text, and steps already tried. That is usually enough for support to find where the transfer is stuck.

Should I back up my DNS records before a registrar transfer?

Yes. Export or screenshot every DNS record before you start, so you can verify the zone afterward and restore it if anything is dropped in the move.