Intra-Registrar Account Push Walkthrough: How to Move a Domain Between Accounts at the Same Registrar, Step by Step

What an intra-registrar account push is, and the three operations it is not

An intra-registrar account push moves a domain between two accounts at the same registrar, with no registry boundary crossed. It is a different operation from an inter-registrar transfer, which moves the domain to a new registrar, from a change of registrant, which updates who legally owns the name, and from a nameserver change, which only redirects where the domain points. The push is the fastest of the four because it stays inside one registrar’s system.

The word transfer gets used loosely, and a push is frequently called a transfer even though it follows none of the inter-registrar rules. Drawing the line first prevents the error that recurs first, where someone starts the slow inter-registrar process when the fast same-registrar push was the right tool, or starts a push expecting it to also hand over ownership when ownership is a separate setting.

The four operations the word transfer can mean

An account push is the subject of this guide: the domain moves between two accounts inside one registrar, governed by that registrar’s own account rules instead of ICANN’s inter-registrar Transfer Policy. An inter-registrar transfer moves the domain to a different accredited registrar, requires the authorization code, and is subject to the 60-day eligibility lock. A change of registrant updates the registrant contact, the field that records legal ownership, and it can ride along with a push or happen on its own. A nameserver change moves only where the domain resolves and hands over neither the account nor the ownership.

Why a push exists and when it is the right tool

The push solves a specific problem: handing a domain to a different account holder without the cost and delay of moving registrars. A domain investor consolidating names under a client’s account, a seller delivering a sold domain to a buyer at the same registrar, or a business moving a name from a personal account to a company account all reach for a push. Because the name stays at one registrar, the expiry date is untouched, no registration year is added, and there is no auth code to obtain, which is what makes the push the path of least friction inside the wider transfer process.

Before you push: the eligibility check and the preconditions

A push can begin once three conditions are met: the receiving account exists at the same registrar and has a complete profile, the domain is not held by a registrar restriction such as an active pending transfer or a redemption status, and the sending account confirms whether the push will also change the registrant. The leading cause of a stalled push is a receiving account that is not fully set up, because a number of registrars hold or reject the push until the destination profile is complete.

Precondition one: a receiving account that is ready

The destination is an account at the identical registrar, identified by its email address, username, or customer number. Namecheap states that the destination account needs its account details filled in correctly before the push, and lists specific extensions, including .au, .ca, .de, .eu, .fr, .uk, and .us, where a complete destination profile is required for the move to land. A receiving account with an empty or partial profile is the first reason a push sits unaccepted or bounces, so confirming the destination is set up is the first eligibility check, not an afterthought.

Precondition two: no restriction holding the domain

A domain inside an active inter-registrar transfer, in a redemption or pending-delete registry status, or under a registry-level hold cannot be pushed until that state clears. Unlike an inter-registrar transfer, an account push does not require the registrar lock, shown in registration data as clientTransferProhibited, to be removed, because that lock guards the registry boundary the push never crosses. The full reasoning on which locks matter and when sits in Transfer locking and when to unlock.

Precondition three: decide the registrant question now

The single decision that shapes everything downstream is whether the push will also change the registrant. One set of registrars lets a push move the domain between accounts while keeping the same registrant contact, and others treat handing a domain to a new account holder as a change of registrant by default. That choice decides whether a 60-day lock attaches, so it belongs at the start of the process, before the request is sent, not as a surprise discovered afterward. The mechanism is the subject of a dedicated section below.

The account push walkthrough, step by step

The push runs in five steps: confirm the receiving account, open the push or change-ownership tool in the sending account, enter the destination identity and choose the contact handling, authorize the request with the account password, and have the receiving account accept the invitation. Each registrar names the tool differently, but the sequence is the same, and the one irreversible moment is the receiving account accepting, after which the change cannot be undone.

The sequence, registrar by registrar, reduced to one process

The published help docs from GoDaddy, Namecheap, and NameSilo describe the same five-step shape under different labels. GoDaddy calls it transferring to another GoDaddy account, Namecheap calls it Change Ownership, and NameSilo calls it Push Domains. The walkthrough below is the common process, with the registrar-specific wording noted where it matters.

The contrast with a full registrar move is sharp: where this push is a same-day, no-code action, an inter-registrar transfer obtains an authorization code, clears the lock, and waits out a multi-day window. That code and its 2024 policy treatment are set out in EPP code (auth code) explained, and the end-to-end registrar move is documented in the Inter-registrar domain transfer walkthrough.

How the push differs by registrar: the terminology and fee map

Every major registrar offers a same-registrar push, but each names it differently and applies its own fee and speed rules. The operation is identical underneath, and the published terms converge on the same picture: a push is free at the largest registrars, completes near-instantly, uses the account password in place of an auth code, and leaves the expiry date unchanged. The one detail worth knowing first is what the same action is called in each panel.

The same operation under different names

Searching a registrar’s help for the word transfer routinely surfaces the inter-registrar process first and buries the push. The table maps the published terminology and terms so the right tool is found on the first try, with each claim drawn from the registrar’s own documentation.

Push versus inter-registrar transfer, side by side

NameSilo’s own documentation compares the two operations directly, and the contrast holds across registrars. The comparison is the clearest way to confirm a push is the right choice for a same-registrar handover.

The 60-day lock paradox: when a push blocks the buyer’s next move

A push does not trigger the 60-day inter-registrar lock by itself, because the domain never leaves the registrar. The paradox is that a push which materially changes the registrant does trigger ICANN’s separate Change of Registrant 60-day lock, and that lock then blocks any move to a different registrar for 60 days. A buyer who accepts a push with the registrant updated, then tries to move the name to their own registrar, finds it frozen. The fix is to handle the registrant decision deliberately and to use the opt-out where the registrar allows it.

What ICANN’s Change of Registrant policy actually says

ICANN defines a Change of Registrant as a material change to the registrant’s name, organization, or email address, with Material Change defined as a nontypographical correction. Under the policy, in effect since 1 December 2016, registrars must impose a 60-day inter-registrar transfer lock following a Change of Registrant. The policy applies to generic top-level domains such as .com, .net, and .org. Country-code domains, including .uk, .eu, .us, and .ca, sit outside it. The mechanics of the broader 60-day eligibility rules are documented in ICANN’s 60-day transfer rule.

The opt-out, and why the timing is everything

The opt-out is the escape hatch, and it is time-bound. The policy permits a registrar to let the prior registrant opt out of the 60-day lock before the Change of Registrant request is made, and bars an opt-out once the lock is already in place. For a buyer who intends to move the name to their own registrar after taking custody, the sequence matters: arrange the opt-out with the seller before the push, or keep the registrant unchanged during the push and handle ownership separately, so the lock never attaches in the first place.

Taking custody of a freshly acquired aged or expired domain

When an aged or expired domain is bought from a seller who holds it at the same registrar the buyer uses, the account push is the fastest custody path available. It hands the name over the same day, at no fee, with no auth code, and without resetting the expiry date. The asset that matters, the domain’s age and inherited backlink authority, travels with the name untouched. The discipline is to verify the name before accepting and to plan the registrant decision around any onward move.

Why the push is the custody path for a same-registrar acquisition

A domain bought at auction or through a marketplace has to reach the buyer’s control before it can be put to work. When buyer and seller share a registrar, the push achieves that in minutes, not the days an inter-registrar transfer takes, and it does so without adding the registration year a transfer forces. For a domain investor receiving names in volume, or a buyer who wants the asset live quickly, the push is the obvious mechanism, and sourcing names already at a known registrar makes it the default instead of the exception.

The verify-before-accept discipline

The buyer accepts the push, and acceptance is the irreversible step. Before clicking the link, the buyer confirms the name is exactly right, the spelling and the TLD match the purchase, the domain is not sitting in a redemption or pending status, and the registrant decision matches the onward plan. A name sourced from a screened catalogue arrives with its registrar, lock state, and registration history already known, which turns the verification into a confirmation instead of a discovery. SEO Domains operates that curated marketplace, where transfer-ready aged and expired names are screened before listing so a push starts from a name whose status is documented.

The post-acquisition steps that follow a successful push, from re-pointing DNS to confirming the registrant and renewal settings, are set out in the Post-transfer checklist for aged domains, which applies to a name taken in by push as much as by transfer.

When a push is rejected or fails, and how to fix it

A push fails for a small set of recurring reasons: a receiving account that is not fully set up, a domain held by a registry status or an account-level eligibility rule, an unaccepted or expired invitation link, or a registrant change that ran into a lock. Each has a clear fix, and almost all of them are caught by checking the destination account and the domain’s status before the push instead of after. The errors are diagnostic, not dead ends.

The recurring failure modes and their fixes

The error messages registrars return point straight at the cause. An eligibility message such as the account-transfer error registrants report, where an account is flagged as not eligible for account transfers, signals an account-level restriction to take up with the registrar, not a fault in the domain. The table consolidates the failures the help docs and registrant reports describe.

The wider catalogue of transfer problems, including the failures specific to moving a domain between registrars, is documented in Transfer failures: common causes and fixes, which complements the push-specific list above.

The post-push verification checklist

A completed push is verified, not assumed. The receiving account confirms the domain is present, the registrant and contact data read correctly, the renewal and auto-renew settings are intact, the DNS resolves where it is meant to, and any onward move is planned around the registrant decision that was made. The checklist turns a finished push into a confirmed handover and catches the small misconfigurations that surface later.

Read top to bottom, the checklist confirms the name landed cleanly and the asset is ready to use. Read as a pre-push reference, the same rows are the things to settle before the request is sent, since each one is easier to fix before acceptance than after.

One pattern runs down the whole checklist. A push moves the account and nothing else, so every row confirms that something the push deliberately left untouched, the DNS, the expiry, the security, is set the way the new owner wants. The asset arrives intact; the configuration around it is what the new account verifies.

Start with a transfer-ready domain: source it screened

An account push is the fastest way to take custody of a domain when buyer and seller share a registrar, and it is at its smoothest when the name’s status is known before the request is sent. A transfer-ready aged or expired domain arrives with its registrar, lock state, and registrant history documented, so the push is a confirmation instead of a gamble. SEO Domains operates the curated marketplace where those names are screened before they are listed.

Why a known status makes the push effortless

Every failure mode in this guide traces back to an unknown: an account that turned out to be incomplete, a status that blocked the move, a registrant change that quietly attached a lock. A name sourced from a screened catalogue removes those unknowns at the front. The registrar is known, so buyer and seller can confirm they share one and the push is even on the table. The registration and lock history are documented, so the verify-before-accept step is a quick confirmation. The asset itself, the age and the inherited authority, is what the screening protects and what the push delivers untouched.