Migrating from shared hosting to cloud means copying all your site's files and databases to your own cloud server, redirecting DNS, and verifying everything works before shutting down the old hosting. The typical process takes two to four hours of work, with zero or minimal downtime when done carefully.
If your site is slow to load, crashes during peak hours, or the shared hosting resources are no longer enough, it's time to migrate. This guide takes you from one environment to the other without losing data or visitors.
When Does It Make Sense to Move to Cloud Hosting?
Not every site needs a cloud server right away. These are clear signs that the time has come:
- Load times above 3 seconds during peak hours, caused by shared CPU limits.
- 503 errors or "Too many connections" from the database.
- The shared host suspends your site for exceeding process limits.
- You need to install PHP extensions the provider doesn't allow.
- Growing traffic projected to exceed your shared plan's limits in the coming months.
On the other hand, if your site gets fewer than 5,000 monthly visits and has no traffic spikes, shared hosting may still be sufficient. Migration comes with added costs and responsibilities worth evaluating first.
Step 1 — Set Up the Cloud Server Environment
Before touching the current site, spin up and configure the destination cloud server. This minimizes the time your site is in transition.
Choose a provider and create the server
Select a Linux distribution (Ubuntu 22.04 LTS is most recommended). Choose a resource plan based on your current traffic: for most WordPress sites with up to 50,000 monthly visits, 2 vCPU and 4 GB of RAM is a solid starting point.
| Monthly Traffic | Recommended RAM | Recommended vCPU |
|---|---|---|
| Up to 10,000 visits | 1–2 GB | 1 |
| 10,000–50,000 visits | 2–4 GB | 2 |
| 50,000–200,000 visits | 4–8 GB | 4 |
| 200,000+ visits | 8+ GB | 4–8 |
Install the software stack
Install Apache (or Nginx), PHP in the same version currently used on the shared host, and MariaDB. If the site runs WordPress, also install the required PHP extensions: php-mysql php-curl php-gd php-mbstring php-xml php-zip.
Step 2 — Create a Complete Backup of the Current Site
Never migrate without a verified backup. An incomplete backup is almost as dangerous as having none at all.
Site files
From your shared hosting panel (cPanel, Plesk, etc.) download a full backup, or compress the site's root folder via SSH:
tar -czf backup_site_$(date +%Y%m%d).tar.gz /home/youruser/public_html/
Database
mysqldump -u your_user -p database_name > backup_db_$(date +%Y%m%d).sql
Download both files to your local computer before making any changes. Verify the .sql file is not empty and that the .tar.gz can be extracted without errors.
Step 3 — Transfer Files and Restore the Database
Upload files to the cloud server
Use scp or rsync to transfer files directly between servers (faster than routing through your computer):
rsync -avz -e "ssh" /path/to/backup/ user@cloud-ip:/var/www/html/my-site/
Alternatively, upload the compressed file with scp and extract it on the cloud server:
scp backup_site.tar.gz user@cloud-ip:/tmp/
# On the cloud server:
tar -xzf /tmp/backup_site.tar.gz -C /var/www/html/my-site/
Import the database
On the cloud server, create the database and user first, then import:
mysql -u root -p database_name
Update the site configuration
If you use WordPress, edit wp-config.php with the new database credentials on the cloud server. For other CMS platforms, find the equivalent config file (config.php, .env, etc.).
Step 4 — Test the Site Before Changing DNS
This step prevents exposing a broken site to your visitors. Temporarily add the domain to your local /etc/hosts file (on your computer) pointing to the new cloud server's IP:
123.45.67.89 mysite.com www.mysite.com
Open a browser and verify:
- The homepage loads correctly.
- Images and styles look right.
- The contact form works.
- The admin login (if applicable) responds.
- SSL certificates are configured.
If anything fails, fix it on the cloud server before touching DNS. The old site remains live for visitors in the meantime.
Step 5 — Change DNS and Monitor Propagation
Once the cloud server site is verified and working correctly, update the A records in your domain registrar's panel:
mysite.com A 123.45.67.89
www.mysite.com A 123.45.67.89
Lower the TTL to 300 seconds (5 minutes) at least one hour before making the change. This speeds up DNS propagation — typically between 15 minutes and 2 hours in most regions.
Monitor the change with tools like dig mysite.com or whatsmydns.net. Once most nodes worldwide resolve to the new IP, the old site can remain active a few more days as a fallback before canceling it.
Want a specialist team to handle the migration for you with no risk of downtime? elenlace.com offers assisted migrations to cloud hosting with full verification included.
Key Takeaways
- Set up the destination cloud server before touching the current site — this reduces transition time.
- A verified backup (files + database) is the single most important step in the entire migration.
- Test the site by pointing the domain in your local
/etc/hostsbefore changing public DNS. - Lower the DNS TTL hours before the switch to speed up propagation.
- Keep the shared hosting active for at least 48 hours after the DNS change as a safety net.
A well-planned migration doesn't interrupt service and can be completed in an afternoon. If you'd rather delegate the process, the team at elenlace.com manages migrations from start to finish. For more cloud hosting resources, visit our cloud blog.
FAQ
How long does a shared hosting to cloud migration take?
Configuration and transfer work takes between 2 and 4 hours for a typical site. DNS propagation can take between 15 minutes and 48 hours, but the site remains accessible throughout because the old hosting stays active.
Will I lose visitors or SEO rankings when I migrate?
No, as long as you keep the exact same URLs and content. Google and other search engines re-crawl the site at the new IP without penalizing rankings. Make sure to keep the same slugs, titles, and folder structure.
Do I need to cancel the shared hosting immediately after migrating?
No. Keep the shared hosting active for at least 48–72 hours after the DNS change. If something goes wrong during propagation, you can quickly revert DNS without having lost the old environment.
What happens to my shared hosting email when I migrate the domain?
Email and web hosting are independent DNS services (MX records vs. A records). If your email is on the same shared host, you need to migrate it separately or ensure MX records don't change during the web migration. Consider keeping email on Google Workspace or Zoho to simplify future migrations.
Useful resources
Other providers and guides worth comparing: