The short answer
Lower the TTL a day or more ahead, switch DNS only after the new site is approved and tested, change the A record or CNAME and leave MX and TXT alone, decide on www versus the bare domain with redirects, confirm the SSL padlock, test email, and keep the old values and old site ready for a rollback.
When to switch
Switch only when the new site has been tested on a preview link, signed off, and the old site's content is frozen. At Webtec nothing goes live without your approval on a preview link, and work is checked by a second person before you see it. Then pick a quiet moment for your business: not the middle of a sale, a campaign launch or your busiest hour. A morning early in the week gives you a full working day to spot problems while people are available to fix them. Avoid Friday evenings.
Also agree who is doing what. DNS is often controlled by the person who registered the domain, who may not be on the project. Sort out access beforehand, as described in who owns your accounts.
Step 1: prepare, days before
- 1Find where DNS is actually hosted: the registrar, your host, or a service like Cloudflare. Look at which name servers your domain uses. Edit records only there.
- 2Export or screenshot every current record. Pay special attention to MX records (email) and TXT records (SPF, DKIM, DMARC, verifications).
- 3Lower the TTL on the records you will change, such as 300 seconds. Do this at least as long ahead as the old TTL, so caches have time to pick up the short value. A shorter TTL lets the switch reach people quickly and makes a rollback just as fast. Cloudflare's documentation notes that longer TTLs slow updates.
- 4Get the new server details from the host: the IP address for an A record, or the hostname for a CNAME. Check them with the host, because a wrong digit points the site nowhere.
- 5Prepare the redirect plan and confirm the SSL certificate approach with your host.
www or the bare domain?
Your site can be reached as yourcompany.com (the bare, or apex, domain) or www.yourcompany.com. They are two names, and each needs a record. Choose one as the main address, and send the other to it with a permanent redirect. Keeping both live as separate copies splits your search signals and confuses visitors.
| Name | Usual record | Why |
|---|---|---|
| yourcompany.com (bare) | A record to the server's IP address | The bare name also carries your MX and TXT records. A standard CNAME cannot sit beside other records on the same name, so use an A record unless your DNS provider offers a supported alias or flattening feature. |
| www.yourcompany.com | CNAME to the bare domain or to the host's hostname | A CNAME is convenient: if the host's address changes, www follows without an edit. |
Cloudflare's reference describes an A record as mapping a name to an IP address and a CNAME as mapping a name to another name. It also describes CNAME flattening as a feature that handles CNAMEs at the top of a domain, for DNS provided there.
Step 2: make the switch
- 1Confirm the new site is ready one last time, on its preview link.
- 2Edit the A record for the bare domain to the new IP, and the www record as planned. Change nothing else. Do not touch MX or TXT.
- 3Save, then wait. Test from a phone on mobile data as well as your office network, because the two may hold different cached answers.
- 4If the site still shows the old version for some people, wait. That is cached DNS expiring. Do not make further changes unless you have a clear error.
- 5Keep the old hosting running for at least several days.
Never delete the old records when you add the new ones. Overwrite the specific value you need and keep a copy of the old one, so you can put it back.
SSL and the padlock
An SSL certificate is what puts the padlock in the browser and turns the address into https. Certificates are issued for a specific domain name, and in most cases your host can only issue one once the domain points at their server, because the issuer has to verify that you control the name. That means the padlock may be missing for a short time after the switch, until the certificate is issued.
Ask your host beforehand how it handles this, and whether it can issue the certificate in advance or at the moment of the switch. Then check afterwards that both the bare domain and www show a valid padlock and that http addresses redirect to https. Warnings that linger are covered in SSL padlock warning.
Step 3: verify, immediately and the next day
- The bare domain and www both load the new site, and one redirects to the other.
- The padlock is present and there is no mixed-content warning.
- Old page addresses that have changed redirect to the right new pages. See redirects after a redesign.
- Contact forms send, and the confirmation arrives. See forms not sending emails.
- Email works both ways: send a message to your domain from outside, and send one out to a Gmail address and check SPF, DKIM and DMARC. See email and your domain.
- Search Console shows no new crawl errors, and your sitemap is submitted. See Search Console basics.
- Phone, tracking and ad links still point to the right pages.
Rollback: how to undo it
If something serious breaks, restore the previous record values from your notes. Because you lowered the TTL, the old setting returns quickly. The old site is still running on its old host, so visitors see it again as caches update. Decide in advance what counts as serious: the site is down, forms or checkout fail, or email stops. A cosmetic issue on the new site is better fixed in place than rolled back.
After a rollback, find the cause, fix it on the preview, and pick a new window. A rollback is a normal tool, not a failure.
Example: A calm Tuesday launch
A design studio planned a launch for Tuesday at 10:00. On Sunday they lowered the TTL from 14,400 seconds (four hours) to 300 seconds. On Monday they exported all DNS records, confirmed the new server's IP with the host, and checked that the host could issue the SSL certificate once the domain pointed at it. On Tuesday they changed the A record for the bare domain and the www CNAME, left MX and TXT alone, and tested from a phone on mobile data. The padlock appeared within the hour. A contact form test and a mail test both passed. They kept the old host for a week, raised the TTL back to a longer value on Wednesday, and never needed the rollback they had prepared.
When to ask us
If we built your new site, your project manager handles timing and approvals, and we will tell you which records to change. If you are doing it yourself, or something looks wrong, send a request through the support form. Include: your domain, where DNS is hosted, the new server details you were given, what you changed and when, what you now see (screenshot or Loom link), and whether email is affected. Share links via Google Drive, Dropbox or Loom, and never send passwords. A person on our team will review and tell you whether to wait, adjust or roll back.
