How to Transfer Your Domain from GoDaddy (Step-by-Step)

If you want to move your domain away from GoDaddy without breaking email, killing SSL, or tanking your site for a day, read this. I’ll walk you through the exact operator playbook: what to prep, which toggles to change, where people get stuck, and how to finish the transfer in days - not weeks - with zero surprises.

There are plenty of good reasons to move registrars. Maybe your finance team wants predictable pricing without add-on upsells. Maybe your tech stack has evolved and you want registrar + DNS that match how you actually run infrastructure. Or you just want speed - fewer clicks, clearer logs, and sane defaults.

Another common reason: consolidation. If you own multiple brands, having everything in one registrar with clean permissions and 2FA reduces risk and saves time. A single source of truth for renewal dates, contacts, and DNS is underrated ops hygiene.

Finally, control. GoDaddy can be fine if you live in their ecosystem. If you don’t, you’ll do less context-switching with a registrar that gets out of your way. Decoupling registrar from DNS, or using a DNS provider with modern tooling, often unlocks faster deploys and safer changes.

A quick map so you don’t conflate roles. Your domain has three layers: the registry (e.g., Verisign for .com), the registrar (GoDaddy, Namecheap, Cloudflare Registrar, etc.), and DNS hosting (the nameservers that hold your zone file: A, CNAME, MX, TXT, etc.). Your website hosting is not your registrar by default, and email depends on DNS (MX records), not on who the registrar is.

When you transfer, you’re moving registrar sponsorship. The registry stays the same; your DNS does not have to change unless you want it to. Most generic TLDs (.com, .net, .org) follow the EPP/Auth-Code flow. You unlock the domain, get an authorization code from the losing registrar (GoDaddy), then initiate transfer at the gaining registrar. There’s an approval email step, a waiting window (usually up to 5–7 days), and then it completes with a one-year extension in most cases.

Key point: if your nameservers don’t change (e.g., your DNS stays with Cloudflare or another provider), the world won’t notice the registrar swap. Downtime happens when people mix up registrar moves with DNS or hosting changes - or forget TTLs and certs.

The safest transfers are boring because you prep well. Treat this like a small migration with a runbook, owners, and timestamps. The registrar move itself is simple; all risk lives in DNS and communications.

Use this pre-check to get to green:

• Confirm eligibility: no 60-day locks, domain is not expired or in redemption, WHOIS email is valid.
• Decide DNS scope: keep nameservers as-is, or migrate DNS separately later. Don’t combine registrar, DNS, and hosting changes in one window if you can avoid it.
• Snapshot DNS: export zone from current DNS host; note all records (A/AAAA, CNAME, MX, TXT for SPF/DKIM/DMARC, SRV for VoIP or M365, verification TXT for SaaS).
• Lower TTLs: if you plan any DNS change soon, drop TTLs to 300 seconds 24–48 hours before.
• Email continuity: confirm MX, SPF, DKIM, DMARC; get DKIM keys from providers like Google Workspace or Microsoft 365 and be ready to re-add if DNS moves.
• Access and roles: ensure you have 2FA recovery, billing permission, and the registrant email inbox access for approvals.

Two more notes. First, if you use GoDaddy’s hosted DNS (their nameservers) and you want to move DNS to a new provider, clone the entire zone and schedule that change after the registrar transfer completes. Second, if you use internal IT policies, line up a small maintenance window even if you expect zero downtime, just to keep comms clean.

Confirm eligibility: locks, contacts, and timing

Before you touch toggles, check these blockers:

• 60-day lock: ICANN policy applies after registration, transfer, or registrant-contact change. If you recently changed the registrant’s name, organization, or email, GoDaddy may have auto-locked the domain for 60 days.
• Status: domain must be in “OK” or “clientTransferProhibited” (lockable) state, not expired or in redemption. Renew first if close to expiration.
• WHOIS/Registrant email: you must receive approval emails. Validate that the registrant or admin contact email is accurate and reachable.

If you’re locked by a recent WHOIS change, you likely have to wait. Some exceptions exist but expect the 60 days. If the renew date is within a couple of weeks, renew now to avoid any edge-case downtime during the process.

Audit DNS and lower TTL

If your nameservers will stay the same, you can skip deep DNS prep. Still, grabbing an export of current records is free insurance. If you think you’ll change DNS in the next sprint, lower TTLs now. That way you avoid long propagation later.

For hosted email (Workspace, Microsoft 365), confirm MX priority and spam-control records (SPF, DKIM, DMARC). Screen-shot or export so you can re-create these in minutes if needed.

