Skip to main content
Operational Runbook

How to Migrate Server to Server

The definitive sysadmin runbook for transferring production web, database, and email workloads between servers with zero downtime and verified data parity.

14 min read
Updated: September 2026
Battle-Tested Runbook
runbook / server-to-server-cutover
root@ops-runner-01:~# # Phase 1: Environment verification
diff -u source_php_modules.txt target_php_modules.txt
No differences found. PHP modules 100% matched.
root@ops-runner-01:~# # Phase 2: Final delta synchronization
rsync -avzHAX --delete --checksum /var/www/ target-server:/var/www/
delta transfer completed in 42 seconds.
root@ops-runner-01:~# # Phase 3: Switch DNS pointer to target IP
nsupdate -k Kdomain.com.+157+12345.key << EOF update delete example.com A update add example.com 300 A 198.51.100.55 send EOF
DNS authoritative pointer updated. Propagation confirmed.
root@ops-runner-01:~#
Quick Answer / Executive Summary

How to migrate server to server: 1) Audit source configs (PHP modules, web vhosts, MySQL variables); 2) Provision target host with modern OS; 3) Perform initial bulk file sync with Rsync; 4) Lower DNS TTL to 300s 48 hours in advance; 5) Validate functionality via local /etc/hosts override; 6) Execute final lock-free delta sync; 7) Repoint DNS records and enable reverse proxy forwarding; 8) Monitor logs and retain source backups for 14 days.

The 8-Phase Server Migration Lifecycle

Migrating a server to a new server without errors requires a structured sequence. Skipping steps or improvising commands mid-cutover is how data loss, database divergence, and dropped client transactions occur.

Follow this step-by-step engineering runbook to execute a seamless transition from start to finish.

STEP 01
Audit & Scope
STEP 02
Target Setup
STEP 03
Bulk Pre-Sync
STEP 04
DNS Staging

Detailed Step-by-Step Execution Guide

1 Discovery & Pre-Migration Audit

Log in to the source server and catalog all active components:

  • Operating system version (cat /etc/os-release)
  • Web server stack (Nginx, Apache, LiteSpeed) and custom configuration directives
  • PHP versions, memory limits, execution timeouts, and installed PECL modules
  • Database engines, character sets, and active database users with permissions
  • Active Cron schedules across all system users (crontab -l)
  • Firewall rules, open ports, and custom fail2ban jails

2 Target Server Setup & Hardening

Provision the new server with a modern long-term support operating system (such as AlmaLinux 9 or Ubuntu 24.04 LTS). Configure security baselines: disable root password logins, enforce SSH key authentication on a non-standard port, configure CSF/UFW firewalls, and match all PHP and database extensions identified in Step 1.

3 Initial Bulk Data Synchronization (Pre-Sync)

While the source server remains live and serving traffic, transfer 95%+ of files and user data using rsync in the background. Because this runs concurrently without taking the server down, large terabyte transfers can run smoothly over several hours.

rsync -avzHAX --numeric-ids --exclude=/tmp/* /var/www/ target-ip:/var/www/

4 DNS TTL Staging (48 Hours in Advance)

Log in to your DNS management provider (Cloudflare, Route 53, BIND, or hosting panel) and lower the TTL (Time-To-Live) on all A, AAAA, and MX records to 300 seconds (5 minutes). This ensures that when you point records to the new IP during cutover, resolvers worldwide will update in minutes rather than days.

5 Pre-Cutover Testing via Local Hosts File

Never switch public DNS blindly. Map the domain name to the new server's IP address on your local computer by editing the hosts file (/etc/hosts on macOS/Linux or C:\Windows\System32\drivers\etc\hosts on Windows):

# Local test mapping
198.51.100.55 example.com www.example.com

Open a browser in incognito mode. Verify SSL certificate handshakes, user authentication, shopping cart checkouts, and database queries against the new server before any public switch.

6 The Cutover Window: Final Delta Sync

During your scheduled maintenance window:

  • Temporarily enable application maintenance mode or set MySQL to read-only.
  • Execute the final delta rsync to copy files modified since the initial pre-sync.
  • Export the final database delta using mysqldump --single-transaction and import it on the target host.
  • Verify row counts and checksums match between source and destination databases.

7 DNS Record Update & Failover Forwarding

Update your authoritative DNS A/AAAA records to the new server IP. On the old server, set up an iptables port forward or an Nginx reverse proxy pointing to the new server. This guarantees that any lingering traffic hitting the old server is immediately routed to the new server without 404 errors.

8 Post-Migration Monitoring & Observation Period

Monitor the new server's web server access logs (tail -f /var/log/nginx/access.log) and mail queue. Verify CPU usage, RAM utilization, and slow query logs. Keep the old server online in a dormant, read-only state for at least 7 to 14 days before final decommission.

Pre-Flight & Post-Migration Health Checklist

Pre-Cutover Full Backup: Create an offsite backup snapshot of the source server prior to initiating cutover.
SSL Pre-Issuance: Pre-generate SSL certificates on the target host before updating public DNS records.
Cron Job Timing: Verify cron jobs are paused during the final delta sync to prevent partial data writes.
Reverse DNS (PTR): Confirm the destination server's public IP has a valid PTR record matching its FQDN mail hostname.
Infrastructure Support

Execute Your Server Migration With Expert Engineering Oversight

Protect application uptime, eliminate data divergence, and ensure verified cutovers with certified Linux systems administrators managing your server transfer.

Speak With a Migration Specialist Explore Migration Services