A domain transfer is an administrative change, but it can have operational consequences if it is handled without preparation. When you transfer a CO.ZA domain, the aim is to move management to a new accredited registrar while preserving the website, email, DNS configuration and the registrant’s control of the name.

For most organisations, a transfer is prompted by a change in hosting provider, service quality concerns, consolidation of domain portfolios, or a need for stronger account security and support. The transfer itself should not take a website offline. Disruption usually occurs when DNS, contact details, access controls or renewal dates are treated as separate matters rather than part of one controlled change.

Before You Transfer a CO.ZA Domain

Start by confirming who has authority to approve the transfer. The registered domain holder, or an authorised representative, should be able to access the account with the current registrar and receive messages sent to the relevant administrative contact. If those details are outdated, resolve that first. A transfer request sent to an inaccessible mailbox can delay the process and, more seriously, make it harder to distinguish an authorised request from an attempted account takeover.

It is also sensible to record the current configuration before any request is submitted. Keep a copy of the domain name, current registrar, expiry date, nameservers, DNS records, DNSSEC status where applicable, and the contacts responsible for web, email and security operations. This is a change record, not paperwork for its own sake. If a problem is reported after the move, it gives the technical team a known-good reference point.

Check whether the domain has a transfer restriction. A registrar-level transfer lock, a registry status that prevents transfer, an unresolved payment issue, or an ongoing registrant update may need to be addressed before the new registrar can proceed. The exact labels displayed in a registrar portal can differ, so ask the registrar to explain both the status and the action required to remove it.

Where your registrar uses an authorisation code or similar transfer credential, obtain it through the established account process and treat it as sensitive information. Do not share it in broad email threads or store it in an unsecured document. A transfer credential can be one part of the control used to move a valuable online identity.

A useful pre-transfer check covers five areas:

• the registrant and administrative contact details are accurate and accessible;
• the domain is not subject to a transfer restriction or unresolved account matter;
• nameservers, DNS records and DNSSEC settings have been documented;
• the expiry date and renewal arrangements are understood; and
• the organisation knows which people may approve the request and make DNS changes.

Separate the Domain Transfer From DNS Changes

A common source of avoidable outages is changing registrar, nameservers and web hosting at the same time. These are related services, but they are not the same operation.

If the nameservers remain unchanged, a registrar transfer should normally leave the public DNS delegation in place. Your website and email should continue to resolve through the existing DNS provider. This is often the lowest-risk route: complete the transfer first, verify that management has moved correctly, then schedule any DNS or hosting migration under its own change plan.

If you must change nameservers as part of the project, prepare the DNS zone at the new provider before updating the delegation. Compare records carefully, including A and AAAA records, MX records, TXT records for SPF, DKIM and domain verification, CNAME records, and any records used by third-party applications. Missing a single mail-related TXT record can cause authentication failures that are less visible than a website outage but just as damaging.

Lowering DNS time-to-live values in advance can help reduce the period during which resolvers retain old records. It does not remove the need for planning, and it does not guarantee instant global change. Keep the old DNS service active until the new delegation and records have been checked from more than one network.

DNSSEC requires particular care. A signed zone depends on coordination between the DNS operator and the parent-zone delegation. Do not remove, replace or publish delegation signer information casually during a registrar move. Where DNSSEC is enabled, agree the sequence with the registrar and DNS provider, and validate the domain after each planned change. A DNSSEC error can make a correctly hosted website appear unavailable to validating resolvers.

The Registrar Transfer Process

CO.ZA domains are registered and managed through accredited registrars. The registry operates the shared technical infrastructure and registry policy framework, while the registrar handles the customer-facing transfer request, verification, billing and account access. ZARC operates this registry infrastructure for the commercial .ZA namespaces, but domain holders should begin transfer support with their registrar.

The gaining registrar will explain its transfer workflow and any information it requires. In practical terms, this usually involves opening an account with the new registrar, submitting the domain name and required transfer authorisation, and confirming that the requester has the right to act for the registrant. The losing registrar may also issue a notification or require confirmation under its account procedures.

Read every transfer message rather than approving it automatically. Confirm that the domain name, receiving registrar and registrant details are correct. If a request arrives unexpectedly, decline it where possible and contact the current registrar using a trusted support route. Do not rely on contact details contained only in the unexpected message.

Transfer timing depends on the registrar processes, domain status and whether further validation is needed. Avoid initiating a transfer at the last possible moment before expiry, during a major website launch, or while the organisation is responding to a security incident. A short period of overlap between the operational deadline and the planned transfer gives teams room to resolve exceptions without rushing DNS or contact changes.

Renewal and transfer are also distinct. Some registrar commercial terms may differ on how renewal dates, fees or account credits are handled. Confirm the domain’s expiry date before submission and ask the gaining registrar how it will present the term after completion. Do not assume that a transfer automatically changes the expiry date in a particular way.

Verify Control After the Move

Completion is not the final task. Once the new registrar confirms the transfer, sign in to the new account and verify the domain details directly. Check that the registrant information is correct, the intended nameservers are present, and authorised staff have the right level of access.

Test the services that matter to the organisation. Resolve the domain and relevant subdomains, load the website over its normal addresses, send and receive email using the domain, and check any business systems that depend on DNS-based verification. For a domain used by an online shop, school, municipality or not-for-profit, this may include payment services, remote access, customer portals and email marketing platforms.

Review security controls at the same time. Enable multi-factor authentication where the registrar supports it, remove former employees or suppliers from the account, use unique credentials, and limit the number of people who can approve transfers or alter nameservers. If the domain is business-critical, ask the registrar about additional protection such as registry lock or account-level transfer controls. These measures add administrative steps, but that is often an appropriate trade-off for a name tied to public services, revenue or organisational trust.

When a Transfer Needs Extra Care

Some situations warrant a more formal change process. A domain that supports high-volume email, a public-facing service, a large brand portfolio, or systems with DNSSEC should have an agreed maintenance window, named technical owners and a rollback plan. In these cases, the question is not simply whether the transfer can be completed, but whether the organisation can detect and contain an unexpected change quickly.

If ownership is disputed, registrant details are inaccurate, or the current registrar account is inaccessible, do not attempt to work around the issue through informal requests. Preserve relevant records and use the registrar’s documented escalation and dispute procedures. Clear evidence and accurate contact information are central to protecting the integrity of the namespace.

A well-managed domain transfer is quiet by design. Keep DNS stable unless a change is necessary, verify each approval, and retain control of the account before and after the move. That discipline protects more than a domain name: it protects the online services and public confidence attached to it.