The cutover runbook nobody writes

By cutover day the site has been built, reviewed and tested. It is the known quantity. What has not been tested is the set of things attached to the same domain: mail routing, certificate issuance, subdomains pointing at services somebody set up years ago, and whatever verification records other platforms rely on.

Those are owned by different people, often at different companies, and the person running the migration frequently does not know all of them exist. A registrar account, a hosting control panel, a mail provider and a CDN can be four separate relationships with four separate logins and no shared view.

Export the current DNS zone in full and read every record. For each one, answer two questions: what depends on this, and what happens if it stops resolving for an hour.

The records that catch people are rarely A records. They are the MX entries and their SPF, DKIM and DMARC companions, the TXT records verifying ownership for other services, and the CNAMEs pointing at things like a status page or a legacy webmail host that somebody will notice only when it dies.

A certificate is the other trap. Automated issuance frequently depends on the hostname resolving to the host doing the issuing. Move the record and the renewal can quietly stop working, which produces nothing visible until the existing certificate expires weeks later. If mail services share that certificate, the failure lands on mail, and it lands without a deployment to correlate it with.

A runbook is a numbered list where each step names the change, the person making it, how to confirm it worked, and how to undo it. It is written before the day, not during it.

Lower TTLs at least twenty-four hours ahead, because a record with a day-long TTL cannot be rolled back quickly and rollback speed is the entire safety margin. Move web traffic before touching anything mail depends on, verify, and only then proceed. Confirm certificate issuance on the new host before the old one stops answering.

Then check mail explicitly, in both directions, from an external address. Not by assuming. Send one and reply to it.

Cut over early in the week and early in the day, when the people who hold the other logins are reachable. The reason is not superstition. Propagation, certificate issuance and mail queues all have delays measured in hours, and a fault introduced on Friday afternoon is discovered on Monday by a customer.

Keep the old host running for at least a week. It costs very little and it is the difference between a rollback and an incident.

For the first fortnight the useful signals are not analytics. They are certificate expiry on every hostname including mail, deliverability from an external mailbox, redirect responses spot-checked against the map, and server logs for 404s on paths the inventory missed.

The last one is where the migration finds out what it forgot. Logs after cutover are the honest report on how complete the URL inventory was.