How to migrate from shared hosting to a KVM VPS without downtime

Shared hosting is fine until you need custom PHP extensions, long-running workers, or predictable CPU. Moving to a Proxmox VPS on Nexelya is straightforward if you treat migration as a small project instead of a Friday-night rsync.

1. Inventory what you are moving

Export a list of domains, databases, cron jobs, and email routing. Email often stays with Google Workspace or your existing provider—only move what benefits from the VPS (web app, API, workers).

2. Provision and harden the target

Order a plan that matches peak RAM, not idle usage. Install your stack (LEMP, Docker, or Node) and run through our security hardening baseline before copying production data.

3. Sync files and databases

Use rsync for file trees and native tools for databases:

# MySQL example
mysqldump -h oldhost -u user -p appdb | mysql -u user -p appdb

# Files
rsync -avz --delete user@oldhost:/var/www/app/ /var/www/app/

Run a final incremental sync minutes before cutover.

4. Lower DNS TTL early

Drop TTL to 300 seconds at least 24 hours before go-live. Point A/AAAA records to the new VPS IP from your Nexelya dashboard. Keep the old site online until TTL expires everywhere—use dig +trace from multiple networks to verify propagation.

5. Validate and roll back

Smoke-test checkout flows, webhooks, and background jobs. If something fails, revert DNS to the old host; because you kept TTL low, rollback is measured in minutes—not hours.

Common pitfalls

• Forgotten cron jobs — export crontabs explicitly.
• Hard-coded IPs in firewall rules or SaaS allowlists — update before cutover.
• Absolute paths in configs — grep for the old hostname.

Growing past a single VPS

When CPU steal, disk IOPS, or noisy neighbors disappear but you still hit limits, evaluate dedicated hardware for database-primary workloads.

View pricing to pick a starting tier, or register and provision in minutes from the client dashboard.