How to transfer a domain without downtime

TL;DR: A registrar transfer moves who bills you for the domain. It does not move your website, your email or your DNS. Done correctly it causes no downtime at all, because nothing about where your site is served changes.

Downtime happens when people conflate two separate operations: transferring the registrar and changing where DNS points. The second is the risky one, and the risk is almost entirely avoidable by lowering your TTL two days beforehand and replicating every DNS record at the destination before you switch anything. The record people forget is MX, which is why "the website moved fine but email stopped" is such a common outcome.

What a transfer actually moves

A registrar transfer changes which accredited company holds your domain registration. That is the entire scope.

What moves: the billing relationship, the management interface, and where renewals are processed.

What does not move: your website, which stays on whatever server it was on. Your email, which stays wherever it was hosted. Your DNS records, unless you deliberately change nameservers as part of the process. Your content, files or databases, none of which the registrar ever held.

This is why a correctly executed registrar transfer produces zero downtime. Nothing serving your site changes hands. The domain continues resolving through whatever nameservers it was already using, and visitors notice nothing.

The complication is that transfers are frequently done alongside a hosting move, and the hosting move is where downtime lives. Separating the two in your head is the single most useful thing in this guide.

If you can, separate them in time as well. Transfer the registrar, confirm everything is stable, then move hosting a week later. Two simple operations instead of one complicated one.

The three things people confuse

Untangling this prevents most transfer problems.

Registrar. The company you buy and renew the domain through. Holds the registration record and your contact details. Changing this is a transfer.

DNS host, or nameservers. The service answering queries about your domain: which IP serves the website, which server receives mail, what verification records exist. Often the registrar by default, but frequently a hosting provider or a separate DNS service.

Web host. The server actually running your website.

These three can be three different companies, and often are. A domain registered at one registrar, DNS managed at a CDN provider, and the site hosted somewhere else entirely is a perfectly normal arrangement.

The practical implication: changing your registrar does not require changing nameservers. You can transfer the domain and leave DNS exactly where it is, which is exactly what you should do if you are not also moving hosting.

Many registrars will offer to "set up DNS for you" during a transfer. Decline unless you have deliberately decided to move DNS, because accepting is how domains end up pointing at a parking page.

Before you start: eligibility

Four conditions to check before initiating anything.

Age and lock status. Domains are typically locked against transfer for 60 days after initial registration, after a previous transfer, and often after a change of registrant details. This cannot be waived. If you recently registered or updated the domain, you wait.

Registrar lock. A protective setting you control, on by default at most registrars. It must be off to transfer, and back on afterwards.

Registrant email access. The transfer authorisation goes to the registrant email address in the WHOIS record. If you cannot receive mail at that address, fix it before starting. Updating the registrant email may itself trigger a 60-day lock, which is why this must be checked early rather than discovered mid-process.

Expiry date. Do not transfer a domain in the last couple of weeks before expiry. Transfers take days, and a domain that expires mid-transfer creates a genuinely awkward situation. If expiry is close, renew first, then transfer afterwards.

Also check WHOIS privacy. Some registrars require it to be temporarily disabled to receive the authorisation email, and some transfer processes fail silently when privacy blocks the confirmation. Re-enable it once the transfer completes.

Preparing DNS two days out

This section only applies if you are also changing where DNS points. If you are transferring the registrar only, skip to the transfer sequence.

Lower your TTL. TTL, time to live, tells resolvers how long to cache a DNS record before checking again. Typical values are 3600 seconds or higher, meaning a change can take an hour or more to propagate, and stale caches can hold longer.

Two days before the switch, lower TTL on the records you will change to 300 seconds. Resolvers gradually pick up the shorter value, and when you make the actual change, propagation happens in minutes rather than hours.

This is the single most effective thing you can do to reduce DNS-related downtime, and it must be done in advance. Lowering TTL at the moment of the change achieves nothing, because resolvers are still holding the old long-cached value.

Export every existing record. Before touching anything, take a complete inventory: A records, AAAA, CNAME, MX, TXT, SRV, CAA. Screenshot the zone and save it as text. This is your reference and your rollback.

Replicate the full zone at the destination first. Create every record at the new DNS provider before switching nameservers. When the switch happens, the new provider answers immediately with a complete zone rather than a partial one.

Half-configured destination zones are the most common cause of transfer-day outages, and MX records are the most common omission.

Raise TTL again afterwards. Once everything is confirmed stable, put TTL back to 3600 or higher. Very short TTLs increase query volume and slightly increase lookup latency for visitors.

The transfer sequence

At the current registrar:

Disable registrar lock. Sometimes called transfer lock or domain lock, usually a single toggle in the domain settings.

Disable WHOIS privacy if your registrar requires it for the authorisation email to reach you.

Verify the registrant email is current and monitored.

