Domain Transfer Checklist: How to Move Your Domain Without Downtime

Overview

A domain transfer moves your domain registration from one registrar to another. It does not automatically move your website files, web hosting, cloud hosting account, email hosting, DNS zone, or SSL certificate. That distinction matters because many problems blamed on a transfer are really caused by DNS or hosting changes made at the same time.

If your goal is a domain transfer without downtime, the safest approach is simple: keep the website and email running exactly where they are, transfer only the registration first, and change DNS later only if you actually need to. In other words, separate the registrar move from the hosting move whenever possible.

Before you start, keep these baseline rules in mind:

• Check transfer eligibility. Some domains cannot be transferred immediately because of recent registration, recent transfer activity, pending expiration, disputes, or registrar locks.
• Know where DNS is hosted. Your registrar and your DNS provider may be different companies. A registrar transfer may have no effect on DNS if the nameservers remain unchanged.
• Inventory every service using the domain. Website, API endpoints, transactional email, mailbox hosting, subdomains, redirects, CDN, and verification records should all be documented first.
• Preserve current DNS settings. Export or manually record every DNS record before touching anything.
• Do not combine unnecessary changes. Avoid changing registrar, nameservers, hosting, mail provider, and SSL setup in one step.

For readers who are still sorting out the difference between domain registration and hosting, it helps to review the basics first: a domain registrar manages your registration, while your web hosting or cloud hosting provider runs the site itself. If you need that foundation, see How to Register a Domain Name: Step-by-Step Checklist for First-Time Buyers.

Checklist by scenario

This section breaks the process into practical scenarios so you can use the right checklist for your exact move rather than following a generic migration sequence.

Scenario 1: Transfer domain registration only, keep existing DNS and hosting

This is usually the lowest-risk path. You want to move to a new registrar for pricing, privacy, account management, or consolidation, but your site and email should stay exactly where they are.

1. Confirm the domain is eligible for transfer. Check the domain status in the current registrar account and verify there are no obvious holds or restrictions.
2. Verify administrative contact access. Make sure you can receive approval messages or complete required confirmations in the current account.
3. Record the current nameservers. Take a screenshot and save the exact values.
4. Export or copy the full DNS zone. Include A, AAAA, CNAME, MX, TXT, SRV, CAA, and any subdomain records.
5. Check email routing. Pay special attention to MX, SPF, DKIM, and DMARC records.
6. Disable transfer lock if required. Registrars often call this domain lock, registrar lock, or transfer protection.
7. Request the authorization code. This may be labeled EPP code or transfer code.
8. Start the transfer at the new registrar. Enter the domain and authorization code carefully.
9. Choose renewal and privacy options deliberately. Some transfers extend the registration term; review any add-ons before completing checkout.
10. Approve the transfer promptly. Respond to any confirmation steps on both sides if needed.
11. After completion, confirm the nameservers did not change. If they are identical, website uptime should remain stable.
12. Test the live site and mail flow. Visit the root domain, www host, common subdomains, and send a test email.

In this scenario, downtime usually happens only if the nameservers are changed unintentionally or if DNS records were being hosted inside the old registrar and were not recreated elsewhere.

Scenario 2: Transfer the domain and also move DNS to the new registrar

This path adds risk because DNS is now part of the migration. It can still be handled safely, but only if you prepare the zone before changing nameservers.

1. Complete the full inventory of existing DNS records. Do not rely on memory. Include verification records for email, search tools, CDNs, third-party apps, and identity providers.
2. Rebuild the DNS zone at the new provider before the nameserver switch. Every active record should exist there first.
3. Compare TTL settings where possible. Lower TTLs can help with future changes, but consistency matters more than aggressive tuning.
4. Check apex and www behavior. Make sure both the root domain and the canonical host resolve correctly.
5. Verify mail-related DNS carefully. MX and TXT mistakes are among the most disruptive and least immediately visible problems.
6. Confirm subdomains used by apps or environments. Common omissions include staging, API, docs, status, shop, login, and webhook endpoints.
7. Only then change nameservers. Do this after the new zone is complete, not before.
8. Monitor propagation and service behavior. Test from multiple networks or external resolvers if needed.
9. Keep the old DNS notes until stability is confirmed. They are your rollback reference.

If you plan to connect domain to hosting at the same time, make sure the target hosting platform is already working before you point production DNS at it.

Scenario 3: Transfer the domain while also migrating to new web hosting

This is common for small business website setup projects and relaunches, but it is the easiest way to create avoidable downtime. Treat hosting migration and domain transfer as separate workstreams.

1. Build and test the new hosting environment first. Whether you are moving to shared hosting, cloud hosting, or managed WordPress hosting, verify the site works before changing public DNS.
2. Install and validate the SSL certificate on the new host. HTTPS should be ready before traffic is sent there.
3. Check redirects, canonical tags, and application config. This is especially important for CMS migrations.
4. Validate database connections, media paths, and forms. A homepage test is not enough.
5. Freeze major content edits during cutover. This reduces sync problems.
6. Transfer the domain registration separately if possible. There is no technical requirement to tie it to the hosting move.
7. Update DNS only after the new host is production-ready. Point the necessary A, AAAA, or CNAME records to the new destination.
8. Monitor uptime, application errors, and certificate status. Continue checking after initial success.

For many teams, the cleanest method is: migrate hosting first under the current registrar, confirm everything works, and only then move the domain registration later for account consolidation.

Scenario 4: Transfer a domain that uses third-party email

