Moving a busy site to new servers: a DNS cutover checklist

Moving a site to new infrastructure is mostly preparation. The servers get built, the application is deployed, tests pass, and then everything depends on one short window when traffic moves from the old environment to the new one. That window is where migrations go wrong: orders written to the old database after the final sync, cached DNS sending some customers to the old servers for hours, background jobs running in both places at once, and nobody quite sure how to switch back. This is the checklist we use for busy sites, broken into the week before, the day of, and the days after.

One to two weeks before

Most of the risk is removed long before cutover.

1. Inventory everything. List every domain and subdomain, every cron job, every queue worker, every inbound webhook, every outbound IP allowlist at a partner, every mail sending configuration and every file path the application writes to. Missed items in this list are the most common cause of post-migration issues.
2. Lower DNS TTLs. Reduce the TTL on records that will change to 300 seconds or less, at least 48 hours before cutover, so resolvers have time to expire the old, longer values. Skipping this is why some visitors keep reaching the old server for a day.
3. Build and test the new environment. Deploy the application, restore a recent copy of the data, and run the full test suite plus a manual walkthrough of the critical journeys. Use a hosts file entry or a temporary hostname to test against the new servers directly.
4. Load test. Replay or simulate peak traffic against the new environment. New servers with different CPU types, disk performance or network paths can behave differently under load.
5. Write the rollback plan. Decide in advance what failure looks like and exactly how you switch back. Include who makes the call.

A migration plan without a rehearsed rollback is not a plan. It is a hope with a timestamp.

Choosing a data sync strategy

How you move the database determines how long any write freeze lasts. There are three broad options:

• Dump and restore at cutover. Simple, but the freeze lasts as long as the dump, transfer and restore. Acceptable for databases under a few gigabytes.
• Replication. Set the new database up as a replica of the old one, let it catch up over days, then promote it at cutover. The freeze shrinks to the seconds needed for the replica to apply the last changes. This is our default for anything transactional.
• Managed migration services. Cloud providers offer tools that handle continuous replication between environments, useful when moving between providers or engine versions.

Files need the same thinking. Uploads should be synced in bulk ahead of time and then incrementally in the final window; better still, move them to shared object storage before the migration so both environments read from the same place.

The cutover sequence

On the day, we follow a written sequence with a named owner for each step and a shared channel where each step is marked done.

1. Confirm replication lag is near zero and the new environment is healthy.
2. Stop scheduled jobs and queue workers on the old environment so nothing runs twice.
3. Put the old application into read-only mode, or show a brief maintenance message on write paths such as checkout and account updates, while leaving browsing available.
4. Wait for replication to catch up fully, then promote the new database and verify row counts on key tables.
5. Point the old application at the new database, or configure the old load balancer to proxy to the new environment. This catches visitors whose DNS has not yet updated.
6. Update DNS records.
7. Start scheduled jobs and workers on the new environment.
8. Remove read-only mode and run the smoke tests against production.

Step five is the one most checklists miss. Proxying from old to new means that stale DNS caches do not matter: every request ends up at the new environment regardless of which IP a visitor resolved. For busy stores, this single step prevents almost all split-brain problems.

location / {
    proxy_pass https://new-origin.example.internal;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

For most clients the write freeze lasts between two and ten minutes. We schedule it in the lowest-traffic hour, which analytics usually puts somewhere between two and five in the morning local time for the main market.

Verification and the days after

A migration is not finished when DNS changes. For the following 72 hours we watch:

• Error rates and latency against the baseline from the old environment.
• Traffic still arriving at the old servers, which should fall to near zero within a few hours once TTLs expire.
• Outbound email delivery, since new sending IPs can trigger spam filtering if SPF records were not updated.
• Webhooks from payment providers and other partners, whose delivery logs show whether they are reaching the new endpoints.
• Scheduled jobs, checking each ran once and only once.

We keep the old environment intact, but idle, for at least a week. Once everything is confirmed, we take a final backup, decommission it and restore normal TTLs.

Plan your move with people who have done it

Most migrations we run finish with customers noticing nothing at all, which is the goal. Our server migrations service handles the planning, rehearsal and cutover end to end, and where a move is a good moment to reconsider the database, we bring in our database scaling work at the same time.

Get a fixed-price migration plan

Tell us where you are hosted today, where you want to be, and roughly how busy the site is. We will return a fixed-price migration plan, including the cutover window we recommend, within a day. Send us the details.