Planning the DNS Cutover: Launch Day Without the Drama

Launching a migrated website usually comes down to changing DNS records so the domain points to the new environment. The change itself takes minutes. The work that makes it uneventful happens in the days before, and a written cutover plan is the simplest way to make sure nothing is improvised.

Inventory current DNS records

Export or record every DNS record for the domain: A and AAAA records, CNAMEs, MX records for email, TXT records for verification and email authentication, and any records for subdomains. You will change only a few of these, but you need to know the rest so they are not lost or overwritten.

Identify what changes and what does not

Typically, only the records for the main hostname and the www hostname change. Email, verification and other subdomain records should stay exactly as they are unless there is a separate plan for them. Write down the current and new values for each record you will touch.

Lower the TTL in advance

Time-to-live tells resolvers how long to cache a record. A day or two before launch, lower the TTL on records you plan to change so that the switch propagates quickly. After launch is stable, raise it again.

Prepare certificates

The new environment needs a valid certificate for every hostname it will serve. Some platforms issue certificates automatically once DNS points to them, which can mean a short window where the certificate is being provisioned. Understand how your platform behaves and plan accordingly.

Freeze content changes

Agree a content freeze on the old site from a set point before launch, so edits are not lost. If freezing is not possible, record changes made after the final content sync and apply them to the new site.

Write the run sheet

A launch run sheet lists each step in order, who does it and how to confirm it worked. A typical sequence:

1. Confirm the final content sync is complete.
2. Confirm redirects, forms and integrations pass on staging.
3. Update DNS records to the new values.
4. Verify the new site responds on all hostnames with a valid certificate.
5. Test key pages, forms and redirects on the live domain.
6. Update any third-party services that need the new configuration.
7. Submit the sitemap and monitor for errors.

Choose a sensible time

Launch when your audience is quietest and when the people who can fix problems are available. Avoid the last hours before a weekend or holiday.

Define the rollback

Keep the old environment running and untouched until the new site has been stable for an agreed period. Decide in advance what would trigger reverting DNS, and who makes that call. A rollback that is planned is quick; one that is improvised is stressful.

Communicate

Let staff know when the launch will happen, what might look different and how to report problems. Customer-facing teams should know who to contact if a customer reports an issue.

After the switch

For the first day, check analytics for traffic, forms for submissions and monitoring for errors. Expect some visitors to see the old site briefly while caches expire. Once everything is steady, raise TTLs and schedule decommissioning of the old environment, after confirming backups are retained as required.