How to Migrate a Dedicated Server to VPS Without Downtime: A Complete Guide

Moving from a dedicated server to a VPS is one of the most common infrastructure decisions a sysadmin faces — whether the dedicated box has reached end-of-life, costs have spiralled, or the workload simply no longer justifies the hardware. The good news is that you can migrate a dedicated server to a VPS with zero downtime if you plan the cutover correctly. This guide walks you through every stage: pre-migration audit, VPS provisioning, live rsync sync, DNS cutover, and post-migration verification.

Why Migrate from a Dedicated Server to a VPS?

Dedicated servers made sense when vertical scaling was the only option. Today, VPS instances on modern hypervisors offer comparable single-thread performance, far better flexibility, and a fraction of the cost. Here are the top reasons sysadmins make the switch:

• Cost reduction — A mid-range VPS costs 60–80 % less than an equivalent dedicated box, with no hardware replacement cycle.
• Instant vertical scaling — Upgrade vCPUs and RAM in minutes through the control panel rather than ordering and racking physical hardware.
• Snapshot backups — VPS providers offer one-click snapshots that let you roll back the entire server state — something dedicated servers rarely provide out of the box.
• End-of-Life hardware — EOL servers carry mounting security and reliability risk. Migrating to a VPS eliminates exposure to ageing CPUs, drives, and NICs.
• Geographic flexibility — Spin up the new VPS in a data centre closer to your user base without a contract renegotiation.

Whatever the driver, the migration itself follows the same repeatable pattern. Let's start at the beginning.

Pre-Migration Audit: What to Inventory Before You Start

Skipping the audit is where most painful migrations begin. Before you touch the new VPS, spend an hour documenting exactly what lives on the dedicated server.

1. Software Stack Inventory

Run the following on the dedicated server to capture installed packages and their versions:

# Debian / Ubuntu
dpkg --get-selections > /root/pkg-list.txt

# RHEL / CentOS / AlmaLinux
rpm -qa > /root/pkg-list.txt

Note the OS version precisely — if the dedicated server runs Ubuntu 20.04 and you provision Ubuntu 24.04 on the VPS, library differences can silently break applications.

2. Running Services

systemctl list-units --type=service --state=running

Export the list and check for non-standard init scripts, cron jobs, and supervisor processes:

crontab -l > /root/root-crontab.txt
ls /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/

3. Network Configuration

Record all bound IPs, firewall rules, and open ports:

ip addr show
ss -tlnp
iptables-save > /root/iptables-backup.txt

4. Disk Usage Breakdown

df -hT
du -sh /var/www /home /etc /opt 2>/dev/null

This tells you the minimum VPS disk size you need. Add at least 20 % headroom.

5. Database Inventory

# MySQL / MariaDB
mysql -u root -p -e "SHOW DATABASES;"

# PostgreSQL
sudo -u postgres psql -c "\l"

Document the database engine version — version mismatches are the single most common cause of post-migration failures.

6. Lower DNS TTL Now

This is the most time-sensitive step and must be done before you do any other work. Log in to your DNS registrar or nameserver and reduce the TTL for all A records pointing to the dedicated server to 300 seconds (5 minutes). Wait at least 24–48 hours so the old TTL expires everywhere before you perform the cutover. Doing this early means your DNS change will propagate globally within minutes when you finally flip the switch.

Setting Up Your New VPS to Mirror the Dedicated Server

1. Choose and Provision the Right VPS

Match the OS family and version as closely as possible. If the dedicated server runs CentOS 7, migrate to AlmaLinux 8 or Rocky Linux 8 (same ecosystem, modern kernel). Provision the VPS with at least as much RAM as the dedicated server's current working set — check with free -h and vmstat on the old box.

2. Install and Configure the Same Software Stack

Use your package list from Step 1 to install matching software:

# Debian / Ubuntu — install from saved list
dpkg --set-selections < /root/pkg-list.txt
apt-get dselect-upgrade -y

For web stacks, install matching versions of NGINX/Apache, PHP, Node.js, or Python runtimes. Pin versions explicitly to avoid auto-upgrades pulling in breaking changes.

3. Create Matching Users and Groups

rsync preserves numeric UIDs and GIDs, not names. If www-data is UID 33 on the old server but UID 1001 on the new one, file ownership will break. Synchronise them:

# On old server
id www-data
# uid=33(www-data) gid=33(www-data)

# On new VPS — set matching IDs if they differ
usermod -u 33 www-data
groupmod -g 33 www-data

4. Set Up SSH Key Authentication Between Servers

rsync will use SSH. Generate a key pair on the new VPS and add the public key to the dedicated server's authorized_keys:

# On new VPS
ssh-keygen -t ed25519 -C "migration-key" -f ~/.ssh/migration_key -N ""
ssh-copy-id -i ~/.ssh/migration_key.pub root@OLD_SERVER_IP

Test the connection before proceeding:

ssh -i ~/.ssh/migration_key root@OLD_SERVER_IP "echo Connection OK"

5. Configure Firewall Rules on the New VPS

Replay the iptables backup from your audit, or recreate the rules in ufw/firewalld. Ensure port 22 is open for SSH from your management IP before closing the session.

Transferring Data with Rsync and Zero-Downtime DNS Cutover

This is the heart of the migration. The strategy is to perform a bulk sync first, then a fast delta sync just before the DNS flip — keeping the old server warm as a rollback target throughout.

1. Initial Bulk Rsync (can run for hours — that's fine)

Run this from the new VPS, pulling data from the old dedicated server:

rsync -avz --progress   -e "ssh -i ~/.ssh/migration_key"   --exclude=/proc   --exclude=/sys   --exclude=/dev   --exclude=/run   --exclude=/tmp   --exclude=/mnt   root@OLD_SERVER_IP:/ /

Flags explained:

• -a — archive mode: preserves permissions, ownership, symlinks, and timestamps
• -v — verbose output so you can monitor progress
• -z — compress data in transit to reduce transfer time
--exclude — skips virtual filesystems that must not be copied

For large servers, run this inside a screen or tmux session so an SSH disconnect doesn't abort the transfer:

screen -S migration
# then run the rsync command above

2. Migrate Databases

For MySQL/MariaDB, dump with --single-transaction to get a consistent snapshot without locking tables:

# On old dedicated server
mysqldump --all-databases   --single-transaction   --quick   --lock-tables=false   -u root -p > /root/all-databases.sql

# Transfer the dump to the new VPS
rsync -avz -e "ssh -i ~/.ssh/migration_key"   /root/all-databases.sql   root@NEW_VPS_IP:/root/

# On new VPS — import
mysql -u root -p < /root/all-databases.sql

For PostgreSQL:

# On old server
sudo -u postgres pg_dumpall > /root/pg_all.sql

# Transfer and import on new VPS
rsync -avz -e "ssh -i ~/.ssh/migration_key"   /root/pg_all.sql root@NEW_VPS_IP:/root/
sudo -u postgres psql < /root/pg_all.sql

3. Test the New VPS with a Hosts File Override

Before touching DNS, verify that every site works correctly on the new VPS by temporarily overriding your local hosts file:

# On your local workstation (Linux/macOS)
sudo nano /etc/hosts
# Add:
NEW_VPS_IP   yourdomain.com www.yourdomain.com

Visit the site in your browser, test logins, check API endpoints, run the application's own health checks. Fix any issues before proceeding. Remove the hosts file override when you're done testing.

4. Final Delta Rsync (minutes before DNS cutover)

Because the bulk sync already ran, this delta sync transfers only files changed since then — typically completing in seconds to a few minutes:

rsync -avz --delete --progress   -e "ssh -i ~/.ssh/migration_key"   --exclude=/proc --exclude=/sys   --exclude=/dev --exclude=/run   --exclude=/tmp --exclude=/mnt   root@OLD_SERVER_IP:/ /

The --delete flag removes files from the new VPS that were deleted on the old server since the first sync, keeping both servers perfectly in sync.

5. Do a Final Database Dump and Import

Repeat the database dump and import from Step 2. This captures any writes that happened after your first dump. If you have high write volume, consider putting the application into brief read-only or maintenance mode for 60–120 seconds at this point to guarantee zero data loss during the final DB sync.

6. DNS Cutover

With the new VPS validated and data synced, update your A record to point to the new VPS IP. Because you pre-staged the TTL to 300 seconds (Step 6 of the audit), propagation completes within 5 minutes for most resolvers:

# Verify propagation from multiple vantage points
dig @8.8.8.8 yourdomain.com A +short
dig @1.1.1.1 yourdomain.com A +short

Once both return the new VPS IP, traffic is flowing to the new server.

7. Keep the Old Dedicated Server Warm for 48 Hours

Do not shut down or reprovision the old server immediately. Visitors whose DNS resolvers cached the old TTL will still route to the dedicated server for up to the old TTL duration. Keep the old server running and serving traffic for a minimum of 48 hours after the DNS flip. This is your live rollback — if a critical issue surfaces on the new VPS, revert the A record to the old IP and you're back in seconds.

Need expert help planning or executing the migration? The CloudHouse server migration service handles the entire process end-to-end with a guaranteed rollback plan.

Post-Migration Checklist: Verifying Everything Works

Once DNS has fully propagated, run through this checklist methodically before decommissioning the old server.

Application Layer

• All web applications load and render correctly
• User login and session management work
• File uploads save to the correct directory
• Outgoing email (SMTP) sends successfully
• Background jobs and cron tasks are running (systemctl status, crontab -l)
• SSL/TLS certificates are valid and auto-renewing (check with certbot certificates)

Database Layer

• Query key tables to confirm row counts match between old and new servers
• Confirm replication is not still pointing at the old server
• Run application-level smoke tests that exercise DB writes

Performance Baseline

• Run top, htop, or vmstat 1 10 under real traffic and compare CPU/memory to the old server's baseline
• Check response times with curl -o /dev/null -s -w "%{time_total}" https://yourdomain.com/
• Review error logs: tail -f /var/log/nginx/error.log, application logs

Security Checks

• Confirm firewall rules are active: iptables -L -n or ufw status
• Disable root SSH login if not already done: set PermitRootLogin no in /etc/ssh/sshd_config
• Run a port scan from an external IP to verify no unexpected ports are open
• Confirm fail2ban or equivalent brute-force protection is running

Monitoring and Alerting

• Update monitoring agents (Zabbix, Prometheus node_exporter, Datadog) with the new server IP
• Set up uptime alerts if not already in place
• Confirm log aggregation (if any) is sending from the new server

Decommission the Old Server

After 48–72 hours of clean operation on the new VPS with no issues, take a final snapshot or backup of the old dedicated server, then cancel it. Keep the snapshot for at least 30 days as a cold archive.

FAQs

See the FAQ section below for answers to the most common questions about dedicated-to-VPS migration.

Migrating a dedicated server to a VPS without downtime is entirely achievable with disciplined preparation. Lower the DNS TTL early, sync data incrementally with rsync, validate thoroughly on the new VPS before the DNS flip, and keep the old server warm as a live rollback. Follow this process and your users will never notice the move. For teams that want the migration handled by specialists — including full rollback guarantees and post-migration monitoring — CloudHouse Technologies offers a dedicated server migration service built around exactly this methodology.