How to Transfer a Domain Without Website or Email Downtime

Transferring a domain should not normally interrupt its website or email. A registrar transfer changes who manages the registration. The live services continue to follow the authoritative nameservers and DNS records unless somebody also changes them.

Downtime happens when a transfer is combined with an unplanned DNS or hosting move, nameservers are replaced without a complete zone, the domain expires during the process, or an account or contact problem prevents a required approval.

This guide explains how to transfer a domain without downtime, including the preparation, transfer lock, auth code, DNS, email, verification and post-transfer steps. Rules vary by extension, so always check the policy for the actual domain.

Start a managed transfer

Visit the Hoster domain transfer page to begin or review a transfer. Have the exact domain, current registrar, expiry date and appropriate authorisation information ready. Never publish an auth code or send it through an ordinary support message.

First understand the four separate systems

Many failed moves begin because “the domain” is treated as one thing. In practice there are at least four layers:

1. Registry and registrar

The registry operates the top-level extension. The registrar or reseller provides the account used to register, renew, lock and transfer the domain.

2. Authoritative DNS

The nameservers publish DNS records. Those records decide where the website, email and other services are found.

3. Website hosting

The web server or platform stores and serves the site. It can stay with the old host after the registrar changes.

4. Email hosting

Mail servers, authentication records and user accounts handle email. They may be provided by a different company from both registrar and web host.

A registrar transfer can leave DNS, website and email unchanged. A hosting migration changes where the site runs. A DNS migration changes who publishes the zone. Plan each as a separate change unless there is a strong reason to combine them.

Why domains go offline during a transfer

Common causes include:

• the old provider disables DNS when the transfer starts or completes;
• new nameservers are set automatically but lack existing records;
• MX, SPF, DKIM, DMARC or verification records are omitted;
• the domain expires before the transfer finishes;
• the website is moved before it has been tested;
• DNSSEC remains configured with keys that no longer match;
• a provider-specific forwarding or hosted DNS feature is cancelled;
• an account change overwrites records with defaults.

Preventing downtime is mainly an inventory and sequencing problem.

Step 1: confirm ownership, contacts and expiry

Sign in to the current provider through a trusted bookmark. Confirm:

• the registered holder is correct;
• the administrative email works;
• the person initiating the move is authorised;
• the domain is not expired or in redemption;
• there is enough time before renewal;
• recent registrant changes have not triggered a policy lock;
• there is no dispute, court order or other restricted status.

Use a WHOIS or registration lookup for public status information, but remember that privacy rules may hide contact data. The registrar account is the appropriate source for full holder and operational details.

For ICANN-governed generic extensions such as .com, transfers can be restricted during the first 60 days after initial registration, during the first 60 days after a previous transfer, or after certain changes of registrant. The exact applicable policy and any opt-out depend on the circumstances and provider.

Step 2: inventory the current DNS zone

Record the authoritative nameservers and every relevant record before changing anything:

• A and AAAA records for websites and services;
• CNAME aliases;
• MX records for incoming mail;
• TXT records for SPF, DKIM, DMARC and verification;
• SRV records for communications platforms;
• CAA records controlling certificate authorities;
• DNSSEC state and DS records;
• subdomains used by applications, shops or remote access.

Take an export where the DNS provider supports it, but also review the live zone. Screenshots are useful evidence but not a machine-restorable backup. Some providers add hidden or managed records, so ask about services tied to the account.

Our DNS records guide for Irish business email explains the most common record types.

Step 3: keep nameservers unchanged during the registrar move

The lowest-risk approach is usually to transfer the registration while retaining the existing authoritative nameservers. The website and mail continue using the same DNS zone.

Before relying on that plan, confirm the old DNS service will remain active after the domain leaves. Some registrars include DNS only while the domain is held there. If it will stop, establish independent DNS first, copy and verify the zone, then transfer the registration as a later change.

Step 4: lower TTL only when a DNS change is planned

Time to Live tells recursive resolvers how long they may cache a DNS answer. Lowering TTL in advance can make a later record change converge more quickly. It does not accelerate the registrar transfer itself.

If nameservers and records will remain unchanged, there may be no reason to alter TTL. If a web hosting or DNS move is planned, lower appropriate records several days in advance, allow old caches to expire, and restore sensible values after the migration stabilises.

Step 5: check lock and transfer status

Generic domains often use a registrar transfer lock shown as clientTransferProhibited. ICANN requires registrars to provide a reasonable way for eligible holders to remove the lock or assist within the policy period.

Unlock only when ready to submit the transfer. Keep the registrar account protected with multi-factor authentication and monitor change notifications. A lock is an important anti-hijacking control, so re-enable it after completion.

Step 6: obtain and protect the auth code

The AuthInfo, EPP or authorisation code is a credential used for many registrar transfers. ICANN requires a unique per-domain AuthInfo code for relevant generic-domain transfers. The .IE registry also uses a unique auth code for transfer to a new billing contact or accredited registrar.

Treat the code like a temporary password:

• request it through the authenticated registrar account;
• do not paste it into chat, email threads or screenshots;
• give it only to the intended gaining provider through its secure form;
• replace or invalidate it if exposed;
• keep the domain locked except for the controlled transfer window.

For .ie domains, .IE states that the holder can request the auth code from the current registrar or directly from .IE; it is sent to the recorded registrant and administrative contacts. Our dedicated .ie transfer guide covers that process.

Step 7: place the transfer order with exact details

Enter the domain without a protocol, path or email prefix—for example, example.ie, not https://example.ie/shop. Verify the spelling before payment or submission.

Review:

