Understand exactly what is moving
A domain registrar maintains the commercial registration of a name. Authoritative DNS answers queries for that name; web hosting serves pages; a mail platform stores and routes messages. Moving the registration from one registrar to another does not inherently move any of the other three services. Treat a registrar transfer as a change in who administers the registration, not a website migration.
An interruption usually follows a separate configuration change: nameservers replaced without copying records, an expired hosting account, a broken DNSSEC chain or a mail record omitted from the new zone. A Malaysian company planning a transfer should first write down which provider currently performs each function. That map determines whether the simplest safe plan is to leave every DNS and hosting setting unchanged.
Confirm the business reason before initiating
Good reasons to transfer include consolidating renewal administration, restoring direct business control of the registrant account, obtaining clearer billing records or changing a registrar whose support no longer meets operational needs. A lower advertised price alone is insufficient: compare subsequent renewal terms, domain-extension support, access controls, assistance with transfers and the ability to export account records.
If the only objective is faster website hosting or better email, changing registrar may not help. Hosting and mail providers can often be changed without transferring registration, while a DNS provider can sometimes be changed separately. Decide which problem actually needs solving; combining unrelated migrations makes it harder to determine why a failure occurred and which vendor must fix it.
Create a current domain and service inventory
Record the exact domain spelling and extension, registrar, registrant organisation, administrative contact, renewal date, transfer status, nameservers, DNS operator, web host, mail provider and any domain-linked services. Include subdomains used for customer portals, booking, verification, payment callbacks or staff tools. Save a dated copy of the inventory in a business-controlled location rather than only in a contractor's personal account.
Inspect both the public DNS answers and the authoritative provider's zone interface. Public lookup results can miss records that are not commonly queried, and an automated import may omit obscure TXT, SRV or CAA entries. Inventory website A, AAAA and CNAME records; MX and mail hostnames; SPF, DKIM and DMARC; verification tokens; and DNSSEC delegation details before anyone changes nameservers.
Separate ownership from administrative access
The registered name holder should be the authorised business entity or person under the relevant registry rules, not automatically the developer who built the site. Check the legal registrant and whether the company can access the registrar account, billing contact, approval inbox and recovery methods. A transfer cannot be managed safely if only a former employee or agency can receive required confirmation messages.
Assign one transfer owner, one technical verifier and an escalation contact. The transfer owner controls authorisation codes and registrar approval; the technical verifier checks DNS, website and email before and after. Where one person fills multiple roles, use a written checklist and record timestamps. Never send a transfer code in an open support ticket or to an unverified third party.
Check whether the extension can transfer now
Rules vary by top-level domain. For many generic domains, ICANN's Transfer Policy permits certain transfer denials, including recent registration or previous transfers within specified periods, applicable change-of-registrant locks, disputes and other defined circumstances. These are not universal instructions for every country-code domain. Ask both the current and receiving registrars to confirm eligibility for the exact extension.
For Malaysian .my-family names, consult MYNIC's transfer-registrar policy and an appointed registrar's current procedure. MYNIC distinguishes a change of registrar from a change of registrant or a move between account holders. Do not treat those operations as interchangeable. Verify any eligibility documents, expiry constraints, role permissions, transfer charges and registration-term effects directly before paying or submitting the request.
Inspect expiry and renewal timing
A domain close to expiry presents unnecessary operational risk during a transfer. Check the registry-reported expiry date, current registrar invoice status and any automatic renewal setting. Determine whether the transfer includes an additional registration period and whether the extension has exceptions. Do not assume a transfer fee, extension or completion date is identical across .com, .my and other names.
If renewal is imminent, ask the relevant registrars whether renewal should occur before transfer and whether it creates a temporary restriction. Keep proof of payment and the renewed expiry date. Avoid a plan that relies on a transfer finishing just before an important customer launch, payroll cycle or marketing event. A routine registrar change should have time to fail safely.
Review locks and transfer authorisation
Registrar locks are protective controls, not evidence that a domain is broken. A generic domain may display clientTransferProhibited while transfer is disabled. When ready, the authorised holder can follow the registrar's documented process to unlock it and obtain the unique AuthInfo or EPP code. Verify that the code is current, copied accurately and entered only into the intended receiving registrar's secure interface.
Do not unlock days earlier than necessary or leave an authorisation code in a shared spreadsheet. If a transfer is refused, request the exact status and policy reason instead of repeatedly changing DNS. Under ICANN's current policy, applicable registrars have duties concerning access to AuthInfo codes and removal of transfer-prohibited status; the extension and particular circumstances still govern what can proceed.
Keep approval communications accessible
Transfer requests can require action through a registrar dashboard or messages sent to registration contacts. Before starting, verify that the destination for notices works and is monitored. If the company's primary email uses the very domain being transferred, arrange an independent recovery or administrative contact where the provider permits it; otherwise a DNS incident could also prevent receipt of transfer instructions.
Be alert to phishing: a fraudulent transfer email may resemble a real registrar notification. Open the registrar portal through a known bookmark, inspect the requested domain and account, and confirm the timing with the designated transfer owner. Record which approvals were granted, by whom and when. Never interpret silence or an unfamiliar email as sufficient proof that the process completed.
Preserve nameservers when no DNS migration is needed
For a straightforward registrar change, retaining the existing authoritative nameservers is usually the least disruptive approach if both registrars support it. Confirm the receiving registrar can retain those nameservers and that the DNS service will remain active independently of the old registrar account. A nameserver value can remain the same while the service behind it is cancelled, so verify the commercial relationship too.
Do not accept a default DNS zone or parking-page nameservers merely because they appear during checkout. Ask the receiving registrar to show the final delegation values before submission. Compare them character for character with the recorded originals. If the old registrar also provides DNS that ends when registration leaves, plan a separate, tested DNS migration first rather than assuming continued service.
Handle DNS-provider changes as a separate project
If the existing DNS service cannot survive the registrar transfer, create the complete replacement zone before altering delegation. Copy records from the authoritative source and verify each name, record type, value, priority, proxy setting and TTL. Review non-obvious records for subdomains, third-party verification, DKIM selectors and certificate authority restrictions. An automated scan is a starting point, not a complete backup.
Choose a controlled cutover window, keep the old DNS zone operational during cache transition and test the new authoritative servers directly. Do not simultaneously change hosting IPs, email platform and nameservers unless the migration has its own validated runbook. A DNS provider migration may affect customers even when the registrar transfer itself is administratively successful.
Understand TTL and cached answers
DNS time to live controls how long recursive resolvers may cache an answer. Lowering a relevant record's TTL in advance can reduce the expected cache period for a later value change, but it does not make a nameserver switch instantaneous or override caches that already stored the old answer. Cloudflare documents separate TTL behaviour for ordinary records and nameserver-related settings.
For a registration-only transfer that retains nameservers and record values, lowering every TTL usually offers no benefit. If DNS must change, record the original TTL, adjust only where supported and allow enough time for older cached responses to age out. Test from more than one resolver and network. A local successful lookup does not prove every customer's resolver has refreshed.
Treat DNSSEC as a dependency, not an afterthought
DNSSEC uses signatures and a chain of trust to help resolvers validate DNS data. A DS record at the parent zone can bind the domain to keys used by its authoritative DNS operator. If nameservers or signing keys change without coordinating the DS record, validating resolvers may return SERVFAIL even though the new zone contains correct A and MX records.
If the nameservers and signing setup remain unchanged, avoid unnecessary DNSSEC changes. When a DNS migration is required, follow the outgoing and incoming providers' documented DNSSEC sequence and wait for relevant cache periods. Record the current DS and DNSKEY information and verify signed resolution afterward. Disabling DNSSEC casually to fix a transfer warning can weaken protections and conceal the real configuration problem.
Protect incoming business email
Incoming mail delivery depends on the domain's MX records and the availability of the named mail hosts. A registrar transfer does not copy mailboxes or automatically move stored messages. If the same DNS and mail provider remain active, mail should continue following the same MX routing; nonetheless, record existing MX priorities, mail-host A or AAAA records and the mail provider's required settings.
Before and after the transfer, send test messages from an unrelated external mailbox to representative business addresses. Verify receipt, delivery timing and any bounce notifications. Include aliases and shared addresses if they are critical to enquiries. If mail fails, compare live MX answers with the documented provider configuration and check whether the provider's service subscription remained active.
Protect outgoing mail authentication
SPF, DKIM and DMARC are commonly published as DNS TXT records, sometimes across multiple hostnames. They support sender authorisation, message signature verification and domain-based policy or reporting. Omitting a DKIM selector or publishing a conflicting SPF record during a DNS migration can cause legitimate business messages to fail checks or land in spam even while inbound mail appears normal.
Keep a complete list of authorised sending systems: primary mailbox platform, website contact form, invoicing service and any approved transactional provider. After a DNS change, inspect their required records and send controlled outbound tests to external accounts. Do not replace a provider-supplied record with a guessed template. A registrar-only transfer with unchanged DNS should not require rewriting these records.
Protect the website, HTTPS and subdomains
Record how the apex domain and www hostname reach the site, including any CDN or reverse proxy. Confirm the web-hosting subscription, application and TLS certificate renewal mechanism remain active. A domain transfer does not rebuild a website or copy a database. An accidental change to A, AAAA or CNAME records can point customers at the wrong server or an unfinished holding page.
Test the homepage, important service pages, HTTPS certificate, redirects and a representative form without submitting sensitive customer data. Check critical subdomains separately; a working homepage does not prove that a booking portal or staff login is reachable. Keep a dated list of expected responses so a later change can be compared with actual behaviour rather than memory.
Choose a quiet window and establish a baseline
Schedule the request away from high-value business periods, and inform the people responsible for the website and email that a registration change is in progress. A transfer may take several days depending on registry and registrar procedures. Do not promise zero downtime: keeping DNS stable reduces risk, but provider failures, missed approvals and unrelated expirations remain possible.
Before submission, capture registrar status, nameserver delegation, DNS answers, mail delivery tests, website availability and current expiry date. Note the time zone used for timestamps. Set a checkpoint for pending status and a later post-completion check. This baseline makes it possible to distinguish a new fault from a pre-existing problem.
Submit the request through the receiving registrar
Use the intended registrar's authenticated transfer workflow. Enter the exact domain, supply the authorisation code only when prompted and review the displayed price, term and contacts. Confirm the destination registrar supports the extension and the nameserver arrangement. Save the order or transaction reference without exposing secret credentials in shared documentation.
Monitor both registrar dashboards and verified administrative notices. Some workflows ask the losing registrar to approve or release a request, while others complete after a waiting period. Do not infer completion from payment alone. If the process stalls, collect the transfer status, timestamps and any rejection reason before contacting support. Avoid launching a second conflicting transfer.
Monitor without changing unrelated settings
While a request is pending, periodically check that the domain still resolves through the expected nameservers, the website loads over HTTPS and test mail can be sent and received. The aim is to detect an unexpected change, not to tweak DNS repeatedly. Keep a concise incident log with symptoms, affected services, test method and time.
If only one resolver reports an old answer, compare authoritative DNS with cached results before assuming the whole site is down. If every resolver fails with DNSSEC validation errors, investigate the DS chain. If the website works but mail fails, inspect MX and mail-host records first. These observations direct the right provider to the right problem.
Prepare a realistic recovery path
A completed registrar transfer may not be immediately reversible through an ordinary second transfer because some extensions apply post-transfer restrictions. The practical recovery plan is therefore to preserve DNS access, provider subscriptions and account credentials, not assume an instant registrar rollback. Document who can restore a zone, correct delegation and contact both registrars.
If the transfer fails before completion, leave working nameservers and hosting untouched while resolving eligibility or authorisation issues. If DNS changed unexpectedly, restore the known-good delegation or records according to the DNS provider's procedure and account for caching. If an expiry issue appears, prioritise renewal and registry status verification rather than buying a new hosting plan.
Verify completion and secure the new account
Once the receiving registrar reports completion, independently verify the registrar of record where authoritative registration data is available, the expiry date, registrant details and nameserver delegation. Recheck web, HTTPS, critical subdomains, inbound and outbound mail, and DNSSEC if enabled. Record which checks passed, which were not applicable and any remaining uncertainty.
Enable appropriate multi-factor authentication and registrar lock at the new provider, review account recovery contacts and set a renewal reminder under company control. Store invoices and transfer records in the business's approved document system. Do not cancel an old DNS or hosting subscription until you have confirmed it is no longer serving a required function.
A practical Malaysian SME example and decision checklist
Consider a hypothetical Selangor design studio using a .com.my domain registered with one provider, DNS at a second provider and business mail at a third. It wants consolidated renewal billing but not a new website or mail platform. The safe first question is whether the receiving registrar can retain the existing nameservers and whether MYNIC rules permit the transfer at the present registration stage.
The owner records all three suppliers, checks the administrative contact and transfer code procedure, verifies MX and website baselines, and schedules the request outside client deadlines. After completion the owner checks the registrar and expiry details while a colleague verifies external mail and HTTPS. If nameservers or DNS service must change, that becomes a separate documented project with its own acceptance checks.
Questions to ask before calling the job finished
Can the business prove who the registrant is, who can approve the transfer and which company will bill the next renewal? Are the current authoritative nameservers still active, and does the new registrar show the expected delegation? Have the website, mail reception, mail sending and critical subdomains been tested from outside the company's network? These questions are more meaningful than a dashboard label alone.
Finally, note what was not verified: a provider-specific extension rule, an obscure third-party DNS record, a future renewal amount or an untested legacy application. Ask the responsible specialist to close those gaps before treating the project as fully accepted. A successful registrar transfer is a controlled administrative change supported by evidence, not a guarantee that every related digital service is healthy.
Sources & further reading
- ICANN Transfer Policy
- ICANN FAQs for Domain Registrants: Transfers
- MYNIC Transfer Registrar Policy
- MYNIC Managing a Domain
- MYNIC Appointed Registrars
- Cloudflare Registrar Transfer Guide
- Cloudflare DNS Record TTL Reference
- Cloudflare Email DNS Records
- Cloudflare DNSSEC Troubleshooting
- cPanel Zone Editor Documentation