Set TTLs to 300 seconds (5 minutes) for critical records 24–48 hours before any potential DNS move. This shortens the blast radius if a mistake slips in.

Unlock the domain in GoDaddy

Log into GoDaddy, find the domain, and turn off the transfer lock. The status often reads “Domain lock ON.” Toggle it OFF. It may take a minute to propagate.

If you see extra layers like “transfer protection” or “2-step verification,” leave 2FA on your account but disable any product-specific “transfer shield” that blocks EPP retrieval. You can re-enable standard lock later at the new registrar.

Confirm the lock status in the domain overview. The domain’s ICANN status should reflect that transfers are allowed.

Turn off privacy and confirm registrant email

Many domains have WHOIS privacy. Temporarily disabling privacy lets the approval emails land at the actual registrant contact; sometimes privacy relays drop or delay them. You can re-enable privacy at the new registrar after completion.

Open your contact information and verify the registrant email address. If you must change it, know that this can trigger a 60-day lock under ICANN policy. Plan accordingly.

Some teams use a shared group inbox (like domains@yourcompany.com) with archive/retention and 2FA. If you don’t have this, now is a good time to set it up.

Get the authorization (EPP) code

In GoDaddy’s domain settings, request the transfer authorization (EPP/Auth) code. You’ll get it in the registrant email or see it displayed once generated. Treat this like a password - don’t paste it in chat threads.

Codes often expire in a short window (e.g., 3–7 days). If the code times out before you start the transfer at your new registrar, just generate a new one.

Do not rotate the registrant email after you generate the code. Keep the identity stable through completion.

Start the transfer at your new registrar

At your gaining registrar, start a transfer-in and enter the domain and EPP code. You’ll pay for the transfer (which typically adds a 1-year extension to the registration term in most TLDs). Confirm contact details match your intent.

If your plan is to keep nameservers where they are, ensure the new registrar doesn’t try to auto-switch nameservers during checkout. Choose “keep existing nameservers.” This preserves DNS and avoids downtime.

Complete the order. You’ll receive confirmation and the transfer will move to “pending” with the registry.

Approve the transfer emails

Two emails commonly appear - one from the new registrar asking you to approve, and one from GoDaddy giving you a chance to cancel/deny. Approve at the new registrar, do nothing at GoDaddy unless they require explicit confirmation.

If you don’t see these emails within an hour, check spam, check the privacy relay, and confirm the WHOIS registrant address. If the relay is unreliable, temporarily disable WHOIS privacy and resend the messages.

Once approved, most .com/.net transfers complete in 1–5 days. Some registrars let you accelerate by “acknowledging” the transfer on the losing side; GoDaddy’s flows vary over time - if available, use it to speed up.

Monitor and verify on the new registrar

When the transfer completes, the domain shows up under your new registrar’s control. Immediately do three things: re-enable domain lock, re-enable WHOIS privacy if you want it, and confirm nameservers remain as intended.

Open your DNS provider and confirm no record drift. If you plan to migrate DNS providers, this is your green-light window (with TTLs already lowered). Make the nameserver change only after your zone is fully cloned and validated.

Finally, verify SSL on your site and email deliverability (SPF/DKIM/DMARC alignment). A quick outbound test to multiple inbox providers (Gmail, Outlook) catches misconfigurations early.

Registrar-only move (best case): if your DNS is already external (e.g., Cloudflare, Route 53, enterprise DNS), simply “keep existing nameservers” during the transfer. You change nothing in DNS, so there’s no user-visible impact.

DNS migration coupled with registrar move: split this into two controlled events. First, complete the registrar transfer with no DNS changes. Second, clone your DNS zone to the new provider, validate parity, lower TTLs, then update nameservers. This keeps rollback clean and limits your risk.

Remember that nameserver changes can take minutes to hours to propagate. With TTLs at 300 seconds and perfect zone parity, users shouldn’t notice. Without parity (missing MX, wrong A record, absent CNAME for www), they will. Double-check subdomains - marketing tools, ESPs, and SSO endpoints often hide in those.

Your inbox doesn’t live at the registrar. Email continuity depends on MX records and related TXT records (SPF, DKIM, DMARC) in DNS. If DNS stays put, your email keeps flowing. If DNS moves, you must re-create these records exactly.

For Google Workspace or Microsoft 365, verify you have current DKIM keys and admin access to re-enable DKIM after any DNS change. Also verify any vendor SPF flattening or include statements (e.g., include:spf.protection.outlook.com) remain identical.

Many SaaS logins use your domain for SSO/SAML endpoints or verification TXT records. Search your existing zone for TXT and CNAME records containing vendor names (HubSpot, Salesforce, Mailgun, SendGrid, etc.). Recreate them precisely to avoid broken integrations and sending reputation issues.

Registrar changes do not affect rankings. Google does not care which registrar you use. DNS changes only affect SEO if you cause crawl failures or prolonged downtime. Keep the site live, maintain redirects and SSL, and you’re safe.

Where teams get burned: they move DNS and forget apex/WWW parity, break a CDN, or drop their 301s. If you use a CDN or proxy (e.g., a performance/security layer), ensure the new DNS points at the correct proxied endpoints and that your SSL certificate is active in that layer.

If you’re also planning a content restructure or platform switch, manage that as a separate SEO project with URL mapping, redirects, and monitoring. If growth is your goal, prioritize clean technical hygiene and consistent publishing instead of risky one-shot “redesigns.” If you want a blueprint to win non-branded search, study our approach to organic visibility and build a safe migration plan around it.

Not every TLD behaves like .com. Many country-code domains have their own transfer mechanics, codes, and timing. Always check the gaining registrar’s documentation for your specific TLD.

Examples: .uk uses IPS tags, so you set the new registrar’s tag at the losing registrar. .nz historically used UDAI codes (similar to EPP). Some TLDs restrict transfers within certain windows from registration or owner change beyond the common 60 days.

Premium or reserved domains, and domains in redemption or with legal holds, have extra steps or waiting periods. Clear billing and compliance first to avoid partial transfers and confusing states.

Time: most generic TLDs complete within 1–5 days after you approve emails. If you don’t approve, the registry auto-approves after the standard window (often up to 7 days). You can sometimes accelerate by acknowledging at the losing registrar.

Cost: the transfer usually includes a 1-year registration extension for eligible TLDs. You pay the gaining registrar’s transfer fee. Budget it as a normal renewal plus a small admin overhead for the ops time.

After completion: immediately re-enable domain lock and WHOIS privacy (if desired), confirm nameservers, and update your internal asset inventory. Expect a 60-day transfer lock after completion before you can transfer again, depending on TLD policy.

Transferring a domain is easy if you keep DNS steady and double-check emails. It gets messy when you mix registrar, DNS, CDN, and platform changes in one sprint. If your brand runs revenue through that domain, treat it like production: change windows, rollbacks, and observability.

This is where an operator model shines. At Anton Chisliuk · AI Marketing Ops, one senior builder owns the plan, the toggles, and the outcomes - no account manager hop. We’ve shipped end-to-end marketing systems while keeping ops clean (e.g., taking a B2B SaaS from 0→80K organic visits/month and ~2K inbound leads/month without downtime). If you’re evaluating the model and want to see how we run migrations inside a broader growth plan, read the brief about page.

Whether you DIY or not, the pattern is the same: decouple changes, validate parity, and keep a rollback path. Most outages are self-inflicted by skipping those three.

Here are the traps that repeatedly bite teams - and the simple antidotes.

Trap: changing nameservers and registrar in one go. Fix: transfer registrar first, then migrate DNS with cloned zone and low TTLs.

Trap: forgetting email and sender-auth records. Fix: inventory MX, SPF, DKIM, DMARC, and ESP records before any DNS move. Test deliverability after.

Trap: registrant email can’t receive approvals (privacy relay, disabled inbox). Fix: disable WHOIS privacy temporarily, verify inbox access, resend approvals.

Trap: registrar auto-switches nameservers at checkout. Fix: explicitly choose “keep existing nameservers.” Confirm post-transfer.

Trap: recent WHOIS edits trigger 60-day lock. Fix: plan the transfer before contact changes, or schedule around the lock window.

If you intend to leave GoDaddy’s DNS and move to a modern DNS host, handle it as a second, controlled change. The flow:

• Export zone from current DNS. If no export tool, manually copy every record. Pay attention to root (@) vs subdomain, record types, priorities, and TTLs.
• Import to the new DNS provider. Normalize any provider-specific syntax (flattened SPF, CAA, ALIAS/ANAME equivalents).
• Provision SSL at your CDN/proxy if you use one. Confirm certificate issuance before flipping nameservers.
• Validation: use dig/nslookup to compare answers between old and new DNS. Everything must match before you switch.
• Lower TTLs to 300 seconds a day in advance. Then update nameservers at the registrar.

Watch logs and error rates for 30–60 minutes after the change. If anything looks off, revert nameservers (your rollback) and fix parity before trying again.

