A domain transfer does not have to interrupt a website or business email. This step-by-step checklist shows what to verify before requesting a transfer, how to preserve DNS continuity, where authorization codes and transfer locks fit, and which checks to repeat after the move is complete.
Overview
A domain transfer moves the registration record from one registrar to another. It does not automatically move your website, hosting account, DNS provider, files, databases, or email service. Keeping those services running is the central principle of a transfer without downtime.
In a typical transfer, the domain continues using its existing nameservers while the registrar changes. If the nameservers and DNS records remain intact, visitors and mail systems can usually continue reaching the same services. Problems occur when a transfer is treated as a complete website migration, when DNS records exist only at the old provider, or when the domain is allowed to expire during the process.
Before starting, record the current setup. Identify the registrar, registrant account owner, expiration date, nameservers, DNS provider, website host, email provider, SSL configuration, and any services that depend on the domain. If you are also changing hosting or email, manage those as separate workstreams and test them independently.
For related planning, see this website migration checklist. If your objective is only to move the registration, keep the existing DNS arrangement in place until the transfer has been verified.
What to track
1. Domain ownership and account access
Confirm that you can sign in to the current registrar and that the account contains accurate administrative and registrant contact details. Check who receives transfer notices and whether multi-factor authentication is enabled. If the domain belongs to a company, make sure access is tied to a controlled business account rather than one person’s private email address.
Do not begin a transfer until you can access the destination registrar account as well. Compare the exact domain spelling, select the intended registration term, and review the destination provider’s transfer instructions. Interface labels vary, so treat the registrar’s current instructions as the final reference for screens and requirements.
2. Expiration date and transfer timing
Record the domain’s expiration date and leave enough time for troubleshooting. A transfer should not be planned as an emergency task immediately before expiration. Renewal and transfer treatment can vary by domain extension and registrar, so check the applicable terms before proceeding.
Also note whether a recent registrant-contact change, ownership update, or other account change could affect transfer eligibility. If the domain is involved in a dispute, recovery process, or security investigation, resolve that situation before moving it.
3. Transfer lock and authorization code
Many domains have a registrar-side transfer lock that must be disabled before an outgoing transfer can proceed. In the current registrar dashboard, look for wording such as transfer lock, registrar lock, or domain lock. Record the lock status, change it only when ready, and restore appropriate security controls after the transfer if the new registrar provides an equivalent setting.
You will usually need a domain authorization code, sometimes called an EPP code or transfer code. Request it through the current registrar’s domain-management tools, not through an unverified message or third-party link. Treat the code like a temporary credential: share it only with the destination registrar and avoid storing it in an exposed document.
4. DNS and service continuity
Export or document the complete DNS zone before making changes. Include A and AAAA records for websites, CNAME records, MX records for email, TXT records for verification and email authentication, and any records used by subdomains or development environments. A DNS management dashboard or a trusted DNS lookup tool can help you compare the public records with the provider’s internal zone.
Confirm where DNS is hosted. The registrar and DNS provider may be different companies. If the domain uses external nameservers, transferring the registration should not require moving the zone. If DNS is hosted by the current registrar, create an equivalent zone at the destination or at a separate DNS provider before changing nameservers.
For a record-by-record explanation, use DNS Records Explained. Pay particular attention to email records; a missing MX, SPF, DKIM, or DMARC-related record can affect mail even when the website appears healthy.
5. A simple pre-transfer checklist
- Current registrar and destination registrar accounts are accessible.
- Expiration date and renewal status are recorded.
- Registrant and administrative contact information is accurate.
- Existing transfer lock status is documented.
- Authorization code has been obtained through the current registrar.
- Nameservers and the complete DNS record set are recorded.
- Website, email, SSL, redirects, and important subdomains have been tested.
- Recent backups exist for website files, databases, and any mail data under your control.
Cadence and checkpoints
Use a staged workflow instead of changing every domain setting at once.
- One to two weeks before the move: audit ownership, expiration, DNS, hosting, email, and security settings. Lower DNS time-to-live values only if you expect a nameserver change; a registrar-only transfer normally does not require this.
- Before submitting the transfer: unlock the domain if required, obtain the authorization code, confirm the destination account, and save a copy of the current DNS zone.
- At submission: enter the domain and authorization code carefully. Confirm whether the destination registrar is asking to transfer registration only or also to change nameservers. Do not approve an unexpected request.
- During the transfer: monitor registrar notifications, domain status, website uptime, and mail delivery. Avoid unrelated DNS, hosting, or CMS changes while the transfer is pending.
- After completion: verify the new registrar, expiration date, nameservers, DNS records, contact details, auto-renewal preference, privacy settings, and account security.
Maintain a transfer log with the date, registrar accounts, authorization-code request, lock changes, approval messages, and final verification results. This is especially useful when managing several domains or handing the process between administrators.
| Checkpoint | What to verify | Warning sign |
|---|---|---|
| Registration | New registrar displays the correct domain and ownership details | Unexpected spelling, account, or contact information |
| DNS | Nameservers and key records match the documented configuration | Website, subdomain, or mail record is missing |
| Website | HTTPS, redirects, forms, and major pages work | Certificate warning, redirect loop, or failed form |
| Inbound and outbound test messages succeed | Missing mail, authentication warning, or rejected messages | |
| Security | Multi-factor authentication, lock, and recovery details are set | Unrecognized user, notification, or account change |
How to interpret changes
A successful transfer can leave the website looking exactly as it did before. That is expected when the same nameservers and DNS records remain active. A temporary delay in the registrar dashboard does not necessarily indicate an outage, but it should be compared with the public domain status and service tests rather than assumed to be harmless.
If the website fails but DNS records look correct, investigate the hosting account, origin server, firewall, SSL configuration, and application settings. If the website works but email fails, compare MX and TXT records and check the email provider’s domain-verification status. If only one subdomain fails, inspect its individual record instead of replacing the entire DNS zone.
When public DNS results differ between networks, allow for caching and propagation behavior. Use more than one DNS lookup location and compare results over time. Do not repeatedly edit records in response to a single stale result; document the change, wait for the relevant caches to update, and test again.
For a registrar change combined with a host change, use a separate migration plan. The guidance in Connect a Domain to Cloud Hosting can help distinguish registration, DNS, SSL, and hosting tasks.
When to revisit
Revisit this checklist before every domain transfer, not just the first one. Add a quarterly domain-management review for business-critical domains and a monthly check for domains approaching expiration, undergoing a project change, or supporting important email.
During each review, confirm the registrar account owner, expiration date, auto-renewal preference, transfer-lock status, recovery contacts, nameservers, DNS provider, and current services. Check that backups and documentation still exist and that former administrators no longer retain unnecessary access.
Update this article or your internal checklist whenever registrar interfaces, transfer requirements, renewal treatment, or domain-extension rules change. The practical trigger is not a particular calendar date; it is any change to the registrar, domain extension, ownership, DNS provider, hosting environment, email platform, or security policy.
Final action: create a one-page record for each important domain containing the registrar, expiration date, nameservers, DNS provider, service dependencies, authorized administrators, and last verification date. That record turns a stressful transfer into a controlled, repeatable process—and gives the next administrator a reliable starting point.