Request the authorisation code. Also called an EPP code, auth code or transfer key. Some registrars display it immediately, others email it, and some impose a delay. Note it exactly, including case.

At the new registrar:

Initiate the transfer and enter the authorisation code. Pay the transfer fee, which typically includes a year added to the registration, so you are not losing paid time.

Approve the confirmation email. Sent to the registrant address. This is where transfers most often stall, because the email lands in spam or goes to an address nobody checks.

Watch for a rejection window. Some registrars send a notice allowing the current registrar to be told to release or hold the domain. Approving explicitly usually speeds completion considerably; ignoring it means waiting out the full automatic period.

Wait for completion. Typically five to seven days, sometimes faster if the losing registrar approves promptly.

Throughout: change nothing else. No nameserver changes, no contact updates, no hosting moves. A transfer in progress is a bad time to introduce variables, and some changes can cancel the transfer outright.

Timeline and what happens at each stage

Stage	Timing	What happens	Downtime risk
Lower TTL	Day -2	Resolvers begin caching for 5 minutes	None
Replicate DNS at destination	Day -1	Full zone created, not yet active	None
Unlock, get auth code	Day 0	Domain made transferable	None
Initiate at new registrar	Day 0	Transfer request submitted	None
Approve confirmation email	Day 0	Registrant authorises	None
Losing registrar release	Day 0 to 5	Explicit approval or automatic expiry	None
Transfer completes	Day 3 to 7	Registration moves, year added	None
Switch nameservers	After completion	DNS authority changes	Here, if zone incomplete
Propagation	5 to 60 minutes	Resolvers pick up new nameservers	Reduced by low TTL
Re-lock, restore privacy, raise TTL	Day +1	Protective settings restored	None

Note that every row before the nameserver switch carries no downtime risk. The registrar transfer itself is not a risky operation. This is why separating it from the hosting move is worth doing.

Moving hosting at the same time

If you are changing hosts as well, the order matters enormously.

Set the site up on the new host first. Copy files and database, get it running, and test it thoroughly before any DNS change. Most hosts provide a temporary URL or a hosts-file method for testing against the new server while the domain still points to the old one.

Verify on the new server properly. Homepage, interior pages, admin login, forms, and checkout for a store. Do not skip this on the assumption that a copy is a copy.

Do a final data sync immediately before switching. Anything written to the old site between your initial copy and the switch, new orders, comments, form submissions, needs bringing across. For a busy store, put the old site into maintenance mode for the final sync so nothing is written during the gap.

Then switch DNS, with the low TTL already in place from two days prior.

Keep the old hosting running for at least a week. During propagation some visitors still reach the old server, and if both are live, nobody sees an error. Cancelling the old plan on switch day is a mistake that turns a smooth migration into an outage for whoever has stale DNS.

That last point is worth the money. A week of overlapping hosting is cheap insurance against a category of problem that is otherwise unfixable in the moment.

If the new host offers free migration, use it. Most reputable Indian hosts include it, they do this constantly, and the sequencing is the part they are good at.

Email, and why it breaks

Email is where domain moves go wrong most often, and the reason is structural: people think about the website and forget that mail routing lives in the same DNS zone.

MX records determine which server receives mail for your domain. If you switch nameservers to a provider whose zone has no MX records, or has default ones pointing at their own mail service you do not use, incoming mail stops or bounces. Immediately, and silently from your side, because you simply stop receiving messages rather than seeing an error.

Copy MX records exactly, including priority values.

SPF, DKIM and DMARC are TXT records that authenticate your outgoing mail. Miss them and your mail starts landing in recipients' spam folders. This is worse than an outage in one respect: it is not obvious. You keep sending, everything looks normal, and delivery quietly degrades until a customer mentions they never received your invoice.

Verification TXT records for Google Workspace, Microsoft 365, and any service that verified domain ownership. Losing these can suspend the service.

Autodiscover and SRV records used by some mail clients for automatic configuration.

A practical rule for anyone using Google Workspace or Microsoft 365: your mail is not affected by a registrar transfer at all, and is only affected by a nameserver change. If you are moving DNS, copy every record from the current zone, then verify against your mail provider's published DNS requirements rather than trusting the copy.

Test after switching by sending mail to the domain from an external address, and sending from the domain to an external address, then checking headers for SPF and DKIM passes.

What to check afterwards

Within an hour of the nameserver switch:

The website loads on both www and the bare domain. HTTPS works and the certificate is valid; a new host may need to issue a fresh certificate, and this is a common transient failure. Interior pages, admin login, and a form submission all work.

Send a test email to the domain and confirm delivery. Send one from the domain and check it does not land in spam.

Within a day:

Confirm the domain shows in your account at the new registrar with the correct expiry, which should be a year further out than before.

