Handling Domain Transfers and Migrations

I want to tell you about a migration that went badly. But first, the mechanics, because understanding the process is the only way to understand how it fails.

The EPP Transfer Process

When you move a domain between registrars, you're executing an EPP (Extensible Provisioning Protocol) transfer. The protocol is defined by ICANN policy and implemented by every accredited registrar. Here's the sequence:

1. Prepare the domain at the losing registrar

Confirm the domain is unlocked (no transfer lock active)
Verify the registrant email is accessible and monitored, approval notifications go there
Obtain the EPP/auth code (also called authorization code, transfer key, or auth-info code depending on the registrar)

2. Initiate the transfer at the gaining registrar

Provide the domain name and EPP code
Pay the transfer fee (most registrars charge 1 year renewal at transfer; some are free)
Confirm registrant details (WHOIS contact)

3. Approval period

ICANN allows up to 5 days for the transfer to complete
The registrant at the losing registrar receives an email notification
They can approve immediately, or it auto-approves at day 5 if not explicitly rejected
The losing registrar can also approve on behalf of the registrant if they choose

4. Transfer completes

Domain moves to the gaining registrar
WHOIS updates to show the new registrar
DNS settings migrate as configured (or pointed to losing registrar's nameservers if you haven't pre-configured DNS at the destination)

The whole process typically takes 2-7 days. International transfers (between different country registrars) can take longer due to different registry policies.

EPP/Auth Codes: Details That Matter

The auth code is a password that authorizes the transfer. Some specifics that catch people out:

Auth codes expire. Depending on the registrar, an auth code may expire after 24 hours, 7 days, or 30 days. If you request a code and don't use it promptly, request a new one.

Auth codes are invalidated by certain actions. Any change to the domain's WHOIS contact information (registrant name, organization, email) at some registrars triggers an immediate code invalidation. If you update contacts and then try to transfer, your auth code may no longer work.

For domains with privacy protection, the auth code must still be obtained through the registrar's interface, not from the WHOIS-listed proxy. The proxy cannot authorize transfers.

Lost auth codes: If you've lost access to the registrant email and can't retrieve the auth code, the process to recover transfer authorization is registrar-specific and usually slow. Some registrars require identity verification via government ID. Plan ahead, don't discover this problem on the day you need to transfer.

The 60-Day Locks: Two Different Rules

There are two 60-day lock periods, and they serve different purposes:

Post-registration lock (ICANN Policy): A domain cannot be transferred out for 60 days after it is first registered. Purpose: anti-fraud. If someone hijacks an account and registers domains, this gives the legitimate owner time to detect the fraud before the domains can be moved out of reach.

Post-transfer lock (ICANN Policy): After a domain is successfully transferred, it cannot be transferred again for 60 days. Purpose: same, prevents chain transfers during a theft scenario.

These locks are non-negotiable at the ICANN policy level. A registrar cannot waive them. Plan your timeline accordingly: if a domain was just registered or just transferred, factor in 60 days before you can move it again.

Some registrars add their own lock period on top of ICANN's minimum. Check their specific policy before planning migrations.

What Can Go Wrong (and Does)

Email access lost: The registrant email is a former employee's address. The approval notification goes nowhere. The transfer auto-approves in 5 days, or more likely gets rejected because nobody approved it. In the meantime, your timeline slips.
Auth code expired: You got the code, waited a week to initiate the transfer, and the code expired. Back to the losing registrar.
Domain in redemption: You tried to transfer a domain that had already lapsed into redemption at the losing registrar. Can't transfer a domain in RGP. Redeem it first, then transfer.
Registrar dispute: A losing registrar places a hold on transfers during a billing dispute. If your account is in arrears, some registrars suspend outbound transfers.
Registry downtime: EPP transfers require the registry to be accessible. During planned maintenance windows (most registries have them), transfers queue or fail. Rare, but real.
Contact validation failures: ICANN's Inter-Registrar Transfer Policy requires accurate contact information. If WHOIS contacts are outdated or incorrect, some registrars reject the transfer initiation.

Planning a Migration for 100+ Domains

This is where registrar migrations get complex. A migration of 200 domains is not the same as moving 200 domain names, it's 200 separate processes, potentially 200 auth code requests, and 200 opportunities for something to go sideways.

The rule: Migrate DNS first, always.

Before you start any registrar transfer, move the DNS to a provider that is independent of both the old and new registrar. This means:

Set up all zones at the new DNS provider
Update nameservers at the old registrar to point to the new DNS provider
Wait for TTL expiry (minimum 48 hours, longer if TTLs were high)
Confirm DNS is resolving correctly from the new provider
Only then initiate registrar transfers

Why? Because if your domain is pointed at your losing registrar's nameservers, and the transfer process creates a status change that temporarily suspends DNS at the losing registrar, you have an outage window. If DNS is at an independent provider, the transfer can proceed without any DNS impact.

Staged migration process:

Audit phase (Week 1-2): Full inventory, verify registrant emails, test auth code retrieval for a sample batch
DNS migration (Week 2-3): Move all zones to independent DNS. Verify with monitoring.
Batch 1, test batch (Week 3): Transfer 5-10 low-criticality domains. Confirm the process works end-to-end at the new registrar.
Batch 2-N (Weeks 4-12): Transfer remaining domains in batches of 20-50, with verification between batches. Don't start the next batch until the previous one is confirmed complete.
Verification (Final week): Confirm all domains are at the new registrar, all DNS is resolving, all auto-renews are configured, all payment methods are valid.

Rollback plan: Know exactly what "rollback" means before you start. For DNS migration: DNS rollback is just changing nameservers back (will work within TTL). For registrar transfer: domains that have already transferred cannot be rolled back to the old registrar for 60 days. Partial rollback means you're managing two registrars anyway.

A Real War Story: What a Bad Migration Looks Like

I won't name the company, but I've seen this pattern twice. A 200-domain portfolio, tight timeline (leadership wanted everything moved before a specific contract end date), no pre-migration DNS separation.

They initiated transfers in bulk, all 200 domains in one week. For the first 100 domains, the nameservers were still pointing at the old registrar. As domains transferred, the old registrar's systems marked them as no longer active in their management interface. Support started handling DNS queries inconsistently.

By day three, about 60 domains had transferred and were pointing at nameservers the new registrar didn't control. The new registrar had no DNS data for these domains because the zones had never been set up there. The domains went dark, no resolution, no website, no email.

Email was the worst part. Several domains were handling production email. When DNS went dark, email delivery failed. Some was bounced, some was lost. The company's support system stopped receiving customer emails for approximately 36 hours for several domains.

The recovery took two weeks of cleanup, manually re-creating DNS zones from backups, coordinating with both registrars, and chasing down 30 domains that got stuck in transfer limbo because approval emails went to a distribution list nobody monitored.

The lesson is simple: DNS first, transfers second, batched, with verification. The extra three weeks of proper sequencing would have cost nothing compared to the recovery.

Key Takeaways

EPP transfers take 2-7 days; auth codes expire and can be invalidated by contact changes
The 60-day post-registration and post-transfer locks are ICANN policy, plan around them
Always migrate DNS to an independent provider before initiating any registrar transfer
Batch transfers with verification between batches; don't mass-transfer everything at once
Keep a rollback plan that acknowledges the 60-day lock reality
Lost registrant email access is the most common cause of transfer failure, audit contacts before starting

Up Next

Lesson 09: Risk management, the full threat map for domain portfolios, registry lock, monitoring tools, and how to hedge against the risks you can't eliminate.