Skip to main content

Server migration checklist

Work through pre-cutover prep, the cutover itself, and post-cutover monitoring when moving a production service to a new server. Each task has an optional note field for an owner, due date, or link — check items off as you complete them, then export the whole checklist (with your notes) to a branded PDF or a CSV for your migration record.

Frequently asked questions

Why reduce DNS TTL 48 hours before cutover instead of right before?

DNS records are cached by resolvers around the internet for however long the TTL says, so if you drop the TTL right before cutover, plenty of resolvers are still holding the old, longer TTL value and won't check back in time. Lowering it a full 48 hours ahead gives those cached records time to expire naturally, so that when you actually flip DNS at cutover, the change propagates in minutes instead of hours — and if you need to roll back, that rollback also propagates fast.

How long should I keep the old server running after cutover before decommissioning it?

Keep it running at minimum until you've watched error rates and traffic stabilize on the new environment — an hour is a reasonable floor, but for anything with meaningful traffic, a full business day (or a full weekly cycle if traffic is uneven by day) gives you a much safer margin. The old server is your fastest rollback path for as long as it exists; decommissioning it early to save cost is the single most common regret in a migration that goes even slightly wrong.

What should smoke-testing the new environment cover before I cut over?

Focus on the critical paths a user or downstream system actually depends on: login, checkout or core transactions, API endpoints other services call, and any scheduled jobs or webhooks. The goal isn't exhaustive coverage — it's catching the class of failure that only shows up in the new environment (missing environment variable, different file permissions, a firewall rule that didn't carry over) before real traffic hits it.

Share this tool