Pick a registrar for stability, transparent billing, and security. Keep DNS where your team ships fastest and safest. Many teams decouple registrar and DNS for flexibility. Others prefer an integrated stack to simplify vendors. Either pattern works if your runbook is solid.

CDNs and security proxies add an extra layer. If you use one, double-check certificate status and origin configurations after any DNS change. The registrar won’t help you here; this is a DNS and edge configuration exercise.

The operator stance: invest in boring, reliable infra. Fast UI, clear audit logs, 2FA enforcement, and sane defaults reduce incidents more than fancy features.

Even if you expect zero downtime, treat domain changes like real releases. Write a short change ticket: scope, owner, timestamps, success checks, and rollback. Share it with whoever runs product and customer support.

Do a small window when traffic is light. Announce internally. Have monitoring open (uptime, error logs, DNS query checks) so you aren’t guessing. The speed of your recovery is what matters when something goes wrong.

After completion, close the loop: update the asset register, screenshots, 2FA status, and renewal reminders. Incidents happen when teams lose institutional memory and repeat the same mistakes a year later.

Moving a domain away from GoDaddy is straightforward when you separate registrar from DNS, prep your records, and keep approvals tight. The transfer itself is mostly paperwork; the risk lives in careless DNS changes. Keep nameservers steady during the registrar move, clone zones before any DNS migration, and you’ll be fine.

If you’re planning a broader site or platform shift alongside the transfer, get an operator-grade runbook and ship it once - cleanly. If you want a second set of eyes or a done-for-you plan, start with a quick free Growth Audit to map risks and timelines before you flip any switches.

Author: Anton Chisliuk - operator, not agency.

- How long does it take to transfer a domain from GoDaddy?

Most .com/.net transfers finish in 1–5 days once you approve the emails. If you don’t approve, the registry auto-approves after a standard period (often up to 7 days). You can sometimes accelerate by acknowledging the transfer at the losing registrar if that option is available.

- Will my website or email go down during the transfer?

No - if you keep nameservers the same, there’s no downtime. Downtime only happens when DNS changes are made incorrectly. If you plan to move DNS later, clone the zone, lower TTLs, and switch nameservers in a separate, controlled window.

- Do I lose the remaining months on my registration?

No. In most TLDs, a transfer adds one year to your current expiration date. You pay a transfer fee at the gaining registrar and get the extension upon completion. Some TLDs have different rules; check your TLD’s specifics.

- I changed my registrant email last week and now I’m locked. Can I still transfer?

Probably not right away. ICANN imposes a 60-day lock after certain contact changes. Plan your transfers before changing WHOIS details, or schedule around the lock window. Edge-case exceptions are rare - assume you’ll wait.

- Do I have to disable WHOIS privacy to transfer?

Not strictly, but it helps ensure approval emails reach your real inbox. If your privacy relay is reliable, you can keep it on. If you don’t receive emails, disable privacy temporarily, complete approvals, then re-enable at the new registrar.

- What’s the difference between registrar, DNS, and hosting?

The registrar is your vendor of record with the registry (ownership and renewals). DNS is the nameserver layer that answers where services live (A, MX, CNAME, TXT records). Hosting serves your website or app. You can move registrars without touching DNS or hosting.

- Can I keep GoDaddy DNS after I transfer the registrar?

Yes. You can retain GoDaddy nameservers even if the domain is registered elsewhere. Many teams decouple registrar and DNS. Just select “keep existing nameservers” during the transfer and confirm post-completion.

- My gaining registrar wants to change nameservers by default. What do I do?

Override it. Choose “keep existing nameservers” during checkout. After the transfer, verify nameservers didn’t change. If they did, switch them back immediately to your DNS provider.

- Will moving registrars impact my Google rankings?

No. Search engines don’t care which registrar you use. SEO risk comes from DNS mistakes that cause downtime or broken redirects. Keep the site available, SSL valid, and redirect rules intact.

- How do I make sure email signatures, SPF, DKIM, and DMARC survive a DNS move?

Export your current records, especially MX, SPF (TXT), DKIM (CNAME/TXT), and DMARC (TXT). Recreate them exactly at the new DNS provider before switching nameservers. After the change, send test emails to multiple providers to confirm deliverability and authentication.

- What if I don’t have access to the registrant email inbox?

Update the contact to an inbox you control, but note this may trigger a 60-day lock. If you can’t wait, investigate whether your registrar supports alternate verification, but the safest path is to secure inbox access in advance and plan for the lock if changes are needed.