A short explanation at onboarding can make later decisions easier, especially when a business changes agencies, replaces a staff member, or moves to another registrar.
For a planned move, NiceNIC's domain transfer service provides a starting point. The first step is to identify exactly what the client wants to change.
Explain the Difference Between a Domain and Its Services
Use a simple description:
“The domain is your website address. Hosting stores and serves the website. Email is a separate service that can use the same address. DNS connects the domain to those services.”
Then explain the organisations involved:
- The registry operates the central system for an extension.
- The registrar manages the customer's domain registration.
- A hosting or email provider supplies the corresponding service.
- An agency or reseller may help coordinate and administer them.
One company may perform several roles, but the roles remain different.
This helps clients understand why moving a domain registration does not automatically copy website files or mailboxes.
What Does "Owning a Domain" Mean?
Clients commonly use “ownership” to describe holding a domain. More precisely, a domain registration provides rights to use the name under the relevant registration agreement and policies for a renewable term.
It is not a permanent purchase with no future obligations.
The intended person or organisation should be accurately identified as the registrant. An invoice, a website login, or access to a hosting account should not be treated as a substitute for checking registration details.
A useful explanation is:
“Your company is the intended domain holder. Our role is to manage the agreed tasks on your behalf. We will document access, renewal responsibilities, and the process for changing providers.”
Check that this description matches the actual account and registration arrangement.
Separate Registration Details from Account Access
A client may be the registered holder while an agency controls the account used to manage the domain.
That arrangement needs clear documentation. Record who can approve changes, who receives notifications, and how the client can regain direct control if the relationship ends.
Use recovery arrangements that can survive staff turnover. An employee’s personal mailbox should not become the only route to a business-critical account.
Explain privacy carefully too. Hidden public contact information does not mean that the registrar has no registrant information. Accurate underlying details remain necessary.
Clarify What the Client Means by "Transfer"
The word can describe several different tasks:
Changing registrars: Moving registration management from one registrar to another.
Changing the registrant: Updating who holds the registration.
Moving between accounts: Changing the account managing the domain within a provider’s system.
Moving hosting or email: Migrating website or mailbox services.
A client may need one of these operations or a coordinated sequence. Ask about the intended outcome before requesting codes or changing contact details.
For example, “We are changing web designers” does not necessarily mean the domain needs a new registrar.
Explain Transfer Locks Before Making Changes
For generic domains governed by ICANN’s Transfer Policy, a registrar may deny a transfer within 60 days of initial registration or a previous inter-registrar transfer, subject to the policy’s provisions.
A Change of Registrant can also trigger a 60-day inter-registrar transfer lock. A registrar may offer an opt-out before that change, but it is not required to offer one.
These situations differ from a routine account-controlled transfer lock. Turning off an ordinary lock does not necessarily remove a policy-based restriction.
Before changing registrant information for a planned move, confirm the sequence with the registrar. Where appropriate, transferring first may avoid triggering a new Change of Registrant lock.
Do not apply this explanation automatically to every country-code extension. ccTLD transfer procedures follow their applicable registry rules.
What Is an Authorization Code?
An authorization code may also be called an Auth-Code, AuthInfo code, EPP code, or transfer code.
For many generic domains, it is part of the process used to authorise a move to another registrar. It is not the account password, and possessing it does not eliminate other transfer requirements.
Treat it as sensitive information and share it only through the approved transfer process.
ICANN states that registrars must provide an Auth-Code within five calendar days of a valid request. That deadline concerns providing the code; it is not a guarantee that the entire transfer will finish within five days.
Some country-code domains use a different process, so check the extension before asking the client for an EPP code.
How Can You Explain the Transfer Process Clearly?
Give the client a short plan covering the work and required approvals.
A typical generic-domain transfer involves checking eligibility, confirming access to the relevant account and contact channels, obtaining the authorization code, removing an ordinary transfer lock where appropriate, and submitting the request to the receiving registrar.
The client should know how to recognise genuine approval messages and where to ask if a message is unexpected.
Avoid promising an immediate completion date. An invalid code, a restriction, or an unresolved verification issue can require additional work.
Once complete, verify the receiving account, registrar information, expiration date, and renewal settings.
Will the Website or Email Stop Working?
A registrar transfer does not inherently require changing nameservers. However, service continuity depends on the existing DNS, hosting, and email arrangements remaining active.
In particular, check whether the old provider’s DNS service will continue after the domain leaves. Unchanged nameserver addresses are not sufficient if the underlying service is discontinued.
Before the move:
- Record the active nameservers and DNS configuration.
- Identify the website and email providers.
- Confirm which services remain active.
- Plan any necessary DNS migration separately.
- Review DNSSEC if the DNS provider will change.
Afterward, test the website and email rather than relying solely on a successful transfer status.
Do not cancel old services until their replacements have been verified.
Give the Client a Handover Summary
A useful handover record identifies the domain holder, managing registrar, responsible account, renewal date, DNS provider, and website and email providers.
It should also state who handles future changes and which access permissions have been removed or retained.
Keep secrets outside the general handover document. Use a secure process for credentials and recovery information.
Invite the client to confirm that they can access the agreed account and understand the next renewal responsibility. This is a practical check that the handover works.
Make Education Part of Normal Service
Explain the essentials when the domain is first registered, revisit them before a transfer, and update the record when the client’s organisation changes.
Measure whether this reduces missing approvals, incomplete handovers, and repeated support questions. Do not assume that sending a long guide means the client understood it.
For a move to NiceNIC, the domain transfer page can support the transaction, while the agency's role is to keep the client informed about scope, approvals, dependencies, and completion.