Email is where quiet failures tend to happen. A website issue is noticed immediately; email loss may not be discovered until messages go missing.

1. Document all MX records exactly.
2. Document all mail authentication records. SPF, DKIM, and DMARC must be copied accurately.
3. Check for provider-specific TXT or CNAME records. Many mailbox platforms use extra verification records.
4. Review autodiscover or mail subdomains if used.
5. Send and receive test messages before the move. Keep a baseline.
6. After transfer or DNS change, repeat mail tests immediately.
7. Review spam or quarantine behavior. Authentication failures can look like deliverability issues rather than hard outages.

If the domain supports business-critical email, schedule the change for a period when someone can actively watch it rather than near weekends, holidays, or staff absences.

Scenario 5: Transfer an expired or nearly expired domain

This scenario needs extra caution. Processes vary by registrar and by TLD, and timing can complicate what would otherwise be a routine transfer.

1. Check the exact expiration date and current status.
2. Review whether renewal should happen before transfer. In many cases, stabilizing the registration first is simpler than trying to move it at the edge of expiration.
3. Do not assume DNS will remain untouched. Expired domains may already have restrictions or parking behavior in place.
4. Confirm website and email are still resolving as expected.
5. Preserve all DNS data before taking any action.

When a domain is close to expiry, the operational priority is continuity, not optimization. If there is any ambiguity, reduce risk first and transfer later.

What to double-check

Once the transfer is in motion, these are the items worth checking twice because they cause the most real-world confusion.

1. Nameservers versus DNS records

Changing registrar is not the same as changing nameservers, and changing nameservers is not the same as editing individual DNS records. Many support incidents start when those three actions are treated as one thing. If the nameservers stay the same, your live DNS may stay exactly where it was.

2. DNS zone completeness

Do not copy only the obvious records for the website. Include mail records, TXT verifications, redirects, subdomains, service discovery records, and certificate-related entries. A partial zone often looks fine at first because the homepage loads, while secondary services quietly fail.

3. SSL certificate coverage

Confirm the certificate covers the hosts you actually use, including www and any subdomains that are part of the migration. If your hosting platform provisions certificates automatically, verify issuance before cutover.

4. WHOIS contact and privacy settings

Make sure account ownership, contact details, and domain privacy choices are set the way you expect after the transfer. Even when privacy is enabled, you still need correct underlying account access for renewals and approvals.

5. Renewal behavior

Review auto-renew, billing profile, and domain term at the new registrar. A transfer is a good time to catch mismatches between who manages the domain and who pays for it.

6. DNSSEC and security features

If you use DNSSEC or other advanced security settings, verify how they are handled during the move. These features can improve security but also add moving parts if they are not replicated properly.

7. Application and platform dependencies

Modern sites often depend on more than a single A record. CDN endpoints, edge workers, identity providers, transactional email platforms, status pages, and webhook receivers may all rely on the domain. Audit the full stack, not just the website.

If you are also reassessing where to keep the domain long term, a registrar comparison can help you think through renewal rates, privacy, and DNS features before you move: Best Domain Registrars Compared: Pricing, Renewal Rates, Privacy, and DNS Features.

Common mistakes

Most transfer problems come from a short list of avoidable decisions.

• Changing too many variables at once. Registrar, DNS, hosting, and email changes compound risk.
• Failing to inventory DNS records first. This is the single most common source of service breakage.
• Assuming the website is the only service that matters. Email, API subdomains, and third-party verifications are often overlooked.
• Starting the process without access to approvals. If you cannot receive or act on transfer confirmations, timelines slip quickly.
• Ignoring SSL until after DNS changes. The result is a live site with browser warnings.
• Scheduling a transfer right before a launch, campaign, or holiday. Even routine changes deserve a calm window and active monitoring.
• Not confirming post-transfer settings. After completion, verify nameservers, renewals, privacy, and account ownership rather than assuming everything carried over exactly as expected.

Another subtle mistake is using a transfer as a substitute for domain strategy. If you are still evaluating the right name, extension, or branding approach, solve that first rather than moving a domain you may not want to keep long term. For that, see Domain Extension Guide: Which TLDs Are Best for Businesses, Creators, and Startups?.

When to revisit

This checklist is most useful when you return to it before a change, not after a problem. Revisit it in these situations:

• Before moving to a new registrar. Especially if the motivation is pricing, consolidation, better DNS tools, or domain privacy.
• Before changing nameservers. This is the point where downtime risk rises.
• Before a hosting migration. If you are comparing shared hosting vs cloud hosting, or preparing a managed WordPress hosting move, separate the hosting decision from the registration move.
• Before a site relaunch or rebrand. Domain strategy and migration planning often intersect here.
• Before seasonal campaigns or high-traffic periods. Freeze unnecessary DNS changes when the business impact is high.
• Whenever tools or registrar workflows change. Interface changes and policy changes can alter the exact steps even when the principles stay the same.

For a practical action plan, use this short pre-flight sequence every time:

1. List every service tied to the domain.
2. Export or copy the complete DNS zone.
3. Decide whether you are changing only the registrar or also DNS and hosting.
4. Prepare the destination environment before any public cutover.
5. Confirm access to approvals, billing, and account ownership.
6. Schedule the change during a monitored window.
7. Test website, HTTPS, email, and important subdomains after completion.
8. Document the final state for the next person who touches the domain.

A clean domain transfer checklist is less about memorizing registrar-specific screens and more about protecting continuity. If you preserve DNS, separate changes, and verify what the domain actually supports beyond the website, you can usually transfer a domain name with little drama and no visible downtime.