• the transfer price;
• whether the extension adds or preserves registration time;
• the standard renewal price after transfer;
• the holder and contact information;
• the nameservers that will remain assigned;
• any email approval that will be required.

Do not assume every extension adds a year. Registry rules differ. Check the terms shown for the actual TLD and current registration state.

Step 8: approve legitimate transfer messages promptly

Depending on the extension and provider, the current or gaining registrar may send confirmation. Verify the domain, companies and requested action before approving. Do not follow an unexpected link merely because it mentions a real domain.

If a legitimate message does not arrive, check the registered contact, spam filtering and provider dashboard. Do not repeatedly start new transfers; identify the status of the existing request first.

Step 9: monitor without changing other systems

During the transfer:

• keep the existing DNS account active;
• do not cancel old hosting or email;
• watch the website from more than one network;
• send and receive test email;
• monitor transfer status and provider messages;
• avoid unrelated registrant, nameserver or DNSSEC changes;
• record times and actions for troubleshooting.

Changing one system at a time makes failures easier to isolate and reverse.

Step 10: verify the completed transfer

When the gaining registrar reports completion, confirm independently:

1. the domain appears in the correct account;
2. holder and contact information are accurate;
3. the authoritative nameservers are unchanged;
4. the website works over HTTPS;
5. incoming and outgoing email work;
6. SPF, DKIM and DMARC still resolve;
7. DNSSEC validates if enabled;
8. the expiry date and renewal settings are understood;
9. the transfer lock is restored;
10. MFA and recovery access are configured.

Do not cancel the old account until every unrelated service on it has been identified. It may still contain hosting, DNS, email, certificates or other domains.

If website hosting is also moving

Prepare the new site before DNS cutover. Copy files and databases, configure HTTPS, test forms and integrations, and use a hosts-file or preview method that does not expose an unfinished site.

Google recommends preparing the new infrastructure, changing DNS only after testing, monitoring both old and new hosting, and keeping the old infrastructure available until traffic has moved. If the visible URLs remain the same, this is a hosting change rather than a domain-name change.

For dynamic sites, plan the final data sync so orders, bookings, comments or enquiries created during migration are not lost. See our full hosting migration checklist.

If email hosting is also moving

Email migration needs its own plan:

1. create all mailboxes, aliases and groups at the new provider;
2. copy historic mail where required;
3. configure SPF, DKIM and DMARC;
4. lower relevant DNS TTL in advance;
5. change MX and related records in a controlled window;
6. keep the old system receiving during propagation;
7. test external inbound, outbound and replies;
8. reconfigure phones, computers and applications;
9. monitor bounces and forwarding.

Do not change MX records simply because the registrar changed. Registrar and email hosting are independent.

DNSSEC requires special care

DNSSEC creates a chain of trust between the registry and authoritative DNS. If the registry publishes a DS record that does not match the active DNS keys, validating resolvers may treat the domain as unavailable.

If nameservers stay with the same DNS provider, confirm the existing DNSSEC relationship remains intact. If DNS also moves, coordinate key creation, DS publication and old-key removal according to both providers' procedures. Do not guess or disable security casually; use a planned transition and validate it.

How long does a transfer take?

There is no single duration for every extension. Some transfers complete quickly after a valid code and approval; others have registry-defined waiting periods. Incorrect contacts, locks, expiry, disputes or invalid codes can delay the request.

.IE says a successfully completed registrar transfer is administratively passed automatically and becomes visible at the next .ie zone update, which occurs every two hours. Generic domains follow the applicable ICANN and registry procedures.

What to do when a transfer fails

Read the exact status rather than submitting again. Check:

• whether the auth code is current and copied exactly;
• whether the domain is still locked;
• whether a 60-day restriction applies;
• whether the approval email went to the right contact;
• whether the domain expired or changed status;
• whether the holder rejected the request;
• whether the extension requires another document or action.

A failed transfer does not normally require changing nameservers. Keep the live services stable while the registration issue is resolved.

Transfer-day checklist

• Domain and TLD are typed correctly.
• Current holder and email are accessible.
• Expiry and restriction status are checked.
• DNS zone is inventoried and exported.
• Old DNS will remain active.
• Website and mail baselines are recorded.
• Transfer lock is removed only when ready.
• Auth code is handled through secure forms.
• Approvals are monitored.
• No simultaneous nameserver change is planned.
• Post-transfer renewal and lock settings are reviewed.

Frequently asked questions

Will transferring my domain move my website?

No. A registrar transfer does not itself copy website files or databases. The website normally continues to use its existing host through DNS.

Will transferring my domain move my email?

No. Email stays with the current mail provider while MX and related DNS records remain unchanged and the provider account stays active.

Do I need to change nameservers?

Usually not for a registrar-only transfer. Keep them unchanged unless you have separately prepared and verified a DNS migration.

Can I transfer an expired domain?

It depends on the extension, registrar and lifecycle state. Renewal or restoration may be required first. Contact the current and gaining providers promptly.

Should I renew before transferring?

Avoid leaving a critical transfer until close to expiry. Whether to renew first depends on timing, extension rules and how registration time is handled. Get the provider's written guidance for that TLD.

Can anyone guarantee zero downtime?

No responsible provider can guarantee every external DNS, registry, hosting and email system. Careful separation, testing, overlap and monitoring make interruption much less likely.

Move the registration, not the outage

Start at Hoster's domain transfer page. For a domain with business-critical website, email or DNSSEC, contact Hoster before changing nameservers. Include the domain and current providers, but never include passwords, one-time codes or the transfer auth code in the initial message.

Official sources

• ICANN Transfer Policy
• ICANN transfer guidance for registrants
• .IE auth code and transfer guidance
• Google guidance for changing website hosting