Dedicated Server Migration Guide: How to Move Without Downtime

"Zero downtime" migration is slightly aspirational marketing language — what you can realistically achieve is downtime measured in seconds rather than hours, by running old and new servers in parallel and cutting over traffic only once the new server is fully validated. This guide walks through that process end to end: pre-migration planning, the actual data and configuration transfer, DNS cutover mechanics, and — the part most guides skip — a rollback plan you have actually tested before you need it under pressure.

Why Migrations Go Wrong

The overwhelming majority of migration disasters trace back to one of three causes: DNS TTLs left at their old (often 24-hour+) default so the cutover takes far longer to propagate than planned, a database that changed during the transfer window (users kept writing to the old server while data was being copied), or no tested rollback path, so a problem discovered post-cutover has no fast way back to the known-good state.

Migration Timeline Overview

Step 1: Lower DNS TTL Well Before You Migrate

At least 48-72 hours before migration, lower your DNS record TTL to 300 seconds (5 minutes) or less. DNS changes only propagate as fast as the previous TTL allows — cutting over with a stale 24-hour TTL still in effect means some visitors keep hitting the old server for up to a day after you have already switched.

Step 2: Provision and Fully Configure the New Server First

Set up the new dedicated server completely — OS, web server, database, application stack, firewall (see our firewall configuration guide), and monitoring — before touching any live traffic. Run it entirely in parallel, reachable only by its own IP or a staging subdomain, so you can validate it thoroughly without any user ever hitting it prematurely.

Step 3: Initial Bulk Data Transfer

Copy the bulk of static files first, while the old server remains fully live and serving traffic:

rsync -avz --progress /var/www/ user@new-server-ip:/var/www/
mysqldump --single-transaction --routines --triggers old_db > full_backup.sql
scp full_backup.sql user@new-server-ip:/tmp/

For a large database, this initial dump can take hours — that is fine, since the old server is still serving live traffic and nothing user-facing depends on this step finishing quickly.

Step 4: Delta Sync Immediately Before Cutover

Just before the actual cutover, re-run rsync (which only transfers changed files, making the second pass fast) and take a fresh, small database dump of only the records that changed since the initial dump — or briefly pause writes on the old server for a short, well-communicated maintenance window if your application cannot easily track "changed since" deltas.

Step 5: Validate the New Server Before Any Real Traffic Hits It

• Edit your local /etc/hosts file to point your domain at the new server's IP and browse the full site as a real user would
• Confirm database connectivity, application logins, file uploads, and any payment/checkout flow explicitly — do not assume "the homepage loads" means everything works
• Check SSL/TLS certificates are correctly installed and valid on the new server before cutover, not after
• Run through your own security checklist on the new server since a migration is exactly when firewall rules or SSH config get accidentally missed

Step 6: The Actual Cutover

1. Do a final delta sync (or brief write-pause) to catch last-minute changes
2. Update DNS A/AAAA records to point at the new server's IP
3. Monitor both servers' logs simultaneously — the old server for any lingering traffic (indicating incomplete DNS propagation) and the new server for errors
4. Keep the old server fully running and untouched for at least 24-72 hours as your immediate rollback path

Step 7: Post-Cutover Monitoring

Watch application error logs, response times, and database query performance closely for the first 24-72 hours — see our monitoring guide for the specific metrics worth tracking during this window. Only decommission the old server once you are fully confident the new one is stable under real production load, not just synthetic testing.

Rollback Plan: Test It Before You Need It

Your rollback plan is simply reverting the DNS change back to the old server's IP — which only works instantly if the old server is still running, untouched, and its data has not diverged meaningfully from the new one. This is precisely why step 6 says to keep the old server alive and running for days after cutover rather than decommissioning it immediately to save a few dollars in overlap costs.

Special Case: Database-Heavy Migrations

For write-heavy databases where even a short pause is disruptive, consider setting up real-time replication (MySQL replication, PostgreSQL streaming replication) from old to new server ahead of the cutover, so the new server's database stays continuously in sync until the moment of cutover rather than relying on a single dump-and-restore delta window.

Common Migration Mistakes

• Forgetting to lower DNS TTL far enough in advance, extending the effective cutover window unnecessarily
• Migrating cron jobs and scheduled tasks as an afterthought, only noticing missing scheduled backups or reports days later
• Not testing SSL certificate validity on the new server until after cutover
• Decommissioning the old server too quickly, eliminating the rollback safety net before the new server has proven itself under real load

Buyer's Checklist

• Does your new provider offer IPMI/remote console access for the new server during setup, before it is even reachable via SSH?
• Is there a way to run the new server in parallel (its own IP, staging subdomain) before any DNS cutover?
• Does your current and new provider both support the same backup/transfer tooling (rsync, standard database dump formats)?
• Have you documented every cron job, scheduled task, and background worker running on the old server, not just the obvious web stack?

Frequently Asked Questions

Can a dedicated server migration really have zero downtime?

Practically, downtime can be reduced to seconds (the brief write-pause during final delta sync, if used) rather than true mathematical zero — full zero-downtime typically requires database replication rather than a dump-and-restore approach.

How long before migration should I lower DNS TTL?

At least 48-72 hours, since DNS caching resolvers around the internet respect the previous TTL until it naturally expires.

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

A minimum of 24-72 hours of stable operation on the new server before decommissioning the old one — longer for complex applications where subtle issues might only surface under specific real-world traffic patterns.

What is the biggest risk in a database migration specifically?

Data written to the old server after your dump was taken but before cutover — either use replication to avoid this entirely, or a brief, well-communicated write-pause immediately before cutover.

Should I migrate everything at once or in phases?

For complex multi-service applications, phased migration (database first, then application tier, then static assets) with validation at each stage reduces the blast radius of any single mistake compared to one big-bang cutover.

Do I need downtime for SSL certificate migration?

No — install and validate SSL certificates on the new server before cutover so HTTPS works correctly from the very first request the new server receives.

Migrating to new hardware is much less stressful with a provider that supports parallel-running validation and offers hands-on help during cutover. See our dedicated server plans or contact our migration team for a guided, zero-surprise cutover.