Home / Articles / Web Hosting
Web Hosting

Moving Hosting Without Confusing Your Website: A Guide to DNS and TTL

Moving hosting doesn't always mean your website has to be down for hours. By understanding DNS, TTL, and the correct sequence of migration, you can reduce the risk of visitors accessing the old server or emails stopping.

Pindah Hosting tanpa Membuat Website Bingung: Panduan DNS dan TTL

Moving hosting is often thought to be as simple as copying files, transferring databases, and then changing the server address. In practice, the part that often causes confusion is DNS—the system that directs a domain to a specific server.

If DNS is not set up correctly, some visitors may see the new website while others are still directed to the old server. Emails can also stop coming in if the MX records change or are not copied. Therefore, moving hosting should be treated like moving an office address: prepare the new location first, then gradually change the directions.

DNS is More Than Just an IP Address

DNS or Domain Name System translates names like example.com into addresses that servers can understand, such as an IPv4 address in an A record or an IPv6 address in an AAAA record.

Within the DNS zone, there are usually several records with different functions:

  • A: directs a domain or subdomain to the server's IPv4 address.
  • AAAA: directs a domain to the IPv6 address.
  • CNAME: creates an alias that points to a specific hostname.
  • MX: specifies the server that receives emails for the domain.
  • TXT: stores text information, such as domain verification and SPF policies.
  • CAA: restricts which certificate authorities can issue SSL certificates for the domain.

Panels like cPanel provide a Zone Editor to view and modify these records. However, the location for managing DNS is not always the same as where the website files are stored. You might host the website on hosting A, but the DNS is managed by Cloudflare or a domain registrar.

What is TTL and Why is it Important Before Moving Hosting?

TTL, short for Time to Live, is the duration a DNS record can be stored by a resolver or DNS cache before it must check back with the authoritative nameserver. The value is usually written in seconds. A TTL of 3,600 means about one hour.

A longer TTL can reduce the frequency of DNS requests, but changes to records take longer to be visible to all users. Conversely, a shorter TTL allows changes to be updated more quickly, with the consequence that DNS requests may occur more frequently.

This is why “DNS propagation” cannot always be forced to complete in a matter of minutes. If a resolver has stored the old server address for several hours, it may continue to use it until the TTL expires. Local device caches, routers, and office networks can also create different experiences for each user.

Safe Sequence for Moving Hosting

1. Inventory DNS Records

Before purchasing or canceling hosting, note all active DNS records. Don’t just look at the A record for the website. Also check www, application subdomains, MX records, TXT, CNAME, and AAAA if used.

Email components require special attention. If MX, SPF, DKIM, or DMARC records are missing when DNS is moved, the website may remain normal but email could encounter issues. Keep a copy of the DNS zone in text form or as a screenshot before making changes.

2. Lower TTL Before Major Changes

A few hours or a day before the move, lower the TTL for the records that will be changed, especially A and AAAA. Values like 300 or 600 seconds can help the next changes to be applied more quickly, as long as the DNS provider allows it.

Do not assume all TTLs automatically change just because you modify one record. In cPanel, TTL can be set per record through the Zone Editor. Changing the TTL for the entire zone can also affect many records at once, including SOA and NS records, so mass changes need to be done carefully.

3. Prepare New Hosting Before Changing DNS

Upload website files, create databases, import data, and adjust application configurations on the new server. If the application uses configuration files, double-check the database name, username, password, database host address, and the PHP version or runtime being used.

Test the website before directing the domain to the new server. You can use a temporary URL from the provider, the hosts file on your own computer, or a testing subdomain. The goal is not only to ensure the homepage displays but also to check login, forms, file uploads, searches, checkouts, and connections to external services.

4. Check SSL Configuration

The new website must have an SSL certificate that matches the domain. If using Let’s Encrypt or an automated certificate issuer, ensure the domain validation process can proceed after DNS is directed. Certificates installed on the old server do not automatically transfer with the website files.

Don’t forget to test variations of the domain such as http://, https://, the version with www, and the version without www. Ensure everything points to the desired destination and does not create excessively long redirect chains.

5. Change Necessary Records

Once the new server is ready, change the A or CNAME records according to the architecture being used. If using Cloudflare, check whether the records are in Proxied or DNS Only mode. This mode can affect the address visible from the outside as well as how the SSL certificate and connection to the origin server function.

If the domain's nameserver is also moved, the risks are greater than just changing the A record. Ensure the entire DNS zone has been created with the new provider before changing the nameserver at the registrar. Changing the nameserver can make records that have not been copied appear “missing.”

How to Check if the Move is Correct

Don’t just open the website from one laptop. Check from multiple networks, such as home Wi-Fi, mobile connections, and office networks. You can also use the following commands from the terminal:

dig example.com A
dig example.com MX
dig www.example.com CNAME

Compare the results with the configuration on the new server. For the website, ensure the IP address that appears is correct. For email, ensure the MX records still point to the correct email service.

During the transition period, monitor access logs on both the old and new servers. If the old server is still receiving many requests, some resolvers may not have updated their caches. Do not immediately shut down the old hosting just because the website appears normal from your computer.

Common Mistakes

  • Changing nameservers too quickly. The DNS zone at the new provider is not complete, but the nameservers have already been changed.
  • Only moving website files. Databases, cron jobs, PHP configurations, and scheduled tasks are forgotten.
  • Immediately deleting old hosting. DNS cache may not have expired, and emails still depend on the old configuration.
  • Changing too many records at once. When issues arise, it’s hard to determine which change caused the problem.
  • Not lowering TTL before the move. Old records may still be stored in resolvers for hours.

What You Can Do Now

Create a migration checklist that includes three groups: website data, server configuration, and DNS. Keep a copy of the DNS records, note the TTL values, and schedule changes during low traffic times.

After a successful migration, gradually raise the TTL back to a more reasonable value. Short TTLs are useful during migration or frequent changes, but they are not always ideal as a permanent configuration.

In summary, DNS is not an instant button that immediately directs everyone to the new server. It operates through caches and resolvers that have different update times. By preparing the new server, copying all important records, lowering the TTL early, and monitoring both servers during the transition, moving hosting can be done without causing the website and email to go in different directions.

Sources & Further Reading

– Rio Yotto @rioyotto