Migrating from shared hosting to cloud hosting means moving your files, database, and configuration to a scalable virtual server environment with more control and better performance. For a typical website, the whole process takes 2 to 6 hours and — done in the right order — your visitors will never notice the difference.
This guide walks through every step: initial backup, server setup, file transfer, DNS cutover, and final validation.
Why It's Worth Moving to the Cloud
Shared hosting puts your site in competition for the same CPU and RAM as dozens or hundreds of other sites on the same machine. When one of them spikes, everyone suffers. Cloud hosting eliminates that problem: each instance gets guaranteed resources, and you can scale in minutes.
Other concrete benefits:
- 99.9%+ SLA — redundant infrastructure with automatic failover.
- Full root or control panel access — install the exact PHP, MySQL, or Node.js version your project needs.
- Independent backups — you're not dependent on your provider's backup policies.
- Horizontal and vertical scaling — add RAM or CPU cores without changing servers.
If your site gets more than 500 daily visitors, runs an online store, or simply loads slowly during peak hours, you've already outgrown shared hosting.
Step 1 — Take a Complete Backup Before Touching Anything
Rule number one: never move data without a verified copy. A broken backup is the same as no backup.
File Backup
From your current hosting's cPanel (or via FTP/SFTP), download a complete copy of your site's root directory. Include every subdirectory: wp-content, uploads, and configuration files like .htaccess and wp-config.php.
If your hosting offers a "Full Backup" option in cPanel, use it — it generates a .tar.gz file containing everything, including the database.
Database Backup
Log into phpMyAdmin, select your database, and export it in SQL format. Make sure the "Structure and data" option is checked. Verify the resulting file is not empty and that the last lines contain INSERT statements.
Save Credentials
Note down in a safe place: database username and password, database name, and SMTP credentials if you send email from the site.
Step 2 — Configure Your New Cloud Server
With your backup ready, create the cloud instance. Most providers let you have a live server running in under 5 minutes from the control panel.
Choose the Right Plan
| Site type | Recommended RAM | Storage |
|---|---|---|
| Blog or informational site | 1–2 GB | 20–40 GB SSD |
| Small WooCommerce store | 2–4 GB | 40–80 GB SSD |
| Marketplace or SaaS | 4–8 GB | 80 GB+ SSD |
Install the LAMP or LEMP Stack
On a freshly created Ubuntu or AlmaLinux server, install Apache (or Nginx), PHP in the version your site uses, and MySQL/MariaDB. Many providers also offer pre-configured images with WordPress or cPanel that speed up this step significantly.
Create the Database and User
On your new server, create a database with the same name it had on shared hosting. Create a user with the necessary permissions (SELECT, INSERT, UPDATE, DELETE, CREATE, DROP on that database). Import the SQL file you exported in step 1 with mysql -u user -p db_name < backup.sql.
Step 3 — Transfer Files and Update Configuration
Upload your site files to the new server using SCP, SFTP, or rsync. For WordPress sites, the target directory is typically /var/www/html/ or whichever path you defined in the Apache VirtualHost.
Update wp-config.php (or Your CMS Config File)
Edit your CMS configuration file to point to the new database:
DB_HOST→localhost(if MySQL runs on the same server)DB_NAME→ your new database nameDB_USER→ the user you createdDB_PASSWORD→ that user's password
Check File Permissions
Site files should belong to the web server user (typically www-data on Ubuntu or apache on CentOS/AlmaLinux). Directories need 755 permissions and files 644. Upload directories (wp-content/uploads) must be writable by the web server process.
Configure VirtualHost and SSL
Create or adjust the VirtualHost block in Apache/Nginx to point to the correct directory and domain name. Install a free SSL certificate with Let's Encrypt using Certbot. This ensures your site runs on HTTPS from the first day on the new server.
If you want technical support during this process, the team at elenlace.com can configure the cloud environment for you and make sure everything is working correctly before the DNS cutover.
Step 4 — Test with the Hosts File Before Changing DNS
Before moving DNS records, test that the site works correctly on the new server without affecting your current visitors.
Add a temporary line to your computer's hosts file:
NEW_CLOUD_IP yourdomain.com www.yourdomain.comOn Windows it's at C:\Windows\System32\drivers\etc\hosts; on Mac/Linux at /etc/hosts. Save the file and open your domain in the browser — your machine will resolve to the new IP while the rest of the world still sees the old server.
Check:
- The site loads without 500 errors or database errors.
- Images and static resources display correctly.
- The admin panel (if applicable) works.
- Contact or payment forms respond as expected.
- The SSL certificate shows a green padlock.
Once everything is validated, remove those lines from your hosts file.
Step 5 — Execute the DNS Cutover
The DNS cutover is the moment the world starts seeing your site on the new server. To minimize the window where both servers receive traffic, reduce the TTL of your DNS records to 300 seconds (5 minutes) at least 24 hours in advance.
When you're ready:
- Log into the panel where you manage your DNS (your domain registrar or Cloudflare).
- Change the A record for
@andwwwto the new cloud server IP. - Save the changes.
- Wait for propagation (between 5 minutes and 2 hours with a low TTL).
You can verify global propagation with dig yourdomain.com +short or an online DNS propagation checker.
Keep the Old Server Live for 48 Hours
Don't cancel your shared hosting immediately. Some DNS providers cache records longer than the configured TTL. Keep both servers active for at least 48 hours after the cutover to catch any straggling visitors.
Key Takeaways
- A complete, verified backup is the mandatory first step — before any server action.
- Fully configure the cloud server (stack, database, SSL) before touching DNS.
- Testing with the
hostsfile lets you validate in production without risking live visitors. - Lowering the TTL 24 hours before the cutover speeds up DNS propagation and shortens the uncertainty window.
- Keep the old server running for at least 48 hours after the DNS change.
- Moving to cloud eliminates noisy neighbors from shared hosting and gives you full control over your environment.
Ready to make the move? The team at elenlace.com handles complete cloud hosting migrations for businesses in Mexico — zero downtime, guaranteed. Browse more technical guides in our cloud hosting section.
FAQ
How long does a shared-to-cloud hosting migration take?
For a standard WordPress site with less than 5 GB of data, the technical process takes 2 to 4 hours. DNS propagation can add between 30 minutes and 2 additional hours if you lowered the TTL in advance.
Will I lose data during the migration?
No, if you follow the process correctly. The key is taking a full backup right before the migration, validating the new server with the hosts file, and only cutting over DNS when everything is confirmed.
Do I need advanced technical skills to migrate?
Basic command-line knowledge and access to control panels are enough for most steps. If you use a CMS like WordPress, migration plugins (Duplicator, All-in-One WP Migration) simplify the file and database transfer considerably.
What if something breaks after the DNS switch?
If you spot serious issues after the cutover, you can revert the DNS record to the old IP while you fix the problem on the new server. That's exactly why it's essential to keep shared hosting active for at least 48 hours after the DNS change.
Useful resources
Other providers and guides worth comparing:
