Zero-Downtime Transfers
For New Zealand businesses, your domain name is more than just a digital address; it is a critical asset that dictates email deliverability, e-commerce revenue, and brand reputation. The prospect of transferring a domain often induces anxiety regarding service interruptions. However, with precise technical execution, a seamless transition is entirely achievable.
To transfer a domain with no downtime in NZ, you must lower your DNS Time-to-Live (TTL) settings to 300 seconds at least 48 hours prior to the move. Ensure your new registrar has identical Zone Records (A, CNAME, MX) configured before switching nameservers to maintain continuous service availability.
The Risks of Transferring Active Business Domains
Transferring a domain name is a standard administrative procedure, yet when handled without a strategic framework, it introduces significant operational risks. For New Zealand enterprises, particularly those relying on .nz extensions for local SEO dominance, “downtime” translates directly to lost revenue and eroded trust.
When a domain transfer is mismanaged, three primary failures typically occur:
- Email Blackouts: If Mail Exchange (MX) records are not perfectly replicated at the destination DNS zone, emails from clients and suppliers will bounce. In the NZ market, where relationships are key, missing a tender document or a customer inquiry can be disastrous.
- Website Inaccessibility: Users attempting to visit your site may encounter standard browser error messages (NXDOMAIN), leading them to assume the business has ceased operations.
- SSL Certificate Failure: If the SSL/TLS certificate is not re-issued or installed correctly on the new host immediately, visitors will see security warnings, severely impacting conversion rates and brand authority.
Understanding these risks is the first step toward mitigation. The goal of a “zero-downtime” transfer is to ensure that at any given second during the migration, a user somewhere in the world can resolve your domain to a working server—whether that is the old one or the new one.
DNS Propagation Explained for NZ SMEs
To master a zero-downtime transfer, one must understand the mechanics of the Domain Name System (DNS). Often described as the internet’s phonebook, DNS translates human-readable domain names (like yourbusiness.co.nz) into IP addresses that computers use to identify each other.
Why Propagation Takes Time
DNS relies heavily on caching to function efficiently. When a user in Auckland visits your website, their ISP (Internet Service Provider) stores the location of your website for a set period. This prevents the ISP from needing to look up your address every single time the user clicks a link.
When you change your domain’s nameservers (the instruction that tells the internet where your DNS records are kept), this change does not happen instantly. It ripples across the internet. This process is known as propagation.
For New Zealand businesses, propagation can be idiosyncratic. While local ISPs like Spark, One NZ, and 2degrees update their records relatively quickly, international traffic may cache old data for longer. During this transition period, some users will be directed to your old host, while others will be directed to your new host. This “split-brain” scenario is normal, but if both hosts are not configured to serve the site, downtime occurs.
Pre-Transfer Checklist: The Critical TTL Strategy
The secret to a seamless transfer lies in the preparation phase, specifically in manipulating the Time-to-Live (TTL) settings. The TTL value tells ISPs how long they should cache your DNS records before checking for an update.
Step 1: Audit Current DNS Records
Before initiating any transfer, log in to your current registrar and export a complete list of your DNS zone file. This includes:
- A Records: The IP address of your website.
- CNAME Records: Aliases for subdomains (e.g.,
wwworblog). - MX Records: Directs email traffic.
- TXT Records: Crucial for email authentication (SPF, DKIM, DMARC).
Step 2: Lower TTL Values
Standard TTL settings are often set to 14400 seconds (4 hours) or even 86400 seconds (24 hours). If you change your nameservers with a 24-hour TTL, it could take a full day for the switch to be recognized globally.
Action: At least 48 hours before your planned transfer:
- Access your current DNS management console.
- Locate the TTL field for your A records and MX records.
- Change the value to 300 seconds (5 minutes).
By lowering the TTL, you are telling ISPs: “Only remember this location for 5 minutes.” This ensures that when you eventually flip the switch, the internet will pick up the change almost immediately.
Step 3: Prepare the Destination
Crucial Step: Set up your zone records at the new DNS provider before you change the nameservers. Most premium registrars and managed DNS providers allow you to create a zone file for a domain that is not yet pointed to them.
Recreate every record from your audit in Step 1 at the new provider. This creates a safety net. When the nameservers change, the new provider is already waiting with the correct map to your website and email.
Managing Email Records (MX) During the Switch
Email is the lifeblood of modern NZ commerce. Losing email connectivity is often more damaging than a website going offline. The complexity of email transfers depends on whether you are moving just the domain registration or the email hosting as well.
Scenario A: Transferring Domain Only (Email Host Stays the Same)
If you use Microsoft 365 or Google Workspace and are simply moving your domain from one registrar (e.g., Freeparking) to another (e.g., SiteHost), the process is straightforward.
Ensure that the MX records at your new DNS provider match exactly what is currently set. Do not rely on default settings provided by the new registrar. If you use Google Workspace, your MX records must explicitly point to Google’s servers, not the new registrar’s webmail servers.
Scenario B: Changing Email Providers
If you are migrating email contents (e.g., from cPanel email to Office 365) simultaneously with the domain transfer, the risk profile increases. In this scenario, you should perform the email migration before the domain transfer if possible, or use a dual-delivery method.
The SPF/DKIM Trap: When moving DNS, ensure your TXT records for SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) are copied over. Failing to do so will result in your legitimate business emails landing in your clients’ spam folders.
Executing the Transfer: UDAI and Registry Locks
Once your TTL is lowered and your destination zone file is cloned, you are ready to execute the transfer. For .nz domains, this process is governed by the InternetNZ policies.
1. Unlock the Domain
Log in to your current registrar and disable the “Registrar Lock” or “Client Transfer Prohibited” status. This security feature prevents unauthorized transfers.
2. Obtain the UDAI
For New Zealand domains, you need a Unique Domain Authentication ID (UDAI). This is an 8-character code generated by the current registrar. It acts as the password for the domain. Ensure the UDAI is valid (they typically expire after 30 days).
3. Initiate the Transfer
Go to your new registrar and purchase the transfer. You will be prompted to enter the domain name and the UDAI. Because .nz transfers are often near-instantaneous upon UDAI validation, the preparation you did in the previous steps is vital.
4. Update Nameservers
Once the domain is in the new registrar’s control, update the nameservers to point to the new DNS provider (where you pre-configured the records). Because your TTL was set to 300 seconds, the world will start seeing this change within 5 minutes.
Post-Transfer Testing Protocols
The transfer is not complete until verified. Do not assume success based on your own browser, which may still be caching old data.
Global Propagation Checks
Use tools like whatsmydns.net or the local NZ equivalent to check how different servers around the world see your domain. You want to see a uniform update to the new IP address.
Email Deliverability Tests
Send test emails to and from external accounts (Gmail, Outlook). Check the headers of the received emails to ensure that SPF and DKIM are passing. This verifies that your new DNS TXT records are propagating correctly.
SSL Verification
Ensure your website loads over HTTPS. If you changed hosting providers along with the domain, you may need to force a reissue of the Let’s Encrypt or paid SSL certificate now that the DNS points to the new server.
Once you have confirmed stability for 24-48 hours, you can increase your TTL settings back to a standard 14400 or 86400 seconds to reduce the load on your nameservers.
People Also Ask
How long does a .nz domain transfer take?
Unlike .com domains which can take 5-7 days, .nz domain transfers are typically completed rapidly, often within minutes to a few hours, provided the UDAI is valid and the domain is unlocked.
What is a UDAI code and where do I find it?
The UDAI (Unique Domain Authentication ID) is an 8-character authorization code required to transfer any .nz domain. You can find it in your current registrar’s management portal or by requesting it from their support team.
Will my email stop working during a domain transfer?
If managed correctly, your email will not stop working. However, if you fail to copy MX records to the new host or don’t lower TTL settings, you may experience bounces or lost emails during the propagation window.
Can I transfer a domain that expired yesterday?
Generally, yes. Most registrars offer a grace period during which you can still transfer the domain. However, it is safer to renew it first to prevent the domain from entering the “Redemption Period,” which incurs higher fees.
Do I need to transfer my web hosting when I transfer my domain?
No. Domain registration and web hosting are separate services. You can keep your website hosted with Provider A while moving your domain registration to Provider B. You simply need to point the DNS A-records to Provider A’s IP address.
What is the best TTL setting for a domain transfer?
The recommended TTL setting for a pending transfer is 300 seconds (5 minutes). This allows for rapid recovery if any errors are detected during the switch. Remember to revert this to a higher value (e.g., 14400) after the transfer is stable.
