Domain Transfer Checklist: Requirements, Timelines, Fees, and Common Delays

Overview

If you need to transfer domain ownership from one registrar account to another registrar, most problems come from a small set of issues: the domain is locked, the contact email is outdated, the authorization code is missing or stale, the name was registered or changed too recently, or DNS was not reviewed before the move. None of these are unusual. What matters is catching them early.

This guide focuses on registrar-to-registrar transfers, not DNS-only changes and not website migration by itself. That distinction matters. You can point a domain to new web hosting or cloud hosting without changing registrars at all. Likewise, you can change DNS providers without moving domain registration. A transfer changes the registrar that manages the domain registration record. Everything attached to the domain—DNS management, email routing, SSL renewal workflows, billing, renewal terms, and account access—should be reviewed as part of that move.

For teams comparing providers before they start, it helps to review registrar differences in pricing, renewals, privacy, and DNS features first. A companion guide on best domain registrars compared can help frame those decisions before you request a transfer.

In practice, a good domain transfer checklist does four things:

• Confirms the domain is eligible to move.
• Protects live services such as websites, email, and verification records.
• Sets realistic expectations for domain transfer time.
• Documents registrar-specific friction points so the next transfer is faster.

That last point is often overlooked. If you manage a portfolio, this should become a tracker: what changed, when it changed, who approved it, and whether anything unexpected happened during the move.

What to track

Before you click any transfer button, collect the variables that commonly decide whether a transfer succeeds smoothly or stalls. Think of this as your recurring pre-transfer audit.

1. Transfer eligibility

Start with the domain's basic status. A domain may not be transferable if it is newly registered, recently transferred, in redemption, suspended, or subject to registry-level restrictions. Policies vary by extension, so avoid assumptions across all TLDs. The right question is not simply, “Can I transfer this domain?” but “Is this specific extension eligible to transfer right now under its current status?”

Track:

• Domain extension and registry rules.
• Current status codes in the registrar or WHOIS/RDAP view.
• Recent registration, transfer, or contact-change activity.
• Any dispute, hold, or compliance flags.

2. Registrar lock status

Many transfers fail at the simplest step: the domain is still locked. Most registrars call this transfer lock, registrar lock, or clientTransferProhibited. Unlocking does not always take effect instantly in every interface, so verify that the status has actually changed before moving on.

Track:

• Whether the domain is locked or unlocked.
• When the status was changed.
• Who changed it.
• Whether the updated status is visible in the control panel and public lookup tools.

3. Authorization code or EPP code

The EPP code is one of the core requirements for many domain transfers. Some registrars expose it instantly. Others send it by email or require an extra confirmation step. Because codes can be regenerated or invalidated, do not assume that the code saved in an old ticket or password vault is still valid.

Track:

• Date and time the code was requested.
• How the code was delivered.
• Who has access to it.
• Whether the code was tested or reissued.

4. Registrant and approval contact details

Transfer approvals often depend on email access. If the administrative or registrant contact is outdated, the transfer may be delayed by manual corrections. This becomes more common after staffing changes, acquisitions, or old agency-managed setups. For business domains, confirm that approval emails go to a controlled mailbox rather than a departed employee's inbox.

Track:

• Registrant contact email.
• Administrative or transfer approval email, if separate.
• Access to that mailbox.
• Any privacy or forwarding layer that could interfere with messages.

5. DNS configuration

A registrar transfer does not always change the nameservers, but this is where people get careless. Some teams discover too late that DNS was hosted by the old registrar and not documented anywhere else. If you move the domain and later change nameservers without a full export, records can be lost or recreated incorrectly.

Track:

• Current nameservers.
• Whether DNS is hosted at the registrar, a cloud DNS provider, or the hosting company.
• Full zone records: A, AAAA, CNAME, MX, TXT, SRV, CAA, and any other active entries.
• TTL settings for important records.
• Dependencies such as CDN verification, email authentication, and external services.

This is especially important for DNS management tied to production services. Export or manually document the entire zone before the transfer. Pay special attention to MX records and TXT records, since email routing, SPF, DKIM, DMARC, and service verification often break quietly.

