How to Move from Shared Hosting to a VPS Without Downtime (2026 Step-by-Step Guide)

1. First, Do You Actually Need a VPS?

Shared hosting is fine until it isn't. A VPS stops being optional the moment your site starts losing money to the limits of a shared plan. These are the signals that you have outgrown shared hosting:

• Your site slows down unpredictably. On shared hosting, CPU, RAM, and disk I/O are shared with hundreds of other accounts. When a "noisy neighbour" spikes, your pages slow down — and you cannot do anything about it.
• You hit hidden resource limits ("entry processes", "CPU seconds", "concurrent connections"). Hosts throttle or suspend accounts that exceed them, often during your busiest hour.
• You need software the host will not install — a specific PHP extension, Redis, Node.js, Docker, Elasticsearch, or a custom cron job.
• Your traffic is growing and the bill is scaling badly. You pay more for a bigger shared tier that still shares resources.
• You need real security control. On shared hosting, one compromised account on the same server can put your data at risk. A VPS isolates you.

2. What "No Downtime" Actually Means

Before the steps, get the mental model right. There are two kinds of downtime, and only one of them is real:

• Real downtime is when the site returns errors or cannot be reached. Your goal is to keep this at zero.
• Perceived downtime is when DNS resolves to the old server for some users while others already hit the new one. This is normal, brief, and invisible if you prepare for it.

The trick that makes this possible is DNS TTL (time to live) — how long resolvers cache your domain's IP address. If your TTL is the default 3,600 seconds (1 hour), some visitors keep hitting the old server for up to an hour after you change the IP. Lower the TTL to 300 seconds before you switch, and the change propagates in minutes instead. That single preparation step is what separates a smooth migration from a stressful one.

3. The Pre-Migration Checklist

Do not skip this. Most "failed" migrations fail here, not at the server.

Figure 3 — Only the web A records move. Your mail, SPF, DKIM and DMARC records stay exactly where they are.

4. The Zero-Downtime Migration, Step by Step

The commands below assume Ubuntu 24.04 and a typical PHP site (WordPress, WooCommerce, Laravel, or similar). Adapt package names for other distributions.

Step 1 — Provision and secure the new VPS

# Create a non-root user with sudo
adduser deploy
usermod -aG sudo deploy

# Copy your SSH key so you can log in without a password
ssh-copy-id deploy@203.0.113.10

# Disable password login (only after you confirm key login works)
sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl restart ssh

# Turn on the firewall
sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable

Step 2 — Install your web stack

sudo apt update && sudo apt upgrade -y
sudo apt install -y nginx mariadb-server php-fpm php-mysql \
  php-curl php-xml php-mbstring php-zip unzip \
  certbot python3-certbot-nginx
sudo systemctl enable --now nginx mariadb
sudo mysql_secure_installation

Step 3 — Copy your files with rsync

rsync is resumable and only transfers what changed — exactly what you need for the second, final sync later.

rsync -avz --delete -e ssh ~/public_html/ deploy@203.0.113.10:/var/www/example.com/

# Set correct ownership and permissions
sudo chown -R www-data:www-data /var/www/example.com
sudo find /var/www/example.com -type d -exec chmod 755 {} \;
sudo find /var/www/example.com -type f -exec chmod 644 {} \;

Step 4 — Export and import your databases

# On the OLD host — --single-transaction gives a consistent dump without locking the site
mysqldump -u dbuser -p --single-transaction --routines --triggers \
  --default-character-set=utf8mb4 example_db | gzip > example_db.sql.gz

# Transfer it
scp example_db.sql.gz deploy@203.0.113.10:/tmp/

# On the NEW server — create the database and user, then import
sudo mysql -e "CREATE DATABASE example_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
sudo mysql -e "CREATE USER 'dbuser'@'localhost' IDENTIFIED BY 'a-strong-password'; \
  GRANT ALL PRIVILEGES ON example_db.* TO 'dbuser'@'localhost'; FLUSH PRIVILEGES;"
gunzip 

Match the character set (utf8mb4) to avoid mangled emoji and non-Latin characters, then update your application's database credentials (wp-config.php for WordPress).

Step 5 — Configure the site and issue SSL

server {
    listen 80;
    server_name example.com www.example.com;
    root /var/www/example.com;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
}

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

# Issue a free TLS certificate
sudo certbot --nginx -d example.com -d www.example.com

Step 6 — Test everything before DNS changes

This step is what guarantees zero downtime. Point your own computer at the new server without touching public DNS:

# macOS/Linux: /etc/hosts  ·  Windows: C:\Windows\System32\drivers\etc\hosts
sudo nano /etc/hosts

# Add this line:
203.0.113.10   example.com   www.example.com

Now browse the site as a visitor would: homepage, several deep pages, search, login, contact forms, and — if you run a store — add to cart and a test checkout. Test on a phone over mobile data too (and remove the hosts entry when done).

Step 7 — Lower TTL, do the final sync, then cut over DNS

1. Final file sync — run the same rsync command again; only changes transfer.
2. Final database sync — take one more dump and import it, so orders, comments, and posts made during your work are not lost.
3. Switch the A record — point example.com (and www) to the new server's IP. Leave MX and other records untouched.
4. Verify propagation with dig +short example.com and a global tool such as whatsmydns.net.

Step 8 — Verify, monitor, and keep your rollback

# Watch the web server error log after cutover
sudo tail -f /var/log/nginx/error.log

# Confirm certificate auto-renewal works
sudo certbot renew --dry-run

Confirm HTTPS loads with a valid certificate, http redirects to https, no 404s on your most important URLs, and scheduled tasks run. Then restore your DNS TTL to a normal value (e.g. 3,600 seconds) and keep the old host live for one to two weeks. If anything goes wrong, your rollback is simply pointing the A record back.

5. How Long Does the Migration Take?

6. Five Mistakes That Cause Downtime (and How to Avoid Them)

1. Switching DNS before lowering TTL. The most common cause of a slow, messy cutover. Lower TTL first — always.
2. Forgetting the final database sync. Anything created between your first copy and cutover (orders, comments, form entries) is lost. Always re-sync right before switching.
3. PHP or MySQL version mismatch. A plugin that ran on PHP 8.1 can fatal-error on PHP 8.4. Match versions first, upgrade later.
4. Ignoring email and DNS side records. Changing the wrong record breaks mail. Only move the web A record; leave MX, SPF, DKIM, and DMARC alone.
5. Cancelling the old host too early. Your rollback disappears with it. Keep it for one to two weeks.

7. Choosing a VPS for the Move

Size for where your site is going, not where it is now — you do not want to migrate twice.

Route choice matters as much as size. If your visitors are in mainland China, a CN2 GIA route (available on LuckVM's Hong Kong and US Los Angeles nodes) gives far lower latency and packet loss than standard international BGP. If your audience is in Southeast Asia, a Singapore node is the better centre of gravity.

Figure 7 — LuckVM regional plans by monthly price, September 2026.

8. LuckVM's Migration Assistance

If you would rather not run the commands yourself, LuckVM's team supports multiple migration paths:

• API-driven migration for cloud-to-cloud transfers
• Direct upload of VM images (QCOW2, VMDK, VHD)
• Physical-to-virtual (P2V) conversion
• Live migration with minimal downtime using replication tools

Migration assessment and planning are available for enterprise customers, and the team can assist with database migrations, application replatforming, and DNS cutover strategies. Combined with 24/7/365 ticket support in English and Chinese, this is the fastest way to move without risking your live site.

9. Frequently Asked Questions