Before you start
Identify the domain holder, registrar, current nameservers and email provider. Export the DNS zone and retain a consistent file and SQL backup. Do not include a transfer authorisation code in a public enquiry.
Inventory every service first
Record the names used by the website, subdomains, mail and third-party applications. Keep values, types, priorities and TTLs in a dated document. A screenshot of the homepage is not enough: TXT records can verify ownership of services that are easy to overlook. Check that you retain access to restore the previous configuration. Do not cancel the old hosting until the destination has been tested and the transition has been reviewed.
Separate website addresses from mail routing
An A record maps a name to IPv4; AAAA maps it to IPv6. CNAME points to another name, not a full URL containing a path. MX identifies receiving mail servers and their priorities. When only the website moves, preserve mail records. Replacing nameservers without reproducing the complete zone can interrupt an unrelated service. Include less visible records in the plan rather than assuming the website address represents the whole domain.
Prepare the destination and change window
Copy files and SQL, then test the application and HTTPS at the destination. Shops and member systems need a final consistent copy and a planned pause in writes to prevent two databases diverging. Lowering a TTL in advance may shorten some cache delays, but cannot clear existing cached answers or guarantee instant propagation. Choose a window when someone can inspect both environments and decide whether to continue or roll back.
Preserve mail authentication
SPF is published in TXT and describes authorised sending systems. DKIM publishes a public key under a selector. DMARC defines policy using alignment of the visible sender domain with SPF or DKIM. Retain the email provider’s required values; do not create multiple separate SPF policies for the same name. After the move, test inbound and outbound delivery and inspect authentication results. Private signing keys should never appear in DNS or a sales enquiry.
Coordinate delegation and DNSSEC
Changing nameservers at the registrar changes DNS delegation. It does not transfer domain ownership or automatically move the website. If DNSSEC is enabled, coordinate keys and DS records with the relevant providers. An incompatible DS can make answers fail validation. Agree the procedure before changing delegation and retain independent access to the registrar. Treat DNSSEC as a planned operation rather than removing records at random when a resolver reports an error.
Verify services before retiring the old copy
Check A, AAAA, MX and TXT answers through more than one resolver, then test website pages, forms and email. Correct DNS is not proof that an application works. Watch the old environment during transition and document rollback criteria. Prepare a CubixServ enquiry identifying which services should move; DNS scope, access and assistance are agreed before intervention. A domain kept with another registrar can still be part of that discussion without being transferred.
For your situation
| Situation | Next check |
|---|---|
| Only the website is moving | Keep the email service and its records. Change only the relevant website names. |
| The entire zone changes provider | Reproduce all records and coordinate DNSSEC before changing delegation. |
| The site accepts orders | Pause writes, take a final consistent copy and define checks before reopening. |
Official sources
These documents describe the relevant protocols and software. Your service terms and configuration still need to be checked.