The DNS Cutover Runbook for a HubSpot CMS Launch

Most website launch problems are not website problems. They are DNS problems, and almost all of them are decided days before the launch by someone who did not know they were making a decision.

This is the runbook we use for client launches onto HubSpot CMS. It is deliberately boring.

Two weeks out: lower the TTL, and understand why the timing works that way

TTL is how long a resolver is allowed to keep a cached copy of your DNS record. The launch-day version everyone knows is "set the TTL low so changes propagate fast." The part that catches people is when to do it.

A TTL change is itself subject to the current TTL. If a record has a 48 hour TTL and you lower it to 300 seconds the morning of launch, resolvers that cached that record yesterday will keep serving the old value for up to another 48 hours, and they will not learn about the new TTL until their existing cache expires.

So the rule is: if the TTL is 48 hours, change it 48 hours before you need the low value to be in effect. In practice we set 300 seconds a comfortable margin ahead of that, because there is no cost to being early.

HubSpot notes that DNS records usually update within 10 to 70 minutes but can take up to 48 hours, and recommends waiting at least 20 minutes before verifying. That range is not the same for every visitor: propagation is uneven between registrars and between resolvers, so during the window some people will see the new site and some the old one. That is normal and it is the reason for the tagging decision below.

One week out: know exactly which records change

Two record types, and nothing else.

• Subdomains connect with a CNAME pointing at HubSpot. The value looks like your Hub ID followed by a HubSpot sites hostname.
• Root domains connect with A records.

Everything else in the zone stays where it is. Do not touch MX, SPF, DKIM or DMARC unless email is genuinely part of this project. The most damaging launch incident is not a website that is down for an hour; it is a client whose email stopped and who did not connect it to the website launch for two days.

Write the change list before launch day as a table of record, current value, new value. Three lines usually. Anything longer needs justifying.

The subdomain everyone forgets. Beyond the website domain and any blog or content subdomain, HubSpot uses a domain for the hosted web version of marketing emails. Nobody thinks about it at launch because nobody is testing an email at launch. Six days later a newsletter goes out with a "view in browser" link that does not resolve.

Two more registrar-side traps worth checking a week ahead, because both take longer to resolve than you expect:

A bad DNS entry that cannot be edited. Some registrars will not let you modify certain records; they have to be deleted and recreated. Find that out during preparation, not at the cutover.

Registrar one-click connect flows need a real login. HubSpot and several registrars offer an automated connection, and it requires a genuine account login rather than delegated or shared access. If your client's domain is held by an IT provider who has given you "access," confirm that access is a login before you plan around the automated route.

Two days out: pre-provision SSL

SSL provisioning in HubSpot happens automatically after a domain is connected and usually takes a few minutes, but can take up to four hours. HubSpot documents a similar window for pre-provisioning changes.

Four hours is fine. Four hours inside your launch window, while a client watches a browser warning on their own homepage, is not.

Pre-provision. Then verify the certificate is live before the cutover rather than discovering the gap afterwards.

Choosing the day: schedule around who can respond

This is where most launch plans are quietly wrong, because they are built around what looks tidy rather than around who is available.

We moved one client launch specifically because the production team worked Sunday to Thursday and the proposed launch day would have left nobody able to roll back. The site was ready. The team was not there. That is a sufficient reason to move a launch and it should not require a discussion.

The test: for the six hours after the cutover, who is watching, and who has both the access and the authority to reverse it? If the answer to any part of that is nobody, pick a different day.

The corollary is not to launch into a period where the client is unreachable either. A launch is a joint operation and half of the decisions in the first hour belong to them.

Know which kind of launch you are running

This is the single most important risk decision, and it distinguishes two launches that look identical on a plan.

Migrating from another platform onto HubSpot is reversible. The old site still exists on the old host. If something is badly wrong, you repoint DNS back and you are live on yesterday's site within the TTL window you set. That is a real rollback and it is why the TTL work matters.

