Changing the company that manages your business domain can look like a small admin job. The risk comes when the transfer also changes the services that keep your website and email working.
You can plan a registrar move while keeping your existing website address, hosting and mailboxes. First, establish which services depend on the current provider, whether they can stay in place and what the receiving registrar requires. A successful transfer notification is only one part of the handover.
This guide covers moving an existing domain between registrars. It does not cover changing your business’s domain name or migrating mailbox contents.
Separate the domain registration from the services behind it
A registrar handles your domain registration. As ICANN’s domain name industry guide explains, the registrar and the registry have different roles. Neither should be confused with the company hosting your website or providing your email.
Before approving a move, complete this simple service map:
- Domain registrar. What to identify: The provider managing registration and renewal. What to confirm before moving: Who can authorise the transfer and who will pay future renewals.
- Authoritative DNS. What to identify: The provider publishing the domain’s routing records. What to confirm before moving: Whether its nameservers and DNS service can remain active.
- Website hosting. What to identify: The service running the website. What to confirm before moving: Whether hosting continues independently of the registration.
- Email. What to identify: The provider holding mailboxes and any separate forwarding services. What to confirm before moving: Whether mailboxes, forwarding and sending services remain active.
One supplier may provide everything, or four suppliers may be involved. Ask for written confirmation of what happens to each service when the domain leaves. In particular, check whether DNS or email forwarding is included only while the domain remains registered there.
For example, a business might want to move renewal billing away from an old supplier while keeping its website host and Microsoft 365 account. Make that exact scope clear to both providers before anyone starts a bundled migration.
Check access, renewal and transfer restrictions first
Confirm that an authorised person in your business can access the current registrar account and receive approval messages. Record the domain’s expiry date, current nameservers and receiving account details. Resolve access problems before scheduling technical changes.
For generic domains such as .com, the current ICANN Transfer Policy includes restrictions around the first 60 days after registration and a previous registrar transfer. A qualifying change of registrant also triggers a 60-day transfer lock unless the registrar offers, and the holder takes, an advance opt-out.
That makes the order of work important. If contact details need correcting, ask the registrar how to do that accurately and complete the transfer without an unexpected lock. Do not assume that switching off an ordinary transfer lock removes every restriction.
ICANN’s current implementation tracker still places the Transfer Policy Review in the implementation queue. Do not treat proposed replacement rules as the process already available in your account.
Plan well ahead of renewal. If expiry is close, ask the existing registrar how to keep the registration active while resolving the transfer. Include renewal responsibility, contact verification and payment arrangements in the handover.
Use the right process for a .uk domain
UK domains need particular care because current and future instructions are both available online.
As checked on 20 October 2026, transfers of .uk, .co.uk and .org.uk domains still use IPS tags. The receiving registrar supplies its tag, and the existing registrar changes the domain’s tag to move it. Follow the receiving provider’s preparation steps first.
For example, Cloudflare’s .UK instructions, updated on 13 October 2026, require its transfer checkout to be completed before the IPS tag is changed. They also specify a provider security lock after transfer. Do not assume that every .uk transfer is immediately reversible.
Nominet’s current registrar-change guidance allows receiving registrars to require an acceptance handshake. Where required, an unanswered request is rejected after five days. A tag-change request alone therefore does not prove that the receiving registrar has accepted the domain.
Nominet’s latest transition guidance schedules its new .UK platform for 9 February 2027, including a pull-based inter-registrar transfer process. That remains a future change at the time of this check. For a move near or after that date, confirm the live procedure with both registrars before relying on older IPS-tag instructions.
Decide whether DNS must move too
Ask the receiving registrar: can this domain retain its current nameservers, and can the current DNS provider continue serving the records after the transfer?
If both providers support that arrangement, keeping DNS in place can reduce the number of changes you need to diagnose. Document the agreed nameservers and verify them after completion.
Some destinations require a DNS move. Cloudflare Registrar’s transfer requirements, for example, require the domain to be active on Cloudflare’s authoritative DNS before registration can transfer. This is a provider-specific requirement, not a reason to replace nameservers during every registrar move.
Where DNS must change, treat it as a separate migration with its own preparation and verification. Agree who creates the replacement records, who makes the change, who tests the result and who can correct a failure.
Preserve the complete DNS configuration
Obtain an export or complete record inventory from the current authoritative DNS service. Check website records, mail routing, email authentication, verification records and less obvious subdomains used by booking, CRM or other business services.
Do not rely solely on an automatic import. Cloudflare’s DNS quick-scan documentation explicitly warns that records can be missed, including unusually named subdomains and custom DKIM records. Compare the replacement configuration with the original before changing nameservers.
Keep a record of the working configuration and a recovery plan. If records are edited while the move is being prepared, make sure the replacement receives those changes too.
Include DNSSEC in the plan
DNSSEC adds validation to DNS responses. Changing DNS providers while leaving incompatible security records in place can break resolution. Cloudflare’s DNSSEC troubleshooting guidance identifies a common cause: authoritative nameservers change but the domain’s DS records do not.
Ask the person managing the migration to check the existing DNSSEC state and agree the supported transition with both providers. Record who will verify the final configuration. Avoid improvising security-record changes as a last-minute response to a failed transfer.
Test email separately from the website
A working homepage does not prove that email is healthy. Cloudflare’s email troubleshooting guidance distinguishes mail-routing problems from missing authentication records: MX records direct incoming mail, while missing SPF or DKIM records can also affect delivery.
Preserve the settings required by your actual mail provider and sending services. Do not replace them with a generic example found in a migration guide.
Use a short before-and-after test list:
- Send an email from an external account to a business mailbox, then reply and confirm receipt.
- Check important aliases and forwarding addresses, especially your main enquiries address.
- Submit a clearly identified test website enquiry and confirm that it reaches the expected inbox or CRM.
- Check a website or CRM-generated message, such as a booking acknowledgement, using your own test details.
- Ask the mail administrator to compare authentication results with the working baseline.
Use test records you can identify and remove. Keep the time, route and outcome of each check so a failure can be traced to the correct system.
Close the handover only after the business checks pass
Verify the domain in the receiving account, its expiry date, renewal settings and authorised contacts. Confirm the published nameservers and DNSSEC state against the agreed plan.
Then test the customer journey. Open the main website and www address, check an important service or product page, and complete a representative enquiry, booking or checkout using an appropriate test method. Check from a second connection, such as mobile data, as well as your normal office connection.
Keep the previous services available until the agreed checks pass and you have confirmed that nothing still depends on them. Ask for a clear list of subscriptions to retain or cancel; avoid cancelling an entire old account simply because the registration has moved.
If anything fails, identify the affected layer before making another change. A pending registrar transfer, incorrect nameservers, a missing DNS record, failed mail delivery and an unavailable website host require different investigations. Give the responsible provider the exact address, time, error and test result.
If you need help planning the handover, BuzzBoost’s web development service covers the technical systems behind business websites. Tell us which domain you want to move and which services must keep working, and we can help define the checks and responsibilities before the move begins.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
