Moving a domain to a new registrar should be routine, not risky. This checklist walks you through how to transfer a domain without downtime by separating registrar changes from DNS changes, flagging the settings that can block a transfer, and giving you a reusable sequence to follow whether you run a brochure site, a store, or a site with business email attached.
Overview
If you are planning a domain transfer, the most important concept is simple: a registrar transfer does not have to change where your website or email is hosted. In many cases, downtime happens not because the transfer itself is dangerous, but because someone changes nameservers, DNS records, or email settings at the same time without a full inventory.
This article is designed as an evergreen domain transfer checklist. Interfaces, buttons, and registrar menus may change over time, but the underlying process stays fairly consistent. Before you begin, treat the transfer as two separate layers:
- Registrar layer: who manages the domain registration, renewal, transfer lock, and ownership details.
- DNS layer: where the nameservers point, and which A, CNAME, MX, TXT, and other records control your website, email, and related services.
If your goal is to move a domain to another registrar without interrupting service, the safest approach is usually to keep the current DNS configuration intact during the transfer. You can always review or change DNS later, after the domain is settled at the new registrar.
Before you start, gather the following:
- Access to the current registrar account
- Access to the destination registrar account
- Administrative email access for the domain contact, if required
- A current export or screenshot of all DNS records
- A record of your nameservers
- Billing access in case renewal or transfer fees are required
- Any hosting, CDN, SSL, or email provider login tied to the domain
It also helps to identify the real reason for the move. Are you transferring for lower renewal pricing, stronger support, better account security, easier DNS tools, or portfolio consolidation? That reason influences what you should verify before and after the transfer. If you are still comparing providers, see Best Domain Registrars Compared: Pricing, WHOIS Privacy, Transfers, and Support.
Checklist by scenario
Use the base checklist first, then apply the scenario that matches your setup.
Base checklist for any domain transfer
- Confirm eligibility. Make sure the domain can be transferred under its current status. Some domains may be blocked by recent registration changes, recent transfers, disputes, or registrar lock settings.
- Audit current DNS. Export or copy every record currently in use. At minimum, document A, AAAA, CNAME, MX, TXT, SRV, CAA, and any subdomain records that support web apps, email, or verification.
- Record the current nameservers. This is one of the most important steps in any domain transfer checklist. If the new registrar defaults to its own parking or DNS service, you want to know exactly what must remain unchanged.
- Check contact details. Verify that the administrative contact email is accessible if transfer approvals are sent there.
- Unlock the domain. Disable transfer lock at the current registrar when you are ready to proceed.
- Request or retrieve the authorization code. Many transfers require an auth code or EPP code. Store it securely and use it promptly.
- Start the transfer at the new registrar. Enter the domain, submit the authorization code, and review the destination settings carefully.
- Keep nameservers unchanged unless you have a separate DNS migration plan. This is the main safeguard for domain transfer without downtime.
- Approve required emails or account prompts. Some transfers move quickly only after manual confirmation.
- Monitor status until completion. Keep both registrar accounts accessible until the transfer is fully done.
- Recheck DNS, website, and email. Once complete, confirm that the domain still resolves correctly and all services work as expected.
- Enable registrar lock again. After the transfer, turn security protections back on.
Scenario 1: Website only, no business email on the domain
This is the easiest case. If the domain only points to a website and does not handle branded email, your main risk is accidental DNS replacement.
- Verify the website's primary A record or CNAME
- Check www and non-www behavior
- Confirm any CDN or reverse proxy settings if used
- Make sure SSL still validates after the transfer
- Test the site from a browser and from a DNS lookup tool after completion
If you are also reviewing hosting at the same time, keep the hosting move separate from the registrar move whenever possible. That reduces variables and makes troubleshooting easier. Related reading: Best Web Hosting for Small Business: Plans, Limits, and Renewal Costs Compared.
Scenario 2: Website plus business email
This is where many transfers go wrong. A site may stay online while email quietly breaks because MX, SPF, DKIM, or verification TXT records were not preserved.
- Document all MX records exactly
- Copy SPF, DKIM, and DMARC TXT records
- Check autodiscover, mail, smtp, or other mail-related hostnames if used
- Confirm whether your email is tied to the registrar, your host, or a third-party email platform
- Send and receive test emails before the transfer, immediately after, and again the next day
If your domain supports team inboxes, sales aliases, or transactional email tools, include those records in your DNS inventory. Losing one TXT or CNAME record can interrupt email authentication or routing even if the main website appears fine.
Scenario 3: Domain uses custom nameservers from your host or DNS provider
In this case, the transfer is often straightforward because DNS is already managed outside the registrar. Your goal is to keep the same nameservers at the new registrar.
- Write down the exact nameserver values
- Confirm the DNS provider account is active and accessible
- Check that no auto-switch to default registrar DNS occurs during checkout or onboarding
- After transfer, verify the nameserver entries are unchanged
This setup is common with cloud hosting, CDN-managed DNS, and some managed WordPress platforms. If you are comparing hosting models more broadly, see Shared Hosting vs VPS vs Cloud Hosting: Which Should You Choose? and Best Managed WordPress Hosting for Speed, Support, and Scalability.
Scenario 4: Domain and website migration happening together
This is the highest-risk scenario, because you are changing registrar, DNS, and hosting at once. It can be done, but it should be treated like a project with staging, rollback options, and a checklist for each layer.
- Move the website first or the domain first; avoid doing both simultaneously if timing is flexible
- Build the new hosting environment before any DNS cutover
- Lower DNS TTL values in advance if you expect record changes soon, where appropriate
- Test the new site on a temporary URL, preview domain, or hosts file override
- Schedule the cutover during a low-traffic period
- Keep the old hosting active until traffic and email are stable
If the site is a store, membership site, or critical lead-generation property, a slower sequence is usually safer than a one-day all-in move. For store owners, this is especially important because payment flows, email receipts, and SSL must all remain stable. Related reading: Best Hosting for WooCommerce Stores: Speed, Security, and Scaling Features.
Scenario 5: Multiple domains in one portfolio
If you manage several domains, create a transfer sheet instead of relying on memory. Include registrar, expiry date, lock status, nameservers, DNS provider, website host, email provider, transfer auth code status, and post-transfer verification notes.
- Transfer domains in batches only if the setups are similar
- Start with a lower-risk domain to test the destination registrar workflow
- Do not assume every domain uses the same DNS provider or email service
- Re-enable security settings for each domain after completion
What to double-check
Even experienced site owners miss a few items during a routine transfer. These are the details worth checking twice.
Nameservers versus DNS records
If you keep the same nameservers, your DNS zone may remain untouched. If you switch nameservers, you must recreate all DNS records at the new provider before making the change. Confusing these two ideas is one of the most common causes of downtime.
Email records
Email is often more fragile than the website. Double-check:
- MX records
- SPF records
- DKIM keys
- DMARC policy
- Any provider-specific verification records
Test both inbound and outbound email, not just one direction.
Auto-renew and expiry dates
Before you transfer, check whether auto-renew is enabled at the current registrar and understand what happens when a transfer is initiated. After the transfer, confirm the renewal settings at the new registrar so the domain does not lapse later because billing was not reconfigured.
Privacy and ownership details
Check whether WHOIS privacy, ownership contact details, and organization fields are set the way you expect after the move. Privacy settings and contact displays can differ between registrars.
DNSSEC, CAA, and advanced records
If you use DNSSEC or certificate authority authorization records, verify them deliberately. Advanced DNS settings are easy to forget because the site may appear to work without them at first.
SSL behavior
Registrar transfers typically do not replace your SSL certificate, but related DNS or hosting changes can affect validation. Confirm that HTTPS works on key pages, not only the homepage.
Third-party services
Review integrations tied to the domain, including:
- Analytics or tag manager verification
- Search console verification
- CDN configuration
- CRM tracking links
- Form handlers and transactional email tools
- Subdomains for apps, support portals, or landing pages
If you rely on branded links or subdomains for campaigns, test them after the transfer rather than assuming they will inherit the main domain's behavior.
Common mistakes
If you want to learn how to transfer a domain with minimal risk, avoid these predictable errors.
Changing registrar and DNS at the same time without a plan
This is the biggest avoidable mistake. A transfer can be simple if DNS stays the same. It becomes much more complex when the move includes nameserver changes, hosting migration, and email reconfiguration all at once.
Forgetting to inventory DNS before starting
People often assume they can look up records later, but if access changes or records are incomplete, rebuilding from memory becomes difficult. Always create a full DNS snapshot first.
Ignoring email because the website still loads
A successful homepage check does not mean the transfer was successful. Email failures, broken SPF alignment, or missing verification records may not be obvious until users stop receiving messages.
Initiating the transfer too close to a major campaign or seasonal event
If the domain supports paid traffic, product launches, seasonal promotions, or important client communications, avoid a rushed transfer window. Even a smooth move benefits from a quiet operating period and time for verification.
Not checking renewal terms at the destination registrar
Some site owners move a domain for convenience and only later discover that the long-term cost, support model, or account features are not what they expected. Before transferring, compare transfer flow, account security, DNS controls, and renewal experience, not just the initial charge. You may also find this useful: Best Cheap Web Hosting That Stays Affordable After Renewal.
Closing the old account too quickly
Keep access to the old registrar account until the transfer is complete and verified. Historical records, billing receipts, and support history can still be useful during cleanup.
When to revisit
This checklist is worth revisiting any time your registrar workflow, DNS provider, or site stack changes. In practice, review it in the following situations:
- Before seasonal planning cycles: especially if your business has peak traffic periods, campaigns, or sales events where even minor disruption is costly.
- When tools or interfaces change: registrar dashboards, approval flows, and security prompts change over time even when the core transfer logic stays the same.
- Before consolidating vendors: if you are moving domains, hosting, email, and DNS under fewer accounts, separate the project into stages and update your notes.
- When adding new services: new email providers, CDNs, verification systems, and app subdomains increase DNS complexity and should be reflected in your inventory.
- Before transferring a high-value or high-traffic domain: rehearse the process on a lower-risk domain first if possible.
For a practical pre-transfer routine, use this short action list:
- Inventory every DNS record and nameserver.
- Identify whether email is tied to the domain and list all related records.
- Confirm eligibility, unlock status, and auth code access.
- Start the transfer while keeping nameservers unchanged unless a separate DNS migration is planned.
- Verify website, HTTPS, email, and key subdomains after completion.
- Re-enable security settings and document the final configuration.
A domain transfer should feel boring when it is done well. If you keep registrar changes separate from DNS changes, document the current setup before touching anything, and verify email as carefully as the website, you can usually complete the move with little or no visible disruption. That is the core of domain transfer steps that remain useful even as registrar interfaces evolve.