Moving a domain does not require moving the website, DNS, or email at the same time. This playbook shows how to transfer a domain to a new registrar while keeping authoritative DNS in place, estimating the work and timing, preparing an EPP/auth code request, and verifying every important service after completion.
Overview
A domain transfer changes the registrar responsible for managing the domain registration. It does not automatically migrate your web files, hosting account, DNS zone, mailboxes, SSL configuration, or applications. Keeping those services separate is the central technique for transferring a domain without downtime.
The safest workflow is to preserve the existing DNS provider and nameservers during the transfer. The website and email continue using the same DNS records while the registrar change proceeds in the background. You can change DNS hosting later, but combining both changes makes troubleshooting harder because a problem may come from the registrar, nameservers, records, hosting, or email provider.
Before starting, identify four parties:
- Current registrar: the company where the domain is registered now.
- New registrar: the company that will manage the registration after the transfer.
- DNS provider: the service hosting the authoritative zone, which may be either registrar.
- Service providers: your web host, email host, CDN, verification services, and other systems referenced by DNS.
Record these relationships before changing anything. If you are unsure where DNS is hosted, inspect the domain's nameservers and export or copy the current DNS records. A transfer should not be treated as a replacement for a website migration or a DNS migration.
How to estimate
Estimate a domain transfer using work, waiting time, and risk rather than a single promised completion date. The calendar estimate begins with preparation, adds any registrar or registry waiting period, and ends with verification.
Estimated transfer window = preparation time + provider-controlled transfer time + approval or exception time + verification time.
Preparation is usually under your control. It includes confirming account access, unlocking the domain if required, requesting the EPP/auth code, checking contact details, documenting DNS, and starting a backup. The provider-controlled portion depends on the domain extension, current registrar, new registrar, approval process, and whether the transfer is approved early or allowed to complete through the normal process. Check both registrars for the current estimate instead of relying on a generic timetable.
Use this planning table as a framework. Fill in the provider-specific values before scheduling a business-critical transfer:
| Stage | Input to record | Planning question |
|---|---|---|
| Preparation | Access, lock status, contact details, DNS export | Can the responsible administrator complete every task? |
| Authorization | EPP/auth code and approval method | Where will the code or approval message arrive? |
| Provider waiting period | Current estimate from both registrars | Is early approval available, or must the transfer wait? |
| Exceptions | Recent registration, transfer, or account changes | Could a restriction or review prevent the transfer? |
| Verification | DNS, website, email, SSL, renewal settings | Who will test each service and when? |
Do not use DNS TTL reduction as a substitute for registrar preparation. TTL affects how long resolvers may cache DNS answers; it does not accelerate the registrar's transfer process. If nameservers remain unchanged, a domain transfer normally does not require a new DNS propagation event. If you also plan to change nameservers, treat that as a separate migration with its own testing and rollback plan.
Inputs and assumptions
Gather the following inputs before you calculate a target date or begin the transfer:
- Domain status: confirm the domain is eligible for transfer and note whether it is locked.
- Account access: verify access to the current registrar, new registrar, DNS provider, web host, and email administration.
- Expiration date: leave enough time to resolve an unsuccessful transfer rather than waiting until the renewal deadline. See the domain expiration and renewal guide for a separate renewal workflow.
- Registrant and administrative email: confirm that approval messages can be received and are monitored.
- DNS zone: copy A, AAAA, CNAME, MX, TXT, and any relevant verification records. The DNS records troubleshooting guide explains what each record does.
- Service dependencies: list the website, email, redirects, subdomains, APIs, VPNs, analytics, payment callbacks, and certificate validation systems that depend on the domain.
- Rollback owner: name the person who can stop, investigate, or reverse a planned DNS change.
Assume that registrar interfaces, fees, transfer estimates, and eligibility rules can change. Confirm them directly in the relevant accounts before payment or submission. Do not assume that domain privacy settings, auto-renewal, DNS records, or custom nameservers will be copied exactly to the new registrar. Plan to review each setting manually.
EPP/auth code request template
Use this internal request when coordinating with a registrar administrator:
Subject: Request for EPP/auth code for [domain]
Please provide the current EPP/auth code for [domain] and confirm whether the domain is unlocked and eligible for transfer. Also confirm the expiration date, the approval contact or process, any applicable transfer restrictions, and whether current nameservers will remain unchanged during the transfer.
Store the code securely and share it only through an approved channel. An EPP/auth code authorizes a transfer; it does not transfer the website or email data.
Worked examples
Example 1: Registrar-only transfer
A company keeps its existing DNS provider, hosting account, and email provider. It documents the zone, confirms the domain is eligible, requests the code, submits the transfer, and monitors approval messages. Because the nameservers remain the same, the main operational tasks are registrar account setup and post-transfer verification. Its estimate should include preparation, the current registrar's stated transfer window, and a review period after completion. There is no reason to schedule a DNS propagation event solely because the registrar changed.
Example 2: Registrar and DNS move
A developer wants to transfer the domain and move DNS to a new provider. These are two separate projects. First, the developer creates the new DNS zone, copies records, validates the website and email targets, and lowers TTL only if appropriate for the planned nameserver change. After testing, the nameservers can be changed according to the DNS provider's instructions. The registrar transfer should be scheduled independently, with a longer contingency window because there are now two possible failure points.
Example 3: Transfer near renewal
A domain is close to renewal and the owner has not confirmed eligibility, account access, or the approval mailbox. The correct estimate is not simply the provider's advertised transfer time. First calculate the time needed to resolve access and eligibility questions, then compare it with the renewal deadline. If the margin is small, renewing or obtaining direct registrar guidance may be safer than relying on a transfer completing in time. Review the final renewal date and billing settings at the new registrar rather than assuming they match the old account.
Post-transfer verification checklist
- Confirm the domain appears in the new registrar account with the expected expiration and renewal settings.
- Confirm nameservers match the intended DNS provider.
- Resolve the apex domain and important subdomains from more than one network or resolver.
- Open the website over HTTPS and check redirects, login flows, forms, and critical transactions.
- Send and receive test email, then confirm MX, SPF, DKIM, and DMARC records remain correct. Use the domain email authentication guide for a deeper review.
- Check SSL certificate coverage, monitoring alerts, API callbacks, and third-party domain verification.
- Record the completed transfer, final settings, invoices, and the person responsible for renewal.
When to recalculate
Recalculate the schedule and cost whenever an input changes: the domain's expiration date, registrar pricing, transfer estimate, eligibility status, approval contact, DNS provider, hosting platform, or email provider. Revisit the plan before consolidating domains, after an acquisition, when changing a domain owner, or when an administrator leaves the organization.
Refresh registrar-specific instructions at least during your regular domain-management review and immediately after a major account-interface or policy change. Screenshots, API commands, fee notes, and transfer windows become stale faster than the underlying workflow, so verify them before publishing or executing a runbook.
For the lowest-risk execution, schedule the transfer during a staffed period, keep the existing hosting and DNS active, avoid unrelated DNS edits, and retain a rollback plan. If the project also includes moving hosts, use the website migration plan rather than treating the registrar transfer as a hosting migration. A documented checklist turns the process into a repeatable domain-management task instead of a one-time emergency.