Overwriting a live HubSpot site from staging inside the same portal is not. There is no cheap undo. The previous state of those pages is gone in any practical sense, and "roll back" becomes "rebuild."

Those are different risk classes and they deserve different preparation. For the second kind, the QA before the switch has to be much harder, because it is the only line of defence you have. For the first, you can accept slightly more risk on the day in exchange for the ability to reverse.

Say which kind you are running out loud, in the launch plan, so nobody assumes a safety net that does not exist.

The QA that has to happen before the switch

For an irreversible launch, the pre-cutover QA is the only protection you have, and the standard version of it is not enough. Three things about how we run it.

Multiple differentiated passes, not one careful look. A single reviewer checking everything catches less than three reviewers each checking one thing. We run separate passes for content accuracy, for functionality, and for cross-browser and responsive behaviour, with a different person on each where possible. One named person signs off at the end; a review everybody did is a review nobody owns.

Sample where you can, be exhaustive where you must. Cross-browser checking every page on a 400 page site is not a good use of anyone's time, and checking every third to fifth page catches template-level problems reliably because problems live in templates rather than in pages. Internal links are the exception: check those on 100 percent of pages. They are cheap to check programmatically and they are the failure that survives QA.

That last point deserves its own paragraph, because it is the trap specific to staging. Absolute internal links written against the old live domain resolve perfectly during staging QA, because the old site is still up and answering. Every link passes. Then DNS moves, the old site stops answering, and the links break in a way nobody tested. Crawl the staging site for absolute links to the production domain before launch and convert them to relative.

Prefix your test data. Any test contact, form submission or record created during QA gets a naming prefix agreed in advance. It makes the cleanup a single filtered delete instead of an archaeology exercise, and it stops test records appearing in the client's first week of reporting.

"Done" means QA signed off, not built. If your project board treats a page as complete when the developer finishes it, your launch date is measuring the wrong thing and you will discover the gap in the final week.

One structural note on client QA: run it as a separate pass rather than jointly with your own. A joint review turns into a design conversation, the client defers to whoever speaks first, and neither party reviews properly. Give them a finished thing and a checklist.

Launch day: the sequence

1. Verify SSL is provisioned and the certificate covers every domain you are switching.
2. Confirm the TTL is actually low, by querying the record rather than by looking at the registrar's interface.
3. Change only the records on your list. A records for the root, CNAMEs for subdomains.
4. Wait 20 minutes before verifying. Checking at minute two produces panic and no information.
5. Verify from more than one network. Your office resolver is not representative. Check from a mobile connection on cellular data as well.
6. Watch for caching phantoms for the first couple of hours. Expect roughly two hours of reports that resolve themselves: a stale page, an old logo, a form that looks wrong. Confirm each one from a clean session before acting on it. Changing something in response to a cache artefact is how a good launch becomes a bad one.
7. Keep tracking on both environments for about a week. You will collect some duplicate analytics data during the overlap. Accept the duplicates rather than risk losing the period entirely. Duplicated data can be identified and cleaned later; a gap cannot be reconstructed.

The week after

Three checks that catch what launch day misses:

• Internal links. Absolute links written against the old domain resolve correctly during staging QA because the old site is still live, so they pass every test right up until the moment they do not.
• The email web-version domain, tested by actually sending a marketing email to yourself and clicking the link.
• Search Console and analytics, confirming the new property is receiving data and the old one has gone quiet in the way you expect.

The bottom line

Lower the TTL one full TTL period ahead, change only the A and CNAME records that need to change, leave mail records alone, pre-provision SSL, and pick a day when someone can respond. Know whether your launch is reversible, because a platform migration is and a same-portal staging overwrite is not, and prepare accordingly. Tag both environments for a week and accept the duplicate data.

None of this is clever. All of it is the difference between a launch nobody remembers and one everybody does.

If your agency sells websites and would rather not carry the launch risk in house, our white-label web design team runs these cutovers under partner brands, and the custom development side handles the builds that sit behind them.