A transfer moves who bills and manages the registration. It does not move hosting, email, or DNS settings, and the most common failure is assuming it does, which takes the site and mail offline.

What a transfer does and does not move

The distinction that causes most of the trouble.

It moves the registration itself: who you pay, where you manage it, and who the registry recognises as the registrar of record.

It does not move your website, your email, or the DNS records that point the domain at them. Those are separate things that happen to be configured through the registrar in many setups.

The failure that follows is predictable. Somebody transfers a domain, the new registrar applies its own default DNS, and the records pointing at the hosting and the mail provider disappear. The site goes down and email stops, and it looks like the transfer broke something.

The preparation that prevents it

Record the existing DNS records before starting.

A screenshot or an export of the full zone: the records pointing at the web server, the mail records, and any verification records for services you use. That list is what you recreate at the new registrar if it does not come across.

Where possible, set the DNS up at the new registrar before initiating the transfer, so the records exist and match. Then the change of registrar has no effect on where anything points.

Ten minutes of recording prevents the outage entirely, and almost nobody does it.

The conditions that block a transfer

The fourth is the one that stops most attempts. If the contact address on the registration is a former employee or an address you no longer read, the approval never reaches you and the transfer times out.

Checking and correcting that address is the first step rather than the last.

The sequence

  1. Check the domain is eligible, meaning not recently registered or transferred.
  2. Update the contact email to one you can access.
  3. Record the current DNS records.
  4. Disable the transfer lock at the current registrar.
  5. Obtain the authorisation code.
  6. Set up matching DNS at the new registrar.
  7. Initiate the transfer and pay, which usually adds a year to the registration.
  8. Approve it from the email that arrives.
  9. Verify afterwards that the site and email still work, and re-enable the lock.

The whole process typically takes several days rather than minutes, because the losing registrar has a window in which to release it. Plan it for a quiet period rather than before a busy season.

Reasons to transfer, and one not to

Good reasons: consolidating domains scattered across several accounts, moving away from a registrar with poor support or opaque pricing, taking control of a domain registered by a developer, or leaving a registrar whose renewal pricing has risen sharply.

The consolidation reason is the strongest for most small businesses, because domains spread across three accounts with different logins are domains that eventually lapse.

A weak reason is a small price difference. The cost of a domain is minor against the disruption of a badly executed move, and the transfer usually adds a year of registration anyway, which changes the comparison.

Transferring away from somebody else

The situation that produces the most anxiety.

Where a developer or agency registered the domain in their own account, the transfer requires their cooperation, since only the account holder can unlock it and produce the code.

Most will do this readily when asked. Where a relationship has ended badly, the position depends on who is recorded as the registrant rather than who holds the account, and it is worth checking the public registration record before assuming either way.

The lesson for anybody not in that situation is to register the domain in the business name from the start, which costs nothing and prevents this entirely.

Afterwards

Three checks, on the day it completes.

That the site loads, that email sends and receives, and that the lock is re-enabled. Then update your access records to reflect the new registrar, since a domain moved and not recorded is a domain nobody can find in two years.

Auto-renewal also needs setting again, since it does not carry across, and a transferred domain that nobody renewed is a worse outcome than the one you were avoiding, which is the same record-keeping discipline as in knowing who can get into what.

Frequently asked questions

What does a domain transfer actually move?

The registration: who you pay and where you manage it. It does not move your website, email, or DNS records, which is the assumption that causes outages.

How do I avoid the site going down?

Record the existing DNS records before starting, and where possible set up matching DNS at the new registrar before initiating the transfer.

What blocks a transfer?

Registration or transfer within the last sixty days, an enabled transfer lock, no authorisation code, a wrong contact address, an expired domain, or recent registrant changes.

Which condition stops most attempts?

A contact address you no longer read, since the approval is sent there and the transfer times out. Correcting it is the first step rather than the last.

How long does it take?

Several days rather than minutes, because the losing registrar has a window to release it. Plan it for a quiet period rather than before a busy season.

What if a developer registered the domain?

The transfer needs their cooperation to unlock it and produce the code. Check the public registration record for who is listed as registrant before assuming your position.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Domains spread across three accounts with different logins?

We consolidate them without taking the site or email down, which is mostly a matter of recording the DNS first.

Start a Conversation