How to Point a Domain to a New Host

Overview

If you need to point a domain to a new host, the first question is not where do I click but what exactly am I changing. In business web hosting, there are two common paths:

• Change nameservers: you hand DNS management to the new hosting provider or DNS provider. This is often the simplest route when the new host gives you nameserver values and expects to manage the zone for you.
• Update specific DNS records: you keep your current DNS provider and edit only the records that control the website, such as the A record, AAAA record, or CNAME. This is often safer when you already use separate email, security, or DNS management for business.

Before touching anything, confirm four things:

1. Where the domain is registered. Your registrar is the company where the domain is held and renewed.
2. Where DNS is hosted. This may be the registrar, the current host, or a third-party DNS service.
3. What services depend on existing DNS. Website, email, subdomains, verification records, CDN, SSL validation, and third-party apps can all be tied to the current zone.
4. Whether the new host is ready. The site files, database, application settings, SSL setup, and redirect rules should be prepared before the public cutover.

If this distinction still feels blurry, it helps to review Domain vs Hosting: What Business Owners Need to Buy Separately. Many migration problems start because the registrar, DNS host, and web host are assumed to be the same system when they are not.

As a working rule, changing nameservers is broader and more disruptive than editing a single website record. If your email and other services are already working well, avoid broad changes unless there is a clear reason to move everything.

Checklist by scenario

Use the scenario below that matches your setup. The goal is to choose the smallest change that gets the site live on the new host without affecting unrelated services.

Scenario 1: Point domain to new host by changing nameservers

Choose this when your new hosting provider tells you to use its nameservers, or when you want the host to manage DNS entirely.

1. Collect the new nameserver values from the new host. These usually look like ns1.examplehost.com and ns2.examplehost.com.
2. Export or copy your existing DNS zone before making changes. Record all A, AAAA, CNAME, MX, TXT, SRV, and other custom records.
3. Recreate non-website DNS records in the new DNS zone before the switch. This matters especially for email, SPF, DKIM, DMARC, verification tokens, and subdomains.
4. Verify the new website works on the host’s temporary URL, preview domain, or hosts file method. Do not rely on the public domain yet.
5. Update nameservers at the registrar. This is the actual handoff step.
6. Monitor propagation and test the website, admin area, forms, checkout, and email delivery.

This route is straightforward, but it is easy to miss records that have nothing to do with the website. For a refresher on record types, see DNS Record Types Explained for Business Owners: A, CNAME, MX, TXT, and More.

Scenario 2: Connect domain to hosting by updating A record or CNAME only

Choose this when you want to keep DNS with your current provider and only direct the website traffic to the new host.

1. Ask the new host which record to update. Some providers want an A record pointed to an IP address. Others use a CNAME for certain setups.
2. Identify the current website record in your DNS zone. Usually this is the root domain record for example.com and a separate record for www.
3. Reduce TTL in advance if possible. Lowering TTL before the cutover can help changes circulate more quickly later. This should be done ahead of time, not at the same moment as the final switch.
4. Update the root domain to the new A or AAAA value if instructed.
5. Update the www record, often as a CNAME pointing to the root or to a host-specific target, depending on the new platform’s instructions.
6. Leave email and unrelated records untouched. This is the main advantage of keeping your DNS where it is.
7. Test both versions: example.com and www.example.com.

This is often the cleanest way to update DNS for hosting when email is already stable and you do not want to risk broader DNS changes.

Scenario 3: Move website to new host but keep email with another provider

This is a very common business setup and a common source of mistakes.

1. Inventory your email-related records: MX, SPF, DKIM, DMARC, autodiscover, and any provider-specific CNAME or TXT records.
2. Do not overwrite or delete them unless you are intentionally changing email providers.
3. Change only the website records needed for the new host.
4. After cutover, send test emails both ways: inbound to your domain and outbound from your domain.
5. Check forms on the site if they send notifications, receipts, or contact messages.

If you change nameservers rather than individual records, you must rebuild all of these email settings first on the new DNS service. Skipping that step can make the site appear fine while business email quietly fails.

Scenario 4: Launch a redesigned site on a new host with minimal disruption

When the new host already has a full copy of the site, your checklist is more about cutover discipline than about DNS itself.

1. Freeze content changes on the old site shortly before migration if your platform requires it.
2. Copy the latest files and database to the new host.
3. Test the new environment for plugins, themes, caching, application settings, redirects, forms, image paths, and user logins.
4. Confirm SSL setup is ready or can be issued immediately after DNS points to the new host. See SSL Certificates for Business Websites: Types, Costs, and Renewal Rules.
5. Make the DNS change during a controlled window when your team can observe and test.
6. Keep the old host active temporarily until traffic is clearly reaching the new host and no rollback is needed.

For broader migration planning beyond DNS, this companion checklist is useful: Website Migration Checklist for Moving Hosting Providers.

