The DNS Cutover: Moving a Domain Without Going Dark

Everything else in a website migration is reversible in private. This part is not. The moment you change a DNS record, the change is visible to the public and to every search engine that visits, and undoing it takes as long as doing it.

It is also, mechanically, about fifteen minutes of work. The risk is not in the difficulty. It is in the two or three things people do not know they are about to break.

Pointing and transferring are different operations

These get used interchangeably and they are not the same thing at all.

Pointing a domain means leaving its registration exactly where it is and changing the records that say where the site lives. Your registrar stays the same, your billing stays the same, and the change takes effect in minutes to hours. This is all you need to launch on a new platform.

Transferring a domain moves its registration from one registrar to another. It takes days, involves an authorisation code, and is entirely optional. People do it to consolidate billing, which is a decent reason, and they do it because they think it is required, which it is not.

Point first. Transfer later, if at all. Doing them in that order removes the only step with a mandatory waiting period from your critical path.

The sixty-day lock, and why it is not negotiable

If you do intend to transfer, check for the lock before you plan anything around a date.

ICANN’s policy locks a domain against transfer for sixty days after it is registered, after it is transferred, and after the registrant’s contact details are changed. Wix’s documentation of this is clear and worth repeating because it is typical of every registrar: the restriction applies to both incoming and outgoing transfers, and the registrar cannot change it. Wix also notes that completing a transfer locks the domain for a further sixty days afterwards.

The contact-details clause is the one that catches people. Updating your own email address on the domain — exactly the sort of tidying you do when preparing to move — can start a fresh sixty-day clock. If you are planning a transfer, do not touch the registrant contact information first.

Being inside a lock is not a problem. It only becomes one if you had planned the launch around the transfer. Point the domain, launch, and transfer when the window opens.

Lower your TTLs before you need them

TTL, or time to live, is a number on each DNS record that tells resolvers how long to cache it. A record with a TTL of 86,400 seconds is cached for a day, which means a change you make at nine in the morning can still be invisible to some visitors at nine the following morning.

The fix is to plan ahead. A day or two before the cutover, lower the TTL on every record you intend to change — typically the A record, any CNAME, and the www entry. Somewhere in the region of five minutes is a sensible target; Cloudflare’s automatic setting, for reference, is 300 seconds.

Then wait out the old TTL. A record cached for a day stays cached for a day regardless of what you have just changed it to, so lowering the value only helps if you do it before the old value has expired.

One honest caveat. Cloudflare’s own documentation makes the point that it can take longer than the TTL suggests for a change to be felt, because local resolvers and operating systems cache independently of what the record says. Plan for the switch to be quick, but do not promise anyone it will be instant.

Write down your MX and TXT records first

This is the failure that turns a quiet migration into a loud one, and it has nothing to do with the website.

If email for your domain is delivered through MX records that your current provider created — and if you bought a business mailbox through your website builder, it is — then those MX records are part of the same record set you are about to edit. Replace the set wholesale and mail stops being delivered. There is no error message. Senders get bounces or silence, and you find out when a customer asks why you ignored them.

Before you change anything, copy out every record on the domain into a plain text file. In particular:

• MX records, with their priority numbers, exactly as written.
• TXT records, which carry mail authentication and service verification. Losing an SPF or DKIM record does not stop mail arriving so much as start it going to spam, which is harder to notice and harder to diagnose.
• CNAMEs for subdomains, which are often pointing at services you forgot you set up.

Then, after the switch, re-enter every one of them on the new side.

There is a related trap on the billing side. Website builders commonly sell the site plan, the domain and the business mailbox as three separate subscriptions that renew and cancel independently. Cancelling the site plan does not cancel the mailbox, and cancelling the mailbox is not implied by moving the site. Check all three explicitly.

The sequence on the day

Pick a quiet weekday morning. Not a Friday, and not the day before you are away.

1. Confirm the new site is complete and its password protection is off.
2. Confirm your redirect map is loaded on the new platform and spot-check five rules.
3. Open your written record of the current DNS entries and have it visible.
4. Change the A record, and the www CNAME or equivalent, to the new platform’s values.
5. Re-enter the MX records and every TXT record immediately, in the same session.
6. Wait. Ten minutes, then check.
7. Check from a device that has never loaded the new site — a phone on mobile data is ideal. Your own machine has been caching things all week and will tell you comfortable lies.
8. Send an email to the domain from an outside address, and reply to it from the mailbox.
9. Walk the customer path: find a page from a search result, follow it, submit a form, complete a purchase if you have one.

If something is wrong, you can put the old record back. That is the reason the old site is still running and the old plan is still paid, and it is the reason running both sites in parallel is not optional.

What to watch for the rest of the week

Certificate warnings. Most platforms issue an HTTPS certificate automatically once the domain resolves to them, and there is usually a gap of minutes to hours between the DNS change and the certificate being ready. A browser warning during that window is expected. A browser warning the next day is not, and means the platform has not completed its side.

Mixed results between devices. Perfectly normal for a few hours while caches expire, and exactly why you lowered the TTLs.

Your 404 report. Check it daily. Every entry is a URL missing from your redirect map.

Email, twice a day. Send and receive, both directions, for the first three days. Silence is not evidence that mail is working.

The rest of the order of operations, and where this step sits in it, is on the plan for switching website builders.