Transfer First, Ownership Second: Avoid the 60-Day Domain Handover Lock

A domain handover can stall because of a step that appears responsible: updating the registrant's organization name or email address before moving the domain to its destination registrar.

Consider a hypothetical agency offboarding a client. The agency wants the public registration details to show the client's company immediately, so an operator updates the organization and registrant email. The client then asks to move the domain into its own registrar account. Instead of a routine transfer, the team may find that a 60-day transfer restriction now applies. A sensible administrative update has changed the timeline for the larger handover.

This is not merely a registrar-console annoyance. A delayed move can complicate access, invoice responsibility, renewal planning, DNS changes, and the agency's exit commitments. The practical lesson is simple: when both a registrar move and a registrant change are planned, decide the sequence before anyone edits registrant data.

Why the order of a domain handover matters

For gTLDs covered by ICANN's Transfer Policy, a Change of Registrant can lead to a 60-day inter-registrar transfer lock. The policy allows a registrar to offer the registered name holder an opportunity to opt out before the change is made, but this is a decision to confirm with the authorized party and current registrar, not an assumption to make. ICANN specifically directs registrars to advise the prior registrant to complete an intended inter-registrar transfer before the registrant change, unless an available opt-out is selected beforehand. See the ICANN Transfer Policy.

The details that can matter are broader than a legal-owner replacement. ICANN describes relevant changes as updates to the registrant's name, organization name, or email address; where no registrant email exists, the administrative contact email can be relevant. Review the ICANN explanation of Change of Registrant before treating a contact cleanup as harmless.

A safer default for a planned registrar migration is therefore:

1. Confirm whether the domain can transfer now.

2. Prepare and complete the inter-registrar transfer.

3. Verify the domain at the destination registrar.

4. Make the intended registrant or contact updates after the transfer.

This is not a rule that every handover must follow without exception. The present registrant may have a legitimate reason to update details first, and the registrar may provide a pre-change opt-out. But the team should make that choice knowingly, with the expected consequence recorded, rather than discovering the restriction after a client has been promised a move date.

Separate the three 60-day checks

The phrase “60-day lock” is too vague to be useful in a handover ticket. Teams need to identify which restriction applies, who can resolve it, and the earliest realistic transfer date.

1. A recent-registration restriction

A transfer request can be denied when it is made within 60 days of a domain's initial registration. A newly registered campaign or product domain may therefore be unavailable for a registrar move even if its contacts and DNS are otherwise ready.

2. A recent-transfer restriction

A domain may also be ineligible for another inter-registrar transfer within 60 days after a prior inter-registrar transfer. This matters after acquisitions, emergency moves, or prior vendor transitions. Do not assume the registrar shown in an old spreadsheet is the registrar from which a transfer can currently be initiated.

3. A change-of-registrant restriction

This is the avoidable sequencing issue. A recent Change of Registrant can trigger a 60-day inter-registrar transfer lock where no pre-change opt-out applies. Record the date of the actual change and the resulting eligibility date, rather than writing only “locked” in a note.

These time-based restrictions are distinct from a normal registrar lock. Under the ICANN policy, a registrar cannot deny a transfer solely because a domain is locked if the registered name holder has a reasonable opportunity to unlock it before making the transfer request. In other words, “unlock the domain” may solve an ordinary status lock, but it does not erase a time-based eligibility restriction.

A transfer-first handover workflow

Use this workflow when an agency, IT team, former vendor, or acquired business needs to hand a domain to a new registrar and may also need to update registrant details. It turns an ambiguous handover into a series of named decisions.

Step 1: classify the requested outcome

Ask the requester to distinguish between three outcomes that are often bundled together:

• Registrar control: Which registrar account should hold the domain?

• Registrant details: Whose name, organization, and contact email should be on the record?

• Operational control: Who needs access to DNS, renewal decisions, invoices, and the registrant mailbox?

These outcomes can be completed on different dates. A client may need DNS access now, registrant information corrected after internal approval, and the registrar move completed before an agency contract ends. Separating them prevents one change from silently blocking another.

Step 2: build a one-domain handover brief

Before making changes, create a compact record that answers questions an operator will otherwise have to reconstruct under pressure:

• Domain name, TLD, current registrar, and target registrar.

• Expiration date and next renewal decision date.

• Current registrant and intended registrant.

• Whether a change of registrant is required.

• Creation date, last transfer date, and any known transfer eligibility date.

• The person authorized to approve the transfer and contact change.

• Who controls the current registrant email inbox.

• Who can unlock the domain and obtain any required authorization code.

• DNS provider, planned change window, and rollback contact.

• A named internal owner responsible for closing the handover.

The aim is not to create bureaucracy for a straightforward transfer. It is to expose dependencies while there is still time to choose a sequence.

Step 3: run an eligibility gate before changing contacts

Pause the work at a clear decision point: can this domain move today? Check the applicable registrar and registry process, recent registration and transfer dates, account access, transfer status, and renewal timing. For many registrar workflows, an authorized operator must unlock the domain and obtain an Auth/EPP code. As one example of registrar-specific process, Namecheap's transfer guidance notes that an authorization code is unique to the domain and may be delivered to the registrant email rather than the account email.

That email detail is an operational risk. A team can have access to a registrar account yet be unable to complete the required confirmation because a former employee, a vendor, or an unmonitored mailbox receives it. Verify the delivery path before scheduling the handover.

Step 4: choose and document the sequence

If the transfer is eligible and the desired end state is a different registrar, use transfer first and make registrant updates after the destination is confirmed. If contacts must change first, document whether the registrar offers an opt-out before the change and whether the authorized registered name holder has approved it.

If transfer is not eligible, do not leave the ticket in a generic “pending” state. Record the reason, the eligibility date if known, the interim operator, and what must remain stable until then. That might include DNS, billing, renewal responsibility, and the registrant inbox.

Step 5: protect the renewal window

A handover is not a reason to let renewal become ambiguous. If expiration arrives before the planned transfer date, explicitly decide who will renew, in which account, and who will confirm completion. A transfer and a renewal are separate registrar actions; neither should be inferred from the other.

For example, a hypothetical domain expires in 18 days but cannot be transferred for another 35 days because of a recent registrant change. The responsible team may decide to renew at the current registrar, preserve DNS settings, and set a dated follow-up for the transfer. That is less elegant than a single clean handover, but much safer than allowing an unowned deadline to dictate the work.

Use a simple decision framework when the client wants an immediate change

When a stakeholder says “put it in our name now,” respond with a short decision framework rather than an automatic yes.

1. Is a registrar move still required? If no, a contact update may be the only task.

2. Is this a gTLD or a TLD with different local rules? ICANN's policy is not a universal rule for every ccTLD. Check the specific registry and registrar procedure.

3. Can the domain transfer now? Check all three time-based constraints and ordinary lock status.

4. Does the current registrar offer a pre-change opt-out? Confirm availability and authorization before the change, not afterward.

5. What is the renewal exposure? Assign a renewal owner until the handover is fully closed.

This framework also helps how agencies manage client domains during offboarding. It replaces an informal request with an auditable plan: current control, intended control, restrictions, approval, and next action.

Keep the plan visible until the handover is truly complete

A domain should not disappear from the team's active work simply because a transfer request was submitted. Keep a temporary handover status such as transfer-first, awaiting-approval, transfer-pending, or post-transfer-contact-update. Review that list against upcoming expiration dates until each domain reaches its intended registrar and ownership state.

This is especially useful when teams manage domains across registrars. The immediate task may be technical, but the real control is shared visibility: someone can see the target registrar, the blocker, the approval owner, and the next deadline without searching old emails or asking a former vendor for context.

For teams that need a dedicated domain renewal tracker for IT teams or agencies, domainnotifications.com can centralize tenant-owned domain inventories across registrars, renewal monitoring, team roles, tags, imports, and exports. Reminders can be routed through email, Slack, SMS, or webhooks subject to plan entitlements. A handover tag and clear notes can keep the planned sequence and accountable owner visible alongside the renewal date. Ultimate workspaces can also use custom attributes for fields such as target registrar, transfer eligible on, and handover stage. It tracks renewals and handover context; it does not register domains or perform automatic renewals. See the domain portfolio management software overview for the operational scope.

The restrained goal is not to make every domain move instantaneous. It is to make the order of operations deliberate, so a well-meant ownership update does not create a 60-day surprise at the moment control needs to change.