What to freeze during a migration window

The freeze begins the moment you take the copy you intend to keep, not the moment you change DNS. Every write that lands on the old environment after that snapshot lives in one place only, and at cutover it is either lost or re-entered by hand. So the real decision is not whether to freeze, but which writes you can afford to lose and which you have to catch.

What has to stop, and what it costs if it does not

How long the freeze actually needs to be

One number does not describe it. Plan two nested windows.

1. Soft freeze, starting two or three days ahead. No updates, no bulk imports, no zone edits, no new integrations. Publishing still allowed. This is the window where you also drop record TTL to something like 300 so the hard window can be short.
2. Hard write freeze, running from the final sync until the new server is confirmed as the one answering. Its length is the final delta sync plus your longest cached TTL plus the time you need to check the site. For a modest database and a lowered TTL that is commonly one to three hours. If your estimate exceeds a working shift, the delta sync is too large and needs a prior full copy.

Telling people who would otherwise keep working

• Announce a clock time with the timezone spelled out, plus the condition that ends the freeze. "Until we confirm" alone invites people to guess.
• Remove the ability, not only the permission. Maintenance mode, a read-only database user, revoked editor roles, disabled cron, a closed contact form. Anything left clickable will be clicked.
• Give the work somewhere else to go. Editors will happily draft in a document and paste later if you say so in advance.
• Name one person who can lift the freeze, so nobody unfreezes early to be helpful.

The things you cannot freeze

Incoming mail is the main one. Do not attempt it. Keep MX pointed at the old mail host until mailboxes are copied, and treat the mail cutover as a separate event from the web cutover so one cannot drag the other. Live transactions are the second: if the checkout genuinely cannot close, move during your quietest hour and treat the payment provider dashboard, not your own database, as the record of what happened. Pause third-party writes at the source where you can, since webhooks and scheduled feeds tend to replay themselves into duplicates.

Reconciling what slipped through

1. Before the snapshot, write down the exact cut time in UTC. Everything below depends on it.
2. Keep the old environment running and readable for a few days. Do not cancel it on cutover day.
3. Query the old database for rows newer than the cut time, table by table, and eyeball the list before touching anything.
4. Compare the uploads directory by modification time to find files added after the copy.

SELECT id, created_at FROM orders WHERE created_at > '2026-08-01 22:00:00';
find /old/uploads -newermt '2026-08-01 22:00' -type f

Re-enter the results rather than importing them wholesale. A stray insert can collide with IDs the new environment has already issued, which turns a small reconciliation into a genuine data problem. Related planning sits in the Moving In guides, and the checks that follow a cutover are covered in Launch Playbooks.