How to Transfer a Domain to a New Host Without Downtime

Overview

A domain transfer moves the registration from one registrar to another. It is separate from moving website files, databases, email, or applications to a different hosting provider. In some migrations, you transfer the domain and change hosting at the same time; in others, you move the website first and transfer the domain later.

Keeping these activities separate makes troubleshooting easier. Before starting, record where each service is managed:

• Domain registrar: the company that manages the registration, renewal, contacts, and transfer controls.
• DNS provider: the service hosting your A, AAAA, CNAME, MX, TXT, and other DNS records. This may be the registrar, your host, or a separate managed DNS provider.
• Web host: the platform serving your website, application, or API.
• Email provider: the service receiving and sending mail for your domain.

A domain transfer alone should not change the active DNS zone if the nameservers remain the same. However, mistakes such as replacing nameservers, omitting records, or changing DNS and hosting simultaneously can make a working site or email system appear offline. For background, see How to Point a Domain to Web Hosting and DNS Record Types Explained.

Checklist by scenario

Scenario 1: Transfer the domain, keep the current website online

1. Confirm the domain is eligible for transfer. Check its status, expiration date, registrar lock, and any transfer restrictions shown in the registrar account.
2. Verify that you can access the administrative or registrant contact email used for transfer approval.
3. Export or copy the complete DNS zone, including records for the website, email, verification services, subdomains, and third-party tools.
4. Confirm the current nameservers. Do not change them unless you intend to move DNS management.
5. Unlock the domain if the registrar requires it, then request the authorization code, also called an EPP or transfer code.
6. Start the transfer at the new registrar using the exact domain name and authorization code.
7. Complete any confirmation steps, then monitor both registrar accounts and the domain status.
8. After completion, verify the nameservers, DNS records, website, email, redirects, and certificate status.

This is usually the lowest-risk path because the website remains on its existing host and the DNS service remains unchanged.

Scenario 2: Transfer the domain and move the website

1. Build the website on the new host before changing production DNS. Use a temporary URL, staging address, hosts-file test, or another controlled method supplied by the host.
2. Copy files, databases, environment variables, scheduled jobs, media, server rules, and required runtime settings.
3. Test login, forms, checkout, search, uploads, redirects, APIs, and any integrations that depend on the domain.
4. Lower DNS TTL values ahead of the cutover if your DNS provider supports this and the change is appropriate. Lower TTLs do not instantly update every resolver, so allow time for existing cached answers to expire.
5. Keep the old host active while the new host is tested and during the initial observation period.
6. Transfer the domain only if that timing fits your operational plan. The site cutover is controlled by DNS records or nameservers, not by the registrar transfer itself.
7. Change the relevant A, AAAA, CNAME, or nameserver configuration, then test from more than one network.

For a more detailed migration pattern, review Staging vs Production Environments and How to Speed Up a Slow Website.

Scenario 3: Move DNS to a new managed DNS service

1. Create the zone at the new DNS provider before changing nameservers.
2. Recreate every record from the current zone. Pay particular attention to MX, SPF, DKIM, DMARC, verification, wildcard, and subdomain records.
3. Check whether the new provider uses different record formats, defaults, or proxy settings.
4. Validate the new zone using the provider's tools or independent DNS lookups.
5. Change nameservers at the registrar only after the new zone is complete.
6. Keep the old DNS service available until the new nameservers are consistently responding and all services work.

What to double-check

Registrar lock and transfer eligibility: A locked domain cannot normally be transferred until it is unlocked. Recent registration changes, contact changes, or registry-specific rules may affect eligibility. Check the current instructions in both registrar accounts rather than relying on an old checklist.

Authorization code accuracy: Copy the code exactly, without extra spaces. Codes may expire or be regenerated. If the transfer fails, request a fresh code and review the error message before retrying.

Domain status and renewal: Do not allow an important domain to approach expiration during a migration. Confirm who will manage renewal after the transfer and whether auto-renewal settings need to be enabled or reviewed.

DNS and email records: Website records are only part of the zone. Missing MX, SPF, DKIM, or DMARC records can disrupt email even when the website loads normally. Record the current values before making changes.

Nameservers: A transfer may preserve the existing nameservers, but this depends on the registrar workflow and your choices during setup. Check the authoritative nameservers after the transfer completes.

Access and security: Confirm multi-factor authentication, recovery methods, billing ownership, and account permissions at the new registrar. Remove obsolete access only after the migration is verified.

Renewal and privacy settings: Review renewal dates, contact details, privacy options, DNSSEC status, and any forwarding or parking settings. Treat these as configuration items, not assumptions.

Common mistakes

• Assuming a registrar transfer moves the website: It does not copy hosting files or databases. Plan the hosting migration separately.
• Changing nameservers without copying the zone: The new DNS provider may begin with an empty or partial zone, breaking the website, email, or verification records.
• Testing only from one device: Cached DNS responses can make one network show the old destination while another shows the new one. Test using multiple networks and resolver checks.
• Closing the old host too early: Keep the old environment available until traffic, logs, forms, email, and application functions have been checked.
• Ignoring subdomains: Development, support, API, and campaign subdomains may have separate records and business dependencies.
• Changing too many variables at once: When possible, transfer the registration, move DNS, and change hosting in controlled stages so the source of a problem is identifiable.
• Forgetting third-party verification: Analytics, payment, security, email, and SaaS providers may depend on TXT or CNAME records that are easy to overlook.

When to revisit

Use this checklist before every domain transfer, hosting migration, DNS provider change, or registrar account consolidation. Revisit it before seasonal planning cycles if the domain supports a campaign, launch, or high-traffic period. It is also worth reviewing when your registrar, host, DNS provider, control panel, or deployment workflow changes.

Keep a current migration record containing the registrar name, renewal date, nameservers, DNS export, host details, account owners, and the last verified backup. Before acting, schedule a low-risk change window, identify the person responsible for DNS, and define a rollback trigger such as failed health checks, missing email, or application errors. After the change, compare the new configuration with the recorded baseline, monitor the old and new environments, and document what worked.

If you are moving to a new platform, also compare the provider's control panel and operational workflow using Best Hosting Control Panels for Beginners and Developers. For larger website moves, review Best Hosting for Agency Clients or the relevant hosting guidance for your site type before committing to a new setup.