Infrastructure · Operations
Hosting Migration Guide: Zero-Downtime Cutover, DNS, and Rollback
A hosting migration is far less risky than its reputation when you treat it as a staged, reversible change rather than a single leap. The reliable process is audit, build and test the new environment, switch DNS, then monitor — and the cardinal rule is to never send live traffic to a server you haven’t tested. Most migration downtime comes from the DNS cutover, so you lower your DNS TTL to around 300 seconds 24 to 48 hours ahead, pre-sync your data so only a small final sync happens at cutover, and switch only after the new environment is proven. Email needs its own plan to avoid “split-brain,” where some mail lands on the old server and some on the new. Throughout, you keep the old server running for at least 48 hours so you can roll back by simply reverting the DNS records if anything looks wrong.
Key takeaways
- Stage it: audit, build, test, switch, monitor. Never point live traffic at an environment you haven’t verified.
- Lower DNS TTL early. Drop it to ~300 seconds 24–48 hours before cutover so the switch propagates in minutes.
- Pre-sync your data. Bulk-transfer ahead of time so only a quick final sync happens during the cutover window.
- Email needs its own cutover. Mishandled MX changes cause split-brain, where replies silently vanish.
- Keep a rollback path. Low TTLs plus an intact old server let you revert in minutes if something breaks.
The fear that stops teams migrating hosts is the same one every time: breaking DNS and taking the site or email offline. But the downtime and lost mail people associate with migrations come from skipped steps and poor sequencing, not from inherent complexity. Handled as planned change management, a migration is a controlled, reversible handoff. This guide walks the process that makes it boring — which, in migrations, is exactly the goal.
What’s the right migration process?
The most successful migrations follow a structured, testable workflow with four phases: audit the existing setup, build and test a copy on the new environment, switch DNS to move traffic, and monitor afterward. The single principle underpinning all of it is that you never send live traffic to an environment you haven’t tested. Each phase reduces risk before the next — the planning eliminates unknowns, the build creates a verified copy, the DNS switch moves traffic only when everything is confirmed ready, and the monitoring catches anything that slipped through. The diagram shows the flow.
This staging is what turns a scary migration into a predictable one. Through the audit and build phases, nothing touches your live site — DNS still points at the old server, so visitors, search engines, and email keep operating normally while you assemble and verify a complete copy on the new environment. Only when that copy is proven do you move traffic. The mistake that causes most migration horror stories is collapsing these phases, building and cutting over in one rushed session without a tested destination.
Inventory: what you must document first
The audit phase lives or dies on the thoroughness of your inventory, because the things that break a migration are almost always the ones nobody wrote down. Beyond the obvious files and databases, you need to catalogue every domain and subdomain, every mailbox and forwarder, all cron jobs, your SSL certificates, and — most easily forgotten — the third-party integrations wired to your domain or IP. Payment gateway webhooks, CRM connections, SMTP relays, analytics scripts, and any API that whitelists your current server’s IP will all silently fail if they’re not on the list and updated as part of the move.
A frequently overlooked trap in this category is outbound SMTP. Many hosts block outbound mail by default to curb abuse, so a contact form that worked perfectly on the old server can fail silently on the new one until you explicitly arrange for sending. The inventory’s companion is a genuinely complete backup — not just the website files, but the database, email, the exported DNS zone, SSL certificates, and cron jobs — captured before you change anything. That backup is your ultimate rollback, so its completeness is worth verifying rather than assuming.
How do you plan the DNS cutover?
DNS is where most migration downtime actually happens, and managing it well is mostly about timing the TTL — the time-to-live value that tells resolvers how long to cache a record. A default TTL might be 24 hours, meaning resolvers can keep serving your old server’s IP for a full day after you change it. The fix is to lower the TTL to around 300 seconds, 24 to 48 hours before your planned cutover, so that by switch time the long cached values have aged out and the change propagates in minutes rather than hours.
The sequencing detail that trips people up is that you must lower the TTL far enough ahead for the old, longer TTL to expire first. The table shows the timeline.
| When | Action | Why |
|---|---|---|
| 48 hrs before | Lower TTL to ~300s | Old long TTL ages out first |
| Cutover window | Change A/AAAA (and MX if moving mail) | Short TTL means fast propagation |
| First hour | Monitor logs and resolution | Catch errors early; rollback ready |
| After it settles | Raise TTL back to 3600s+ | Reduce DNS query load |
One more choice matters: for a hosting-only move where you’re keeping the same DNS provider, updating the A and AAAA records is usually safer than switching nameservers, because a nameserver change risks dropping records you forgot to recreate in the new zone. Either way, perform the actual switch during a maintenance window while the short TTL is active, so that if you make a mistake you can revert the record and most users will see the fix within minutes.
Why does email need its own plan?
Email is the part of a migration most often overlooked and most painful when it goes wrong. The classic failure is “split-brain”: if you change your MX records carelessly, some senders deliver to your old mail server while others reach the new one during propagation, so replies seem to vanish because they landed on a server nobody’s checking. This is why mail needs a deliberate, separate cutover rather than being swept along with the website switch.
The safe pattern is to leave MX records alone until the new mail server is fully proven, then switch them during a quiet window, and crucially to keep the old mailboxes active and monitored for at least 48 hours afterward so nothing is lost during propagation. Before any of this, export your DNS zone and document the records that quietly matter — MX, SPF, DKIM selectors, DMARC, and autodiscover — exactly, because these are the ones whose absence breaks delivery silently. Getting the authentication records right is essential, as our email authentication guide details, since a missed DKIM selector means mail that sends but doesn’t land.
Choosing a migration strategy
Not every migration uses the same approach, and matching the strategy to your risk tolerance shapes everything else. The fastest is the “big bang” or lift-and-shift, where you move everything at once — simple and quick, but carrying the highest risk if the new environment doesn’t initialise cleanly. A phased approach reduces that risk by moving non-critical systems first, letting your team refine the process on low-stakes workloads before touching production. And a parallel or “swing” migration, where you run production on a temporary environment while the move happens, is the gold standard for operations that need continuous availability, at the cost of more infrastructure and complexity.
Whichever you choose, one principle holds across all of them: don’t change too many things at once. Combining a host move with a domain change and a redesign in a single migration multiplies the risk exponentially, because when something breaks you can’t tell which change caused it. The disciplined approach is to make each migration a single, debuggable change — move the hosting first, prove it stable, and only then take on the next change. That sequencing turns a high-variance gamble into a series of small, reversible steps, each one easy to verify and undo.
Transferring data without losing any
Moving the data itself has two goals: lose nothing, and minimise the downtime window. The technique that achieves both is pre-syncing. Rather than copying everything during the cutover, you bulk-transfer the bulk of your files and database ahead of time using tools that preserve permissions and timestamps — rsync on Linux or its Windows equivalents — then run a quick final sync of only the recent changes at cutover. That staged approach shrinks the actual downtime to the length of a small delta sync rather than a full copy, and for very large databases, replication can keep the new system synced in real time until the moment you switch.
The step people skip at their peril is verifying integrity. After transferring, run checksums or hashes on the files and compare them against the source, because a partial transfer or silently truncated database is worse than an obvious failure — it looks fine until something breaks in production. The same diligence applies to backups: a backup that exists but turns out to be incomplete, missing its database, or unrestorable on the new server’s paths is no safety net at all. Prove your backup with an actual restore test, a discipline our backup strategy guide treats as non-negotiable.
Testing before you switch
The whole staged approach hinges on being able to test the new environment thoroughly before any live traffic reaches it, and the tool for that is a preview mechanism — a staging URL, a temporary hosts-file entry, or a preview link — that lets you load the site on the new server while DNS still points at the old one. This is what makes “never send live traffic to an untested environment” actually achievable rather than aspirational. You build the full copy, point your own machine at it, and exercise it as a real user would.
A real test goes well beyond loading the homepage. You click through navigation to catch broken links, submit every form, confirm the SSL certificate is valid with no mixed-content warnings, check that redirects still fire, run through transactional flows like checkout and login, exercise any API endpoints, and trigger a test email from the application. Environment parity is a frequent culprit here: if the new server defaults to a different PHP version than the old one was pinned to, plugins and applications can break in ways that only surface under real use, which is exactly what pre-cutover testing is meant to catch.
What goes wrong, and how to avoid it
Most migration failures are a small, recurring set of mistakes, and knowing them in advance is most of the defense. The terminal lists the usual suspects.
# The migration mistakes that cause real downtime TTL LEFT HIGH … users keep hitting the old server for hours EMAIL SPLIT-BRAIN . MX changed carelessly; replies disappear PHP MISMATCH … new server’s version breaks pinned plugins SSL NOT RECREATED . missing intermediates or wrong SAN list BACKUP UNRESTORABLE exists but no DB, or wrong paths/permissions SMTP BLOCKED … outbound mail off by default; forms fail silently NO ROLLBACK PLAN .. old server killed before new one is proven # A “boring” cutover rarely needs a rollback — aim for boring.
The thread connecting these is that they’re all preventable in the planning phase. A thorough inventory catches the outbound-SMTP block and the third-party integrations — payment webhooks, CRM connections, API whitelists tied to your old IP — before they fail in production. A complete backup that includes files, database, email, the DNS zone, SSL, and cron jobs gives you a real parachute. And resisting the urge to change too many things at once — host plus domain plus redesign in a single move multiplies the risk exponentially — keeps each migration a single, debuggable change rather than a tangle of simultaneous variables.
How do you keep a rollback path?
A safe migration is a reversible one, and rollback rests on two simple principles working together: low TTLs and an intact old environment. Because you lowered your TTL before cutover, a bad switch can be undone in minutes — you simply revert the A and AAAA records, or change the nameservers back, and the short TTL means most users return to the working old server quickly. This is only possible if you haven’t touched the old server yet, which is why you keep it fully running for at least 48 to 72 hours after cutover rather than decommissioning it the moment the new one looks alive.
The discipline to add is identifying your “point of no return” — the moment when reverting becomes impossible or more damaging than pushing forward, typically once new data has accumulated on the new server that the old one doesn’t have. Knowing where that line sits tells you how long your rollback window really is and when to commit fully. Only after you’ve confirmed everything works on the new server, monitored it across a couple of days, and passed that point should you cancel the old hosting. For teams that want a stable, well-provisioned destination to migrate onto — with the monitoring and rollback headroom a clean cutover needs — our dedicated servers in Toronto give you full control of the target environment, while the staged, reversible process above is what keeps the move boring.