Disclosure: This guide contains affiliate links. If you sign up through them, First Bridge Consulting may earn a commission at no extra cost to you. We only recommend platforms we actually deploy on for client projects — the rankings here are not for sale.
Shared hosting is fine until it isn't. One day your site is slow under load, you hit a resource limit you can't raise, or you need a package the host won't install — and you realize you've outgrown the tier. Moving to a VPS gives you dedicated resources and root control, but it also makes you responsible for the server. This guide covers when to make the move and exactly how to do it without taking your site down.
TL;DR
- Move when you hit resource limits, need root/custom software, suffer "noisy neighbour" slowdowns, or need better security isolation.
- Don't move if you're not ready to own server patching and backups — consider managed hosting (a managed middle tier) instead.
- The migration is six steps: provision, set up the stack, copy data, test on a temp domain, lower DNS TTL, then cut over.
- Zero downtime comes from testing fully before you touch DNS, and lowering your DNS TTL a day ahead so the switch propagates fast.
Signs it's time to leave shared hosting
You don't need all of these — any one is a valid reason:
- Resource ceilings. CPU, RAM, inode, or process limits you can't raise, throttling your site at peak.
- Noisy neighbours. Performance swings because other accounts on the same machine are spiking.
- No root / no custom software. You need a specific runtime, extension, daemon, or config the host won't allow.
- Security isolation. You want your environment isolated from strangers' code on the same box.
- Outgrowing the control panel. You're fighting cPanel limits instead of using the server.
A reality check before you migrate
A VPS hands you root — and the responsibility that comes with it: OS patching, TLS renewal, backups, monitoring, and recovery when something breaks. If nobody on your side will own that, you have two better options:
- Managed hosting (a provider tunes and patches the server; you push code) — the middle tier between shared and self-managed VPS.
- A PaaS if your app fits it.
If you're ready to own the box, a VPS on DigitalOcean or Hetzner is the move — see our hosting guide for how the tiers compare, and DigitalOcean vs Hetzner to choose between the two.
The migration, step by step
1. Provision the VPS
Create the server (a DigitalOcean Droplet or Hetzner cloud server), choose a current LTS Linux, and do the baseline hardening: a non-root sudo user, SSH keys (disable password login), a firewall, and automatic security updates.
2. Build the stack
Install what your app needs — web server (Nginx or Caddy), runtime (PHP, Node, Python, etc.), and database (MySQL/MariaDB or Postgres). Match versions to your current host to avoid surprises. DigitalOcean's tutorials walk through nearly every common stack.
3. Copy the files and the database
- Files: transfer over
rsyncor SFTP. For a site, that's your web root and any uploads. - Database: export with
mysqldump(orpg_dump), copy the dump to the VPS, and import it. Update your app's database credentials and host in its config.
4. Test on a temporary address — before touching DNS
This is the step that prevents downtime. Point your local machine at the new server by adding a line to your hosts file (mapping your domain to the new IP), or use a temporary subdomain. Click through everything: pages, forms, logins, checkout, email. Fix issues now, while the live site is still happily serving from shared hosting.
5. Lower your DNS TTL a day ahead
The day before cutover, drop your domain's DNS TTL (e.g. to 300 seconds). This means when you change the record, the internet picks it up in minutes instead of hours.
6. Cut over and verify
Set up TLS on the VPS (Let's Encrypt via Certbot/Caddy), then update the DNS A record to the new IP. Because you lowered the TTL and already tested, propagation is fast and the experience is seamless. Watch logs and uptime for 24–48 hours, and keep the old shared account alive for a few days as a rollback path before cancelling.
Don't forget these
- Backups, on day one. Automate database and file backups before you need them.
- Monitoring. Uptime checks and basic resource alerts so you hear about problems before users do.
- Email. If your shared host handled email, plan where mail goes now — often a dedicated email provider rather than the VPS.
- Cron jobs. Re-create any scheduled tasks the old host ran.
FAQ
Will migrating to a VPS cause downtime? Not if you test on a temporary address first and lower your DNS TTL before cutover. The live site keeps serving from shared hosting until DNS points at the fully-tested VPS.
Is a VPS harder to manage than shared hosting? Yes — you own patching, backups, security, and recovery. If that's not for you, managed hosting gives you VPS-like performance while someone else runs the server.
How long does the migration take? For a typical site, the technical work is a few hours plus a day of lowered-TTL lead time. Complex apps with large databases or custom services take longer.
Should I keep my old shared hosting after migrating? Keep it for a few days to a week as a rollback option and to confirm nothing was missed, then cancel.
Planning a migration and want it done with zero downtime? Tell us about your current setup — we migrate sites and apps to VPS and cloud for a living.