6. Website and hosting dependencies

If the domain points to live web hosting, note what is actually attached to it. The transfer itself should not move site files, databases, or SSL material, but related changes often happen at the same time. That is where outages begin.

Track:

• Primary website destination.
• Whether the site runs on shared, VPS, managed, or cloud hosting.
• Any pending hosting migration.
• Existing SSL certificate issuance and renewal method.
• CDN, WAF, reverse proxy, or load balancer dependencies.

If your transfer is part of a larger move, it helps to separate “domain registrar change” from “hosting move” in your plan. If you are still deciding between hosting models, see Cloud Hosting Pricing Comparison: Shared vs VPS vs Managed Cloud Plans before stacking multiple infrastructure changes into one maintenance window.

7. Renewal date and billing impact

A domain transfer fee often includes a registration-year extension, but billing treatment varies by extension and provider. Avoid treating transfer cost, renewal date, and add-on pricing as obvious. Hidden surprises often come from renewal rates, domain privacy protection, and premium extension rules rather than from the transfer request itself.

Track:

• Current expiration date.
• Quoted transfer fee.
• Expected renewal treatment after transfer.
• Domain privacy protection pricing and defaults.
• Auto-renew status at both losing and gaining registrars.

8. Registrar-specific process steps

Not every registrar uses the same workflow. Some require separate approval at the old registrar and the new one. Some support transfer acceleration after approval. Others insert review delays or support steps for security reasons. Build your own notes as you go.

Track:

• The exact click path to unlock and request the code.
• Whether support intervention was required.
• Average response time for transfer-related tickets.
• Any extension-specific quirks.
• The point where the transfer status becomes visible.

Cadence and checkpoints

A useful transfer checklist is not just a list of requirements. It also tells you when to check them. For a one-off move, the cadence may be simple. For a team handling multiple domains or recurring migrations, this should become a repeatable schedule.

Checkpoint 1: One to two weeks before transfer

This is the planning phase. The goal is to confirm that the move is worth doing and that the domain is actually ready.

• Review why you want to transfer: price, support, account consolidation, security, DNS features, or operational control.
• Compare the destination registrar's renewal terms, privacy defaults, and DNS capabilities.
• Confirm the domain is eligible for transfer.
• Audit nameservers and export all DNS records.
• Verify access to approval email addresses.
• Record current expiry date and auto-renew settings.

If you manage domains across providers, this is a good monthly or quarterly review point even when no transfer is planned. Many transfer delays are discovered only because old admin contacts, stale billing methods, or inconsistent DNS ownership sit unnoticed for months.

Checkpoint 2: Two to three days before transfer

This is the execution-prep phase. You are reducing last-minute blockers.

• Unlock the domain.
• Request the EPP code.
• Confirm the code is current.
• Re-check contact email access.
• Take a fresh snapshot of DNS records.
• Note any critical services tied to the domain, including email and SSL validation.

If email is business-critical, review inbound and outbound mail flow separately. A website issue is visible quickly. Email misrouting can be missed for hours or days.

Checkpoint 3: Day of transfer request

Submit the transfer only after the prep list is complete. Then monitor approval and status transitions carefully.

• Initiate the transfer at the new registrar.
• Enter the EPP code carefully.
• Approve any confirmation emails promptly.
• Watch for status updates at both registrars.
• Document timestamps for request, approval, and visible progress.

This is where tracking domain transfer time becomes useful. Do not rely on vague memory later. Keep timestamps so your next transfer plan reflects real experience.

Checkpoint 4: During transfer window

Some transfers complete quickly; others sit in pending states. During this period, your job is to monitor, not to change unrelated settings unless necessary.

• Check whether nameservers remain unchanged.
• Confirm website uptime.
• Test email delivery.
• Monitor any registrar messages requesting action.
• Escalate only when the process has clearly stalled or an action is missing.

Checkpoint 5: After completion

The transfer is not done when the status says complete. It is done when operational control, billing, and DNS are verified.

• Confirm the domain appears in the correct account.
• Review nameservers, DNSSEC if applicable, and contact data.
• Check renewal settings and payment method.
• Verify privacy settings.
• Retest website, redirects, SSL issuance, and email.
• Store a brief transfer note for future reference.

How to interpret changes

Not every status change or delay means something is wrong. The practical skill is knowing which changes are normal and which need action.

Unlocked but still not transferable

If the domain shows unlocked but the transfer still cannot proceed, eligibility is the next suspect. Look for recent registration or transfer events, contact changes that triggered additional review, or extension-specific restrictions. Unlocking is necessary, but it is not the whole requirement set.

EPP code accepted, then transfer stalls

This often points to a pending approval, mismatched contact access, registrar-side review, or extension rules. It may also mean the losing registrar is waiting for a confirmation step that was missed. Compare the exact state at both registrars before changing anything else.

Website works, but email breaks after related DNS changes

This usually means the transfer itself was not the root cause; DNS changes around the transfer were. Recheck MX, SPF, DKIM, and DMARC entries first. In many environments, mail issues come from incomplete zone recreation rather than from registrar transfer mechanics.

Transfer completed, but SSL or validation fails

Review CAA, TXT, and validation records along with proxy or CDN settings. If certificate automation depends on DNS validation or the old provider's control panel, small record differences can delay issuance or renewal. This is common when teams bundle domain transfer, DNS migration, and hosting cutover into one project.

New registrar account is active, but team access is weak

This is a governance problem rather than a transfer problem. A move is a good time to standardize MFA, delegated roles, billing ownership, and break-glass access. For small business environments, this is often the real long-term value of the transfer: cleaner control of domain registration and fewer operational surprises later.

Fees seem low up front, but renewal risk increases

Interpret transfer promotions cautiously. The better comparison is total expected cost over time, not the first transaction alone. Review renewal pricing, privacy charges, DNS add-ons, and support quality together. A cheap first-year move may still be a poor fit for a high-value domain portfolio.

When to revisit

The best use of this article is not to read it once. Revisit it on a recurring schedule and every time one of the following conditions appears.

Revisit monthly or quarterly if you manage multiple domains

Use a simple tracker for each domain: registrar, expiration date, nameservers, DNS host, approval contact, lock status, and whether an EPP code can be retrieved easily. This makes future transfers faster and reduces the risk of emergency moves under time pressure.

Revisit before any registrar consolidation project

If you are combining domains under one provider for billing, access control, or DNS consistency, review the checklist before the first move and again after the first completion. The first transfer will usually expose a process issue worth fixing for the rest of the batch.

Revisit after staff or ownership changes

New administrators, acquisitions, contractor exits, and rebrands often leave domain contacts and approval paths outdated. These are exactly the moments when a transfer becomes urgent and unexpectedly difficult. Confirm who owns access before you need it.

Revisit when DNS or hosting architecture changes

A shift to new fast web hosting, managed DNS, a CDN, or a new email provider changes the risk profile around a transfer. Even if the registrar move is straightforward, the attached services may no longer be. Update the tracker before any major infrastructure change.

Revisit before renewal season for important domains

If a critical domain is approaching expiration, do not wait until the final days to decide whether to transfer domain to new registrar. Review timing, renewal terms, and support paths early. Domain transfers are easiest when they are planned, not rushed.

Practical next steps

For your next transfer, create a one-page record with these fields: domain name, extension, current registrar, target registrar, unlock status, EPP code requested date, approval email verified, DNS export completed, nameservers recorded, fee noted, expiration date noted, transfer submitted date, completion date, and post-transfer checks passed. That single document is often the difference between a clean move and a confusing one.

If you are still choosing a provider, compare registrar policies first and separate that decision from hosting. If hosting is also changing, plan it as a related but distinct project. A careful sequence—document, verify, transfer, confirm—will usually outperform a rushed all-at-once migration.

Used this way, a domain transfer checklist becomes more than a how-to article. It becomes a recurring operations tool for any team responsible for domains, DNS, and continuity.