Moving a website, transferring a domain and changing DNS providers are related activities, but they are separate changes. Confusing them can interrupt services that appeared unrelated to the move. Your website may load correctly while email stops arriving, a booking subdomain disappears or a supplier can no longer verify the domain.
The practical question is which part of the arrangement is changing and which services depend on it. DNS records describe destinations and other domain information. Nameservers identify the servers providing the authoritative DNS answers for a domain. A careful provider move establishes both before altering the live configuration.
Separate the domain, DNS and hosting responsibilities
The registrar manages the domain registration relationship. The DNS provider hosts the authoritative records. The website host runs the website, and the email provider runs the mail service. One company may supply several of these functions, but that does not make them the same function.
Ask the technical owner to draw the current arrangement. Record the registrar, authoritative DNS provider, website destination, email provider and important external services. Include the account owner and who is authorised to make each change. An invoice for hosting may not identify where DNS is actually managed.
Define the move precisely. If only website hosting changes, you may need to update the website's DNS destination while keeping the existing nameservers. If authoritative DNS moves, the new provider needs the relevant zone information before delegation changes. A domain transfer between registrars can be a third, independently planned task.
Understand the records that support your services
Common records include A records for IPv4 addresses, AAAA records for IPv6 addresses, CNAME records that refer to another hostname and MX records identifying mail destinations. TXT records can carry information used for verification and email-related configuration. Other record types support additional services.
Use DNS record definitions as a starting point for an inventory rather than instructions to invent values. The website, email and other service providers should supply the exact records required for their arrangements. Check ownership and dependencies before changing them. Our DNS record inventory guide provides the related checks.
Record names, types, values and relevant priorities accurately. Similar-looking entries can serve different purposes. A record for the main website does not automatically cover every subdomain, and a mail destination alone does not describe the complete email configuration.
Connect each entry with an owner or service where possible. A verification record with no known purpose may still support an active supplier account. Investigate before removing it. The migration is easier to review when the team understands what each retained record enables.
Know what a nameserver change actually redirects
Changing the domain's nameservers changes where authoritative DNS answers are obtained. It does not itself copy a website, move stored email messages or recreate the records at the destination provider. Those dependencies require their own preparation.
For a domain managed through a registrar or reseller, delegation is normally changed through the relevant domain account. A delegated subdomain can have a different arrangement within its parent zone. Identify the account and delegation model first. Our nameservers and DNS delegation guide provides the related checks.
Use the nameservers assigned by the intended provider for the actual domain and setup. Do not copy nameservers from another customer's instructions or assume that every account uses the same ones. Ask the responsible provider to confirm the proposed values before the change.
Build and compare the destination configuration
Export the current zone where supported and keep a dated reference. Supplement it with the service inventory and any provider-specific settings that a standard record export does not capture. Store the reference where the authorised team can reach it during the move.
Create the destination zone before switching delegation. Compare it with the source and the intended final service arrangement. Some records should remain identical because their services are staying put; others may change because the website or email is moving too.
Do not rely entirely on an automatic discovery tool. It may not find every record, particularly entries that are not visible through a simple lookup of the main domain. Compare against an authoritative account export and confirm less obvious subdomains with their owners.
Check provider features separately. Proxying, traffic steering and other managed behaviours may influence how a record operates beyond its displayed name and value. Ask whether the new setup preserves the intended behaviour, rather than treating every provider interface as interchangeable.
Use TTL to plan caching, without promising instant change
DNS time to live, or TTL, indicates how long an answer may be cached before refreshing. A lower value can support planned changes, but it does not immediately clear existing caches. Account for the previous lifetime when preparing the transition. Our DNS caching and TTL guide provides the related checks.
If the migration plan calls for lowering a record's TTL, do it sufficiently in advance for previously cached answers to age out under their earlier value. The appropriate lead time depends on the existing configuration and the change being made. Agree it with the DNS owner.
Distinguish record caching from delegation changes. Lowering a website record's TTL does not by itself establish how quickly every resolver will use a new nameserver arrangement. Avoid promising a universal cutover time based on one value in the control panel.
Keep necessary old services available during the agreed transition. Visitors and senders may reach different destinations while cached information changes. The operational plan should address that overlap and prevent lost enquiries or conflicting data where both environments can receive activity.
Protect email and other dependencies during the move
Confirm whether email is staying with its current provider. If it is, preserve the required mail routing and authentication records using that provider's instructions. If email is moving, treat mailbox data, user access and sending configuration as a separate migration workstream.
Test incoming and outgoing mail through agreed accounts after the change. Include automated website messages and other authorised sending services where relevant. A person successfully sending from a desktop mail application does not prove that every business sender still works.
Review subdomains used for booking, customer portals, campaigns or external tools. Ask the business teams about services they use rather than limiting the check to the homepage. A forgotten subdomain may not be noticed until a customer follows an old link.
Have the technical owner review DNSSEC and the provider's migration requirements where it is enabled. This is part of the DNS design, not a setting to change casually during troubleshooting. Record the agreed sequence and validation checks before the move.
Assign a change window, checks and recovery route
Choose a change window based on the services involved and the availability of the people who can resolve problems. A quiet period is useful only if someone can monitor the result. Identify the person making the change and the person deciding whether to continue or recover.
Prepare checks that establish both DNS answers and business outcomes. Ask the technical owner to verify the intended authoritative configuration and representative external resolution. Then check website journeys, mail delivery and dependent services from appropriate test arrangements.
Document the recovery route without assuming that reversing nameservers is instantaneous. Cached answers can continue to refer to either arrangement. The plan needs valid records, accessible accounts and a clear approach to any data created during the transition.
Complete the handover before closing old accounts
Keep monitoring after the first successful check. Review customer reports and operational records for evidence of missed dependencies. Record the final provider arrangement, retained record inventory, account owners and renewal responsibilities.
Close old services only when their role in the transition has been resolved and the owner has agreed the timing. Cancelling an account can remove DNS or email functions bundled with hosting, even when the website has already moved elsewhere.
Giraffe Digital's digital strategy service considers hosting, domains and business tools within the wider customer journey. A provider move should follow that same joined-up view: identify authority, preserve dependencies, test actual outcomes and leave the business with a configuration it can understand and maintain.
Frequently asked questions
How should we separate the domain, DNS and hosting responsibilities?
The registrar manages the domain registration relationship. The DNS provider hosts the authoritative records. The website host runs the website, and the email provider runs the mail service. One company may supply several of these functions, but that does not make them the same function. Ask the technical owner to draw the current arrangement. Record the registrar, authoritative DNS provider, website destination, email provider and important external services. Include the account owner and who is authorised to make each change. An invoice for hosting may not identify where DNS is actually managed. Define the move precisely. If only website hosting changes, you may need to update the website's DNS destination while keeping the existing nameservers.
How should we know what a nameserver change actually redirects?
Changing the domain's nameservers changes where authoritative DNS answers are obtained. It does not itself copy a website, move stored email messages or recreate the records at the destination provider. Those dependencies require their own preparation. For a domain managed through a registrar or reseller, delegation is normally changed through the relevant domain account. A delegated subdomain can have a different arrangement within its parent zone. Identify the account and delegation model first. Our nameservers and DNS delegation guide provides the related checks. Use the nameservers assigned by the intended provider for the actual domain and setup. Do not copy nameservers from another customer's instructions or assume that every account uses the same ones. Ask the responsible provider to confirm the proposed values before the change.
How should we use TTL to plan caching, without promising instant change?
DNS time to live, or TTL, indicates how long an answer may be cached before refreshing. A lower value can support planned changes, but it does not immediately clear existing caches. Account for the previous lifetime when preparing the transition. Our DNS caching and TTL guide provides the related checks. If the migration plan calls for lowering a record's TTL, do it sufficiently in advance for previously cached answers to age out under their earlier value. The appropriate lead time depends on the existing configuration and the change being made. Agree it with the DNS owner. Distinguish record caching from delegation changes. Lowering a website record's TTL does not by itself establish how quickly every resolver will use a new nameserver arrangement.
How should we protect email and other dependencies during the move?
Confirm whether email is staying with its current provider. If it is, preserve the required mail routing and authentication records using that provider's instructions. If email is moving, treat mailbox data, user access and sending configuration as a separate migration workstream. Test incoming and outgoing mail through agreed accounts after the change. Include automated website messages and other authorised sending services where relevant. A person successfully sending from a desktop mail application does not prove that every business sender still works. Review subdomains used for booking, customer portals, campaigns or external tools. Ask the business teams about services they use rather than limiting the check to the homepage. A forgotten subdomain may not be noticed until a customer follows an old link.
How should we complete the handover before closing old accounts?
Keep monitoring after the first successful check. Review customer reports and operational records for evidence of missed dependencies. Record the final provider arrangement, retained record inventory, account owners and renewal responsibilities. Close old services only when their role in the transition has been resolved and the owner has agreed the timing. Cancelling an account can remove DNS or email functions bundled with hosting, even when the website has already moved elsewhere. Giraffe Digital's digital strategy service considers hosting, domains and business tools within the wider customer journey. A provider move should follow that same joined-up view: identify authority, preserve dependencies, test actual outcomes and leave the business with a configuration it can understand and maintain.
