Change DNS with minimal disruption to your website and email

Changing DNS should be the last step of a migration, not the first. Before you do it, copy and test the content at the destination, recreate the records for external services and prepare a final sync of any data that may have changed.

Transferring the domain and changing DNS are not the same

A transfer changes the registrar that manages the domain. It doesn't move the website, doesn't copy email and usually keeps the previous nameservers.

A DNS change sets which servers will answer from then on. It can be done without transferring the domain, from the provider that currently manages it.

See the full difference in the guide to migrating hosting to Hostsuar.

1. Save the current configuration

Before changing anything, keep a copy of the DNS zone and note down:

• A and AAAA records for the website and subdomains.
• MX records for email.
• TXT records for SPF, DKIM, DMARC and verifications; some providers use CNAME for DKIM.
• CNAME and SRV records for external services.
• Subdomains used by applications, phone systems, calendars or third-party tools.

Don't copy every record without reviewing it. Those pointing to the old hosting will need to change; those belonging to Google Workspace, Microsoft 365 or other services that remain active must be kept.

2. Prepare the new zone

Set up all the records you need at the destination before changing the nameservers.

If email will stay outside Hostsuar, keep its MX, TXT, CNAME and SRV records and set email routing to remote.

If you only want to move the website and keep email where it is, see how to point the website to another server while keeping your current email.

You can review and edit the records from Zone Editor.

If you're going to lower a record's TTL, do it in advance: an answer that has already been stored keeps the TTL it had when it was queried. Lowering it at the moment of the change doesn't clear caches or change the delegation's TTL in the parent zone.

3. Test the destination without changing DNS

Check the website on the new server by temporarily editing your computer's hosts file, using a test subdomain or the method available for the application.

The guide to working with the final domain before pointing it explains how to make only your computer resolve the domain to the new IP.

At a minimum, test:

• The home page, internal pages and the admin area.
• Forms and orders; test payments in test mode to avoid real charges.
• The database connection.
• Files and media.
• Scheduled tasks.
• Sending email from the application.

4. Sync the latest changes

A dynamic website may have received orders, form submissions or changes since the first copy. Before the switchover, agree on a low-activity window and copy the database or any changed data again.

For email, run imapsync again just before the change. See how to migrate email without losing messages.

5. Change the nameservers

If DNSSEC is active, first remove the previous DS configuration at the registrar and wait for its TTL in the parent zone to expire. Then change the nameservers and publish the DNSSEC configuration generated by the new provider. A multi-signer migration avoids the period without validation, but only use it if both providers support the external DNSKEYs required.

Set Hostsuar's nameservers at the registrar. If the domain is registered with us, follow the steps to change its nameservers.

During propagation, some connections may reach the old provider and others the new one. Keep both services running and avoid making incompatible changes to the two copies.

6. Check propagation

Don't rely only on what your own computer shows: your internet provider or browser may keep old data for a while.

Use the DNS and IP propagation check to verify from different resolvers:

• Authoritative nameservers.
• The website's IP.
• Email MX records.
• Relevant subdomains.

Propagation can take anywhere from minutes to hours and isn't the same for every user.

7. Check the website, HTTPS and email

Once the domain starts resolving to the new service, check:

• The website with and without www.
• The HTTPS certificate.
• Forms, orders and admin access.
• Sending and receiving email.
• Mailboxes and recent messages.
• Subdomains and external services.
• SPF, DKIM and DMARC for the final provider.

Run one last email sync to pick up messages that may have reached the source during propagation.

If something goes wrong

Don't cancel the old provider. First work out whether the problem is in the content, the DNS zone or propagation.

If the new service has a serious problem, you can temporarily restore the previous records or nameservers, but switching back also needs to propagate and won't be instant. On dynamic websites, keep any changes made during the attempt so you don't lose orders or data when you roll back.

When to retire the old service

Wait until you have confirmed that:

• The main resolvers show the new DNS or IP.
• The website and external services work at the destination.
• Email goes in and out through the final provider.
• No recent messages or data remain only at the source.
• You have a final restorable backup.

Only then cancel the old hosting and revoke the temporary access used during the migration.

Complete the review with the post-migration checklist.

Before reopening for business, check which server runs the scheduled tasks. Keeping both hosting accounts active during propagation doesn't mean they should both send the same notifications or process the same orders at the same time.