Re-enable registrar lock. Re-enable WHOIS privacy. Raise TTL back to a normal value. Confirm auto-renew is enabled at the new registrar, since it does not carry across and this is a frequently missed step that surfaces a year later as an expired domain.

Check Search Console for crawl errors, and confirm your analytics is still recording.

Within a week:

Confirm mail deliverability has not degraded by checking a few sent messages. Then, and only then, cancel the old hosting.

Update your own records: where the domain is registered, where DNS is managed, where the site is hosted, and the renewal date. Keep it somewhere the whole team can find, because the person who did the transfer is not always the person handling the next incident.

FAQs

Does transferring a domain cause downtime?

Not by itself. A registrar transfer changes only who bills and manages the registration; your website, email and DNS records are unaffected and continue working throughout. Downtime occurs when a nameserver or hosting change is made at the same time, which is a separate operation people often conflate with the transfer.

How long does a domain transfer take?

Typically five to seven days, and faster if the losing registrar approves the release explicitly rather than letting the automatic period expire. The domain resolves normally throughout, so the duration is an administrative wait rather than an outage.

What is an EPP or authorisation code?

A unique code issued by your current registrar that proves you have the right to transfer the domain. You request it from the current registrar and provide it to the new one when initiating the transfer. Some registrars display it instantly, others email it or impose a short delay before releasing it.

Why can't I transfer my domain?

Most commonly a 60-day transfer lock, which typically applies after initial registration, after a previous transfer, and often after a change of registrant details. Other causes are registrar lock still enabled, WHOIS privacy blocking the authorisation email, an unreachable registrant email address, or a domain too close to its expiry date.

Do I lose the remaining time on my registration when I transfer?

No. A transfer normally adds a year to the existing expiry date rather than resetting it, so you keep the time you already paid for and gain another year for the transfer fee. Verify the expiry date at the new registrar after completion to confirm it applied.

Should I change nameservers before or after transferring?

After, and preferably not at the same time at all. Complete the registrar transfer, confirm everything is stable, then change nameservers a few days later if you are also moving DNS or hosting. Two simple operations in sequence are far easier to troubleshoot than one combined change.

What is TTL and why does it matter for transfers?

TTL is how long resolvers cache a DNS record before checking again. Lowering it to 300 seconds two days before a nameserver change means the switch propagates in minutes rather than hours. It must be lowered in advance, since resolvers are otherwise still holding the previous long-cached value at the moment you make the change.

Why did my email stop working after moving my domain?

Almost certainly missing MX records at the new DNS provider, since mail routing lives in the same DNS zone as your website records and is easy to overlook. Missing SPF, DKIM and DMARC TXT records cause a subtler problem where mail still sends but starts landing in spam. Replicate the complete zone before switching nameservers.

Do I need to move my website when I transfer my domain?

No. The registrar and the web host are separate relationships, and you can transfer the domain while leaving the site exactly where it is. Decline any offer from the new registrar to configure DNS for you unless you have specifically decided to move DNS as well, since accepting is how sites end up pointing at a parking page.

Can I transfer a domain that is about to expire?

You should renew first. Transfers take days, and a domain expiring mid-transfer creates a difficult situation with the transfer potentially failing and the domain entering the grace period. Renew, confirm the new expiry date, then transfer once the domain is comfortably clear of expiry.

Will transferring my domain affect SEO?

No, provided the site continues serving from the same place. A registrar transfer is invisible to search engines. What can affect SEO is downtime or a misconfigured DNS zone during an accompanying hosting move, which is why replicating records fully and keeping the old host running during propagation matters.

What should I do immediately after the transfer completes?

Re-enable registrar lock and WHOIS privacy, raise TTL back to a normal value, and confirm auto-renew is switched on at the new registrar, since it does not carry across and is the most commonly missed step. Then verify the site loads on both www and the bare domain, SSL is valid, and email sends and receives correctly.

Conclusion

The mental model is the whole thing. Registrar, DNS host and web host are three separate relationships, and a transfer touches only the first.

Move only the registrar and there is no downtime to manage. Move DNS or hosting as well and the risk is real, but it is concentrated in one moment and it is almost entirely mitigated by two habits: lowering TTL two days ahead, and replicating every record at the destination before switching anything.

MX records are the ones that get forgotten. If you take a single practical action from this, export your complete DNS zone before you touch anything and check the destination against it line by line, paying particular attention to mail records.

Keep the old hosting running for a week afterwards. During propagation some visitors still reach the old server, and having both live means nobody sees an error at all.

Then close the loop: re-lock the domain, restore privacy, raise TTL, and switch auto-renew back on. That last one is the most commonly missed step in the entire process, and it surfaces a year later as an expired domain nobody was warned about.

HostCloud handles domain transfers with transparent renewal pricing and free WHOIS privacy, and includes free website migration with the DNS sequencing managed by our team if you are moving hosting at the same time. Start at https://hostcloud.in.