To move from shared hosting to a VPS, you need to take a complete backup, set up and configure your new server, transfer all files and databases, and then point your DNS to the VPS — all before canceling your old plan.
The good news: you don't have to cut service while migrating. With the right sequence you can make the switch with near-zero downtime. This guide walks you through every step.
Why Move from Shared Hosting to a VPS?
Shared hosting places your site on a server alongside hundreds of other accounts. When one of those neighbors consumes too many resources, your site pays the price. As your project grows, those constraints become a real ceiling.
A VPS (Virtual Private Server) gives you dedicated resources — CPU, RAM, and disk — that only you use. You also gain full control over the environment: install any software, tweak PHP settings, manage your own firewall, and scale resources on demand.
Clear signals that it's time to migrate:
- Your hosting panel shows CPU or RAM usage consistently at the limit.
- Your provider sends overuse warnings.
- Pages load slowly during peak hours even though content hasn't changed.
- You need software extensions or versions that shared hosting won't allow.
- You handle sensitive data and need true isolation from other users.
If you identify three or more of those points, the migration is worth it. Browse more articles about VPS servers to compare options before deciding.
Phase 1 — Prepare and Back Up Your Current Environment
Before touching the new server, secure everything on your shared hosting. A broken backup discovered after migration is the worst possible scenario.
What to back up
- Site files: download the entire
public_html(or the domain's root folder) via FTP/SFTP or the panel's file manager. - Databases: export each database as a
.sqlfile from phpMyAdmin or usingmysqldumpif you have SSH access. - Email: if you host mail on the same plan, export mailboxes before migrating.
- SSL certificates: note whether you use Let's Encrypt or a paid certificate; you'll need to reinstall it on the VPS.
- Custom configurations: save your
.htaccess, any customphp.inidirectives, and environment variables.
Document your current stack
Note the PHP version your site uses, the database engine (MySQL/MariaDB) and its version, and any active PHP extensions. You'll need to match that environment on the VPS for the application to behave the same way.
Phase 2 — Provision and Configure the VPS
With backups ready, it's time to provision the new server. This is where most beginners get stuck — the VPS arrives "blank," without the familiar cPanel interface.
Choose the right size
| Site type | Recommended RAM | Storage |
|---|---|---|
| Blog or informational site (WordPress) | 1–2 GB | 20–40 GB SSD |
| Small online store (<500 products) | 2–4 GB | 40–80 GB SSD |
| Multi-site platform | 4–8 GB | 80–160 GB SSD |
| High-traffic application | 8 GB or more | NVMe 100 GB+ |
Minimum stack to install
Connect to the VPS via SSH and run system updates. Then install the stack your site needs. For most PHP sites it's the classic LAMP stack:
# Ubuntu/Debian
sudo apt update && sudo apt upgrade -y
sudo apt install apache2 mariadb-server php php-mysql php-curl php-gd php-mbstring -y
# CentOS/AlmaLinux
sudo dnf update -y
sudo dnf install httpd mariadb-server php php-mysqlnd php-curl -y
Configure the firewall to open only the necessary ports (22 for SSH, 80 for HTTP, 443 for HTTPS) and disable direct root SSH login by using key-based authentication instead of passwords.
Phase 3 — Transfer Files and Databases
This is the phase with the highest risk of error if done without a clear order. Follow the sequence and verify each step before moving on.
Transfer files
The fastest method from Linux/macOS is rsync directly between machines:
rsync -avz -e ssh /local/path/public_html/ user@VPS_IP:/var/www/html/
If you only have FTP access to the shared hosting, upload the files to the VPS using scp or FileZilla pointed at the new server.
Restore databases
- Create the user and database in the VPS's MariaDB instance.
- Import the SQL dump:
mysql -u user -p db_name < backup.sql - Update your application's configuration file (
wp-config.php,.env, etc.) with the new credentials.
Install the SSL certificate
With Certbot, getting a free Let's Encrypt certificate takes a single command:
sudo certbot --apache -d yourdomain.com -d www.yourdomain.com
Verify that automatic renewal is active with sudo certbot renew --dry-run.
Phase 4 — Test Before Changing DNS
Here's the trick to migrating without downtime: test the site on the VPS before changing DNS. Use your computer's hosts file to point the domain to the VPS IP locally.
On Linux/macOS, edit /etc/hosts; on Windows, C:\Windows\System32\drivers\etc\hosts:
203.0.113.10 yourdomain.com www.yourdomain.com
With that line active, your browser will go to the VPS even though public DNS still points to shared hosting. Test:
- The homepage loads correctly.
- Contact forms or shopping carts work end to end.
- Admin login works and data is intact.
- The SSL certificate shows a green padlock.
- Outbound emails send successfully (if applicable).
Only proceed when everything checks out.
Phase 5 — Switch DNS and Cancel Old Hosting
Once the site on the VPS passes all your local tests, it's time for the official cutover.
Update DNS records
In your domain registrar's panel (Namecheap, GoDaddy, etc.), update the A record for the root domain and the www subdomain to point to the VPS's public IP. Lower the TTL to 300 seconds a few hours before the switch for faster propagation.
DNS propagation can take anywhere from 15 minutes to 48 hours depending on the previous TTL. During that window, keep the shared hosting active and unchanged: some visitors will still reach it while the rest of the world updates its cache.
Confirm propagation
Use tools like dig yourdomain.com +short or whatsmydns.net to see from which regions the domain already resolves to the new IP.
Cancel shared hosting
Wait at least 72 hours after the DNS change before canceling. If you host email on the same shared plan, migrate it first (Google Workspace, Zoho Mail, or configure Postfix on the VPS). Once you confirm traffic is flowing 100% through the VPS, you can safely drop the shared plan.
Key Takeaways
- Always back up files, databases, and configurations before any move.
- Match the VPS stack (PHP version, extensions, database engine) to the original hosting environment.
- Test the site on the VPS using the local
hostsfile before touching DNS. - Lower DNS TTL hours before the cutover to speed up propagation.
- Keep shared hosting active for at least 72 hours after the DNS change.
- Set up a firewall, SSH key authentication, and SSL from day one.
Ready to make the move but not sure where to start with server configuration? The team at elenlace.com can handle the complete migration for you, from the initial backup to post-cutover verification.
FAQ
How long does it take to migrate from shared hosting to a VPS?
A small site can be migrated in 2–4 hours of active work. The total elapsed time may be 24–48 hours while DNS propagates, but the site never goes down if you follow the correct sequence.
Can I migrate without knowing Linux?
Yes, though there's a learning curve. You can install a control panel like cPanel or Plesk on the VPS to get a graphical interface similar to shared hosting. The alternative is to hire a managed migration service.
Does the DNS change affect email?
It can if your email depends on MX records hosted on the shared hosting account. Before changing DNS, document your current MX records and make sure they point to the correct mail provider (Google Workspace, Zoho, etc.) independently of the web server.
What if something breaks after the DNS switch?
Don't panic — the shared hosting stays active during the 72-hour window. If you detect a critical issue, revert the A record in DNS back to the shared hosting IP and you're back to normal while you fix the VPS. This is exactly why keeping the backup active is non-negotiable.
Prefer it done for you? El Enlace handles hosting and professional web development.
Useful resources
Other providers and guides worth comparing: