Moving a domain to a new provider sounds risky, and it is the part of leaving a web company that people put off longest. In practice it is a short, well-defined process — as long as you understand one thing first, which most guides skip past.
Transferring a domain does not move your website or your email. The transfer moves who bills you and who manages the name. What controls where your site and email actually live is DNS. Get those two ideas separate in your head and nothing else about this is difficult.
Before you start: three things to check
- Is the domain close to expiry? Do not start a transfer in the last couple of weeks of a term. If it lapses mid-process you have a much bigger problem. Renew first if you are close, then transfer.
- Do you actually control it? The registrant contact email on the domain needs to be one you can read. If it points at a former employee or a web company you have parted with, sort that out before anything else.
- Do you know what your DNS currently does? Write down your existing records — particularly your MX records for email — before you touch anything. A screenshot of the current DNS zone is the cheapest insurance in this whole exercise.
Transferring a .nz domain
New Zealand domains work differently from .com, and rather more pleasantly. The mechanism is the UDAI — Unique Domain Authentication ID, sometimes called a domain secret.
- Get the UDAI from your current provider. Most give it to you in their control panel. Some require you to ask, and they are obliged to provide it. It is a short code, and it is specific to that one domain.
- Start the transfer with your new provider and enter the UDAI when prompted.
- Wait — but not long. .nz transfers are typically completed within minutes to a couple of hours, not days.
Two details that make .nz easier than most extensions: there is no 60-day lock after registration, and transferring does not change your expiry date. You keep the term you already paid for. A .nz transfer is also generally free, which is not true everywhere.
If your provider is dragging their feet on releasing a UDAI, the Domain Name Commission publishes guidance on your rights as a registrant, and that is the right place to escalate.
Transferring a .com, .net or .org
These follow the international process, which has more steps and more waiting:
- Unlock the domain at your current provider. Registrar lock is on by default.
- Turn off domain privacy temporarily, if you have it. The transfer confirmation email often cannot reach you otherwise.
- Request the authorisation code — the EPP code or auth code. It is the equivalent of a UDAI.
- Start the transfer with the new provider and supply the code.
- Approve the confirmation email sent to the registrant address. This is where most transfers stall, because nobody is reading that mailbox.
- Wait up to five days. The losing registrar has a window to release it, and some use all of it.
Two restrictions to plan around: a .com cannot be transferred within 60 days of being registered, or within 60 days of a previous transfer, or after a change of registrant contact details. And a .com transfer normally adds a year to your registration, which you pay for — so it is not free, but you are not losing the time either.
Keeping your website and email up during the move
This is where the real risk sits, and it is entirely avoidable.
When a domain moves, the new provider may apply their own default DNS — which will not know about your website or your mailboxes. If that happens, your site goes to a parking page and your email starts bouncing. The fix is to prepare, not to react.
- Record your current DNS zone before you begin. Every record: A, CNAME, MX, TXT, the lot. Screenshot it.
- Recreate those records at the new provider before the transfer completes, or immediately after, so there is nothing to restore from memory.
- Pay particular attention to MX and TXT records. MX routes your mail. The TXT records carry SPF, DKIM and DMARC — miss them and your outgoing email starts landing in spam folders, which is a subtle failure you may not notice for days.
- Do not change hosting on the same day. Move the domain, confirm everything still works, then move the hosting. One variable at a time. If something breaks you will know instantly what caused it.
- Allow for propagation. DNS changes take time to reach everyone — usually minutes, occasionally up to 24 hours. During that window some people see the old destination and some the new. That is normal, not a fault.
Common problems and what they mean
- “Transfer rejected.” Usually the domain is still locked, or the auth code has expired. Codes are often time-limited — request a fresh one.
- “Domain is not eligible.” Almost always the 60-day rule on a .com, or a recent change of registrant details.
- Nothing happens for days. Check the registrant email, including spam. An unanswered confirmation is the single most common cause of a stalled transfer.
- Email stops working right after the move. MX records were not carried across. Restore them from your screenshot; mail resumes once DNS propagates. Nothing sent in the meantime is normally lost — sending servers retry for a day or more.
- Your provider will not release the domain. For .nz, take it to the Domain Name Commission. For gTLDs, ICANN has a transfer dispute process. Both exist precisely because this happens.
Should you transfer at all?
Consolidating domains, hosting and email with one provider is worth doing for a practical reason rather than an ideological one: when something breaks at 9pm, one phone call beats three, and nobody can tell you it is the other company’s fault.
The exception is if you are mid-way through a website rebuild. Finish that first. Do not run two changes at once.
If you would like to move a domain across and would rather someone checked your DNS before and after, start a transfer with us or talk to our team first — we will look at your current records and tell you honestly whether it is a five-minute job or one worth planning.