Scenario 5: Point a subdomain to a new host

Sometimes you are not moving the entire domain. You may only be launching a shop, app, knowledge base, or regional site on a subdomain such as store.example.com or app.example.com.

1. Confirm the target subdomain and whether the new platform wants an A record or CNAME.
2. Create or edit only that subdomain record.
3. Check whether SSL covers the subdomain.
4. Verify internal links and canonical settings if the subdomain is part of a broader website structure.

For planning decisions around site structure, see Subdomain vs Subdirectory for Business Websites.

What to double-check

Before and after you change nameservers to a new host or update DNS for hosting, review these items. They are the difference between a clean cutover and a frustrating cleanup project.

• Registrar access: make sure you can log in and complete changes without waiting on a colleague, old vendor, or shared inbox.
• Domain renewal status: do not start a migration if the domain is close to expiration or has billing uncertainty. See What Happens If You Forget to Renew a Domain?.
• Correct DNS host: editing records at the registrar does nothing if authoritative DNS is hosted elsewhere.
• Root and www behavior: both should resolve correctly, and one should redirect consistently if that is your preferred setup.
• IPv6 records: if there is an AAAA record, make sure it matches the new host’s setup or remove it if the host specifically instructs you to. A stale AAAA record can send some visitors to the wrong destination.
• Email records: MX, SPF, DKIM, and DMARC should survive the move unchanged unless email is also being migrated.
• TXT records for external services: payment processors, productivity suites, marketing platforms, and verification tools often rely on these.
• CDN or proxy settings: if you use a CDN, reverse proxy, or web application firewall, confirm whether origin IPs, SSL modes, and cache settings need updating.
• Redirects: if URLs are changing during the move, make sure 301 redirects are in place at the new host.
• Application-level settings: CMS site URL, database connection values, environment variables, cron jobs, and file permissions often need host-specific updates.
• Monitoring: keep uptime and response checks running during the transition. Website Uptime Monitoring for Small Businesses: What to Track and Why is a useful baseline.

Also remember that DNS changes are not always visible everywhere at once. Different resolvers and devices may see different answers for a period of time. A practical overview is here: DNS Propagation Explained: How Long Changes Take and How to Check.

Common mistakes

Most failed domain cutovers are not caused by DNS itself. They are caused by skipped preparation or changes that were broader than necessary.

• Changing nameservers when only one A record needed updating. This increases risk because it moves all DNS responsibility at once.
• Forgetting email records. A site can load perfectly while mail stops flowing.
• Editing the wrong zone. Many businesses have multiple DNS dashboards from registrar, old host, CDN, and managed DNS provider.
• Not testing on the new host first. DNS should not be your testing method.
• Shutting down the old host too early. Keep it available until you are sure traffic has shifted and rollback is unnecessary.
• Ignoring SSL timing. If certificates depend on DNS validation or the new platform provisions certificates after cutover, plan for that sequence.
• Leaving stale records behind. Old A, AAAA, or CNAME records can create inconsistent routing.
• Skipping a rollback plan. Know what previous values to restore if the new environment fails.
• Making changes during a high-risk business window. Avoid major launches right before critical campaigns, events, or seasonal peaks unless you have ample coverage.

If your organization manages many domains, add one more caution: standardize your process. A simple operating checklist for domain registration for business and DNS management for business reduces repeated errors across teams.

When to revisit

This is a topic worth revisiting every time your setup changes. Use this short action list before any new launch, migration, platform switch, or seasonal planning cycle.

1. Reconfirm who controls the registrar, DNS, hosting, and SSL. Ownership drifts over time, especially after vendor changes.
2. Review whether your current DNS approach still fits. If you need more control, speed, or reliability, keeping DNS separate from hosting may make future migrations easier.
3. Update your domain inventory. Include apex domain, www, subdomains, nameservers, DNS provider, host, and related services.
4. Refresh your migration checklist whenever your CMS, control panel, CDN, or security tooling changes.
5. Test a low-risk change periodically so your team stays familiar with the process before a time-sensitive move.
6. Document the last known good configuration. Store prior record values, screenshots, and access details in a secure internal system.
7. Schedule cutovers deliberately. Choose a time when technical staff can validate the website, email, and analytics immediately after the switch.

The practical goal is simple: make every future cutover smaller, clearer, and easier to reverse. Whether you need to point a domain to a new host once a decade or several times a year, the same principle applies. Change only what needs to change, preserve the records that support other business services, and test the new hosting environment before public traffic reaches it.

If you are planning a broader upgrade in business web hosting or comparing managed hosting for small business, it is worth treating DNS and hosting as separate decision layers. Better hosting improves the application environment. Better DNS management improves control and cutover safety. Together, they make website hosting for companies more reliable, especially when growth, redesigns, or platform changes are part of the roadmap.