Virtualization

When to Move from a VPS to a Dedicated Server

Your WordPress site suddenly takes three seconds to answer a page, top shows the load average pinned at 8 on a 2 vCPU box, and iostat reports the disk is busy 95% of the time. You have spent a week tuning PHP-FPM, adding swap, and trimming cron jobs. Nothing helps. That is the moment you stop tuning the VPS and start planning the move to a dedicated server. This guide shows you how to measure the real signals, when to make the jump, and how to migrate without downtime.

Prerequisites

  • A Linux VPS running Ubuntu 24.04 LTS or Debian 12 with root or sudo access.
  • SSH access to the server and a non-root sudo user.
  • For the migration section: a backup of your data, or a snapshot if your provider offers it.
  • Basic familiarity with top, mpstat, and iostat. You will use these to diagnose your actual bottleneck.

Why the VPS Model Has a Hard Ceiling

A VPS is a slice of a physical machine. The hypervisor, usually KVM on modern infrastructure, divides the host's CPUs, RAM, and disk among many tenants. That is what makes a Linux VPS cheap: you share the hardware. As long as your neighbors behave, you get predictable performance. The problem starts when they do not, or when your own workload simply outgrows the slice.

Three shared-resource bottlenecks define the ceiling of a VPS: CPU steal, memory pressure, and disk I/O contention. Unlike a dedicated server, you cannot fix these by tuning your guest OS. You can only reduce your footprint, or move to hardware where you are the only tenant. Most people wait too long. By the time the site is slow during business hours, the migration is urgent, not planned.

Signal 1: CPU Steal Is Above 10 Percent

CPU steal is the percentage of time the hypervisor wants to run your vCPU but cannot because the physical CPU is busy running other tenants. A little steal, under 5 percent, is normal. Above 10 percent sustained, your VPS is effectively slower than its clock speed suggests, and no amount of tuning fixes it.

Check it with mpstat, from the sysstat package:

sudo apt install sysstat
mpstat -P ALL 5 3

The output shows a %steal column per CPU. Run this during your peak traffic window, not at 3 a.m. If %steal sits above 10 percent while your load is high, the host is oversubscribed and your performance is at the mercy of strangers.

On a dedicated server there is no steal column. The CPU is yours, period. If your workload is CPU-bound, this single metric often justifies the move on its own.

当 CPU 窃取率超过 10% 时,VPS 的性能已不由你控制。

When CPU steal exceeds 10 percent, your VPS performance is no longer under your control.

Signal 2: The Disk Is the Bottleneck, Not Your Code

NVMe drives on a VPS are fast, but they are still shared. A noisy neighbor running heavy database queries can push your disk latency from 0.5 ms to 20 ms. Your application feels it as slow queries, slow page loads, and stalled uploads.

Measure it while the server is under load:

sudo apt install sysstat
iostat -x 5 3

Look at the %util column. If it is near 100 percent and the await column shows more than 10 ms, the disk is saturated. On a VPS, this can be your workload, or it can be the neighbor's. The command cannot tell you which.

A dedicated server Vietnam gives you a full NVMe drive with no contention. If your growth plan involves a real database, PostgreSQL or MySQL with a few gigabytes of active data, the dedicated disk is the difference between a query returning in 50 ms and in 500 ms.

Signal 3: RAM Is Permanent Swap Fodder

Memory is the one resource a VPS does not share silently. You get exactly what you paid for. But when your workload needs more than the plan offers, you hit a wall. The fix on a VPS is a bigger plan, which usually means more vCPUs and disk you do not need, just to get the RAM.

Check if swap is actively used during normal operation:

free -h
vmstat 5 3

If the si and so columns (swap in and swap out) show sustained non-zero numbers, your working set exceeds physical RAM. For a database or a build server, this is fatal. For a web server, it means slow responses under traffic spikes.

Dedicated servers typically start at 32 GB or 64 GB of RAM. That is not a luxury, it is headroom. On a Windows VPS for RDP or a .NET workload, the same logic applies: 2 GB is never enough, and the jump to a dedicated box with 64 GB eliminates the entire class of memory problems.

Signal 4: Unpredictable Performance During Peak Hours

This is the symptom that combines all the others. Your site is fast at 6 a.m. and slow at 2 p.m. The code did not change. The traffic did not spike. The only variable is the other tenants on the host waking up. If you consistently see latency spikes at the same hours, map them to your monitoring and overlay them with steal and I/O data.

Run this during a suspected peak window to capture evidence:

sar -u 5 10
sar -d 5 10

sar records CPU and disk activity. If %steal and %util climb together exactly when the site slows, you have your answer. You are not being rate-limited by your provider. You are sharing hardware with someone whose workload is spiking at the same time as yours.

One useful comparison: benchmark your VPS, then look at what a dedicated box with the same vCPU count costs. The VPS vs dedicated server comparison walks through the cost math in detail. Often the dedicated server is only two to three times the price of the VPS, for five to ten times the sustained throughput.

When a VPS Is Still the Right Call

Do not overcorrect. A dedicated server is not automatically better. If your workload is intermittent, a VPS with snapshots and the ability to reinstall the OS in minutes is operationally superior. The flexibility of a rent Linux VPS model, where you can scale down, snapshot, and clone, beats raw hardware for development, staging, and low-traffic production.

Keep the VPS if:

  • Your CPU steal is under 5 percent and your load average is comfortably below your vCPU count.
  • Your peak RAM usage stays under 80 percent of the plan with swap idle.
  • Disk I/O waits are rare and the application is not database-heavy.
  • You want the operational convenience of snapshots and OS reinstall from a control panel.

Plenty of production WordPress sites, small e-commerce stores, and internal tools run perfectly on a 4 GB RAM VPS. The decision is not about prestige, it is about the measured signals above.

How to Migrate to a Dedicated Server Without Downtime

Once you have decided, the migration is a controlled process. The goal is to cut over with zero downtime, or a maintenance window measured in minutes, not hours.

The fastest path for a web application is a database dump plus a file sync:

# On the old VPS: dump the database
mysqldump -u root -p --single-transaction --routines --triggers appdb > appdb.sql

# Sync files to the new server (run from the new server)
rsync -avz --progress user@old-vps-ip:/var/www/ /var/www/

Then restore the database on the new server:

mysql -u root -p appdb < appdb.sql

Update your DNS records to point to the new server's IP. Most providers let you set a low TTL beforehand, 300 seconds, so the cutover propagates quickly. The sequence is: lower TTL, sync data, restore database, switch DNS, verify, then raise the TTL back.

For a zero-downtime migration with reverse proxy and a load balancer, the process is more involved but the pattern is the same: prepare the new server, sync data, test, and flip the proxy. The key is testing the new server in isolation before touching DNS. Login via SSH, run your application, and check the logs on the new box while the old one still serves traffic.

What to Look For in a Dedicated Server Provider

Not all dedicated servers are equal. The hardware matters, but the network and support matter more. When you compare providers, check these points:

CriteriaWhat to Check
Hardware generationLook for modern Xeon or EPYC CPUs, NVMe disks, and ECC RAM. Avoid older E5-2670 era boxes unless the price is severely discounted and the workload is light.
IP and rDNSYou need a dedicated IPv4 and the ability to set rDNS freely, especially if you send email. Free rDNS is a must, not a luxury.
Remote managementAn IPKVM or out-of-band console lets you fix a broken boot without a physical trip. Insist on it.
Bandwidth modelFor a server in Vietnam, domestic bandwidth at 100 Mbps on a 1 Gbps port is the norm. International bandwidth is a shared pool, about 4 to 10 Mbps, enough for backups and API calls but not for serving a global audience.
Support responsivenessHardware fails. The question is whether the provider swaps a dead disk in hours or days. Check for ticket support and a real SLA.

If your users are in Vietnam, locating the server inside the country matters. A Vietnam IPv4 matters for latency and local routing, and for compliance it can be decisive.

Troubleshooting the Migration

Two failures show up constantly in migrations to dedicated hardware. The first is a firewall rule on the new server blocking traffic. The second is a database character set mismatch.

Diagnose the first with:

# On the new server, check the firewall
sudo ufw status verbose
sudo nft list ruleset

If your old VPS used a simple ufw setup, replicate it exactly on the new box, including the SSH port. A common mistake is enabling the firewall before opening port 443, which locks out HTTPS traffic.

For the database, compare the output of SHOW VARIABLES LIKE 'character_set%'; on both servers. A mismatch between utf8mb4 on the old and latin1 on the new will produce mojibake. Dump and restore with explicit flags:

mysqldump --default-character-set=utf8mb4 -u root -p appdb > appdb.sql
mysql --default-character-set=utf8mb4 -u root -p appdb < appdb.sql

Always run your application logs and a full smoke test on the new server before switching DNS. The extra hour of testing saves a night of emergency debugging.

FAQ

How do I know if CPU steal is the reason my VPS is slow?

Run mpstat -P ALL 5 3 during peak hours. If the %steal column is above 10 percent while your load is high, the host is oversubscribed. This is the most reliable sign that shared hardware is the bottleneck, not your application.

Can I move from a VPS to a dedicated server without downtime?

Yes. The standard pattern is: lower DNS TTL, sync files with rsync, dump and restore the database, test the new server, then switch DNS. A reverse proxy in front of both servers allows a true zero-downtime cutover by flipping the proxy target.

Is a dedicated server always faster than a VPS?

No. For a light workload on a quiet host, a VPS can match a dedicated server. The dedicated advantage shows under sustained load, database I/O, and CPU-heavy work, where shared resource contention is eliminated.

What is a reasonable budget for a dedicated server in Vietnam?

Pricing varies by hardware generation and provider. A modern entry-level dedicated server with a recent Xeon, NVMe, and 32 GB RAM typically costs several times a mid-range VPS. Check the provider's pricing page, as prices change. You can compare VPS pricing to see where the break-even point sits for your workload.

Should I benchmark my VPS before deciding?

Yes. Run a disk benchmark with fio and a CPU benchmark with sysbench, then repeat on the dedicated server before migrating. This gives you a concrete comparison and verifies the new hardware meets expectations. See the full benchmarking guide with fio, sysbench, and iperf3.

Related articles

VPS 迁移至独立服务器的判断标准

当 CPU 窃取率持续高于 10%、磁盘利用率接近饱和、或内存长期依赖交换分区时,共享资源的 VPS 已经达到性能上限。先用 mpstat 和 iostat 测量这些指标,确认瓶颈后再考虑迁移。独立服务器提供独占的 CPU 和 NVMe 磁盘,适合数据库和 CPU 密集型业务。迁移时先同步文件、导出数据库,再切换 DNS,可做到零停机。若业务面向越南用户,选择位于越南机房的独立服务器能获得更低的本地延迟。

Note: This guide is for general reference. Every system and infrastructure has its own specifics, so test each step in a safe environment and consult a qualified engineer before applying it in production.