Migration · 2025

How to Migrate from Shared Hosting to Cloud Hosting (Step-by-Step)

Updated April 2025 · 10 min read

Move your WordPress site or web app from cPanel shared hosting to managed cloud in under 4 hours.

HomeBlog › How to Migrate from Shared Hosting to Cloud Hosting (Step-by-Step)

How to Migrate from Shared Hosting to Cloud Hosting (Step-by-Step 2025)

Migrating your website from shared hosting to cloud-based managed hosting sounds intimidating. In practice, for the vast majority of websites, it's a 2–4 hour process with under 5 minutes of actual downtime.

This guide covers the complete migration for three scenarios: migrating a WordPress site, migrating a Node.js/Python/PHP app, and migrating a static site — each from cPanel-based shared hosting to a container-based platform.

Before You Start: Migration Checklist

Complete this before touching any DNS:

  • [ ] Access to your current hosting cPanel / control panel
  • [ ] FTP/SFTP credentials for current host
  • [ ] Access to your domain registrar (GoDaddy, Namecheap, etc.)
  • [ ] Current site fully backed up (files + database)
  • [ ] List of all environment variables / database credentials on current host
  • [ ] New hosting provisioned and tested with staging domain

Do not start migration until your new hosting is fully configured and tested on the staging subdomain.

Part 1: Migrating a WordPress Site

Step 1: Export Your Current WordPress Site

Option A: Using a Migration Plugin (Easiest)

Install All-in-One WP Migration on your current WordPress site:
1. WordPress admin → Plugins → Add New → search "All-in-One WP Migration" → Install → Activate
2. All-in-One WP Migration → Export → Export To → File
3. Download the .wpress file (includes database + files + themes + plugins)

Option B: Manual Export (More Control)

Database export via phpMyAdmin:
1. cPanel → phpMyAdmin → select your WordPress database
2. Export tab → Quick method → Format: SQL → Go
3. Save the .sql file

Files export via SFTP:

# From your local machine
sftp username@oldhost.com
lcd ~/migration-backup
get -r /public_html/your-site ./

Or via cPanel → File Manager → compress public_html/your-site → download the archive.

The critical directories to preserve:
- wp-content/uploads/ — your media files
- wp-content/themes/your-theme/ — your custom theme
- wp-content/plugins/ — all plugins (can be reinstalled but this is faster)
- wp-config.php — contains your old database credentials (you'll need to reference these)

Step 2: Set Up WordPress on ApexWeave

Your new WordPress hosting provisions with a fresh WordPress installation. You'll see it at yoursite.apexweaveapp.com.

Configure via CLI:

# Set PHP version
apexweave env:set yoursite.apexweaveapp.com APEXWEAVE_STACK=php:8.3

# Set email delivery (optional but recommended)
apexweave env:set yoursite.apexweaveapp.com SMTP_HOST=smtp.mailgun.org
apexweave env:set yoursite.apexweaveapp.com SMTP_USERNAME=postmaster@mg.yourdomain.com
apexweave env:set yoursite.apexweaveapp.com SMTP_PASSWORD=your-mailgun-key

Step 3: Import Your Site to the New Host

Option A: Using All-in-One WP Migration on new host:
1. Install All-in-One WP Migration on the new WordPress installation
2. All-in-One WP Migration → Import → drag your .wpress file
3. Wait for import to complete (may take 5–30 minutes depending on site size)
4. Update your admin password if the old password is unknown

Option B: Manual Import:

Import database via phpMyAdmin on the new host:
1. Access phpMyAdmin through your ApexWeave dashboard or:
bash apexweave bash yoursite.apexweaveapp.com mysql -u $DB_USER -p$DB_PASSWORD $DB_NAME < /tmp/backup.sql

Transfer files via SFTP or git:

# Upload files to new host via SFTP
sftp username@new-host.com
put -r ./wp-content/uploads/* /var/www/html/wp-content/uploads/
put -r ./wp-content/themes/your-theme/* /var/www/html/wp-content/themes/your-theme/

Update wp-config.php on the new host with the new database credentials:

apexweave bash yoursite.apexweaveapp.com
nano /var/www/html/wp-config.php
# Update: DB_NAME, DB_USER, DB_PASSWORD, DB_HOST

Step 4: Fix URLs in the Database

WordPress stores your domain URL in the database. After migration, run a search-replace:

apexweave run "wp search-replace 'https://yoursite.apexweaveapp.com' 'https://yourdomain.com'" yoursite.apexweaveapp.com

Or if you've been testing on the staging subdomain:

apexweave run "wp search-replace 'http://oldhost.com/yoursite' 'https://yourdomain.com'" yoursite.apexweaveapp.com

Step 5: Test on Staging Domain

Before changing DNS, verify everything works on the staging domain:
- Home page loads
- All images display
- Forms work
- Admin login works at yoursite.apexweaveapp.com/wp-admin
- WooCommerce products load (if applicable)
- All page links work (no broken internal links)

# Test key pages
curl -sI https://yoursite.apexweaveapp.com/
curl -sI https://yoursite.apexweaveapp.com/shop/
curl -sI https://yoursite.apexweaveapp.com/contact/

Step 6: Reduce DNS TTL (24–72 Hours Before Migration)

At your domain registrar:
- Current A record TTL: probably 3600 (1 hour) or 86400 (24 hours)
- Change to: 300 (5 minutes)

Wait the current TTL duration for the change to propagate. Now DNS changes will propagate in 5 minutes instead of hours.

Step 7: Switch DNS

# Set your custom domain on ApexWeave
apexweave domain:set yoursite.apexweaveapp.com yourdomain.com

At your domain registrar, change the A record:
- Old value: your current host's IP
- New value: your ApexWeave server IP (shown in dashboard)

SSL provisions automatically within minutes of DNS propagation.

Step 8: Verify and Monitor

# Check the site is live on your domain
curl -sI https://yourdomain.com

# Check SSL
echo | openssl s_client -connect yourdomain.com:443 2>/dev/null | grep subject

# Monitor logs
apexweave logs yoursite.com --follow

Total downtime: 0–5 minutes (only during DNS TTL window).

Part 2: Migrating a Node.js / Python / PHP App

The process for custom apps is simpler than WordPress because there's no database search-replace step.

Step 1: Prepare Your App

If your app isn't in git, initialize it:

cd your-app
git init
echo "node_modules/" >> .gitignore
echo ".env" >> .gitignore
git add .
git commit -m "Migration commit"

Step 2: Document Your Environment Variables

On your current host (cPanel → PHP Settings, or wherever your env vars are set), note every environment variable:
- Database credentials
- API keys
- App configuration values

Step 3: Provision and Configure New App

# Add ApexWeave as remote
git remote add apexweave https://git.apexweaveapp.com/username/your-app.git

# Set runtime
apexweave env:set your-app.apexweaveapp.com APEXWEAVE_STACK=node:22  # or python:3.12, php:8.3

# Set all environment variables
apexweave env:set your-app.apexweaveapp.com DATABASE_URL=postgres://...
apexweave env:set your-app.apexweaveapp.com API_KEY=xxx
# ... all other variables

Step 4: Deploy and Test

git push apexweave main
apexweave deploy your-app.apexweaveapp.com --follow

Test on staging subdomain. Verify all functionality works.

Step 5: Migrate Database (If Needed)

# Export from old host
# (via phpMyAdmin, pgAdmin, or command line on old server)
pg_dump -h old-host -U user database > backup.sql
# Or:
mysqldump -h old-host -u user -p database > backup.sql

# Import to new host
apexweave db:import mydb.apexweaveapp.com --file backup.sql

Step 6: Switch DNS

Same as WordPress migration (Steps 6–8 above).

Part 3: Migrating a Static Site

Simplest migration:

# Your static files (HTML, CSS, JS, images)
git init your-static-site
cd your-static-site

# If you have a build step (Gatsby, Hugo, etc.):
# Commit the source, configure build command

# Or commit the built files directly:
# Copy your built site to the repo
git add .
git commit -m "Static site migration"

git remote add apexweave https://git.apexweaveapp.com/username/static-site.git
git push apexweave main

Select Static Site as app type. No database, no environment variables needed for a pure static site.

Common Migration Issues and Fixes

Images broken after WordPress migration

Cause: WordPress stores absolute URLs for media. URLs in the database reference the old host's domain.

Fix:

apexweave run "wp search-replace 'http://oldhost.com' 'https://yourdomain.com' --all-tables" yoursite.com
apexweave run "wp cache flush" yoursite.com

500 errors after migration

Cause: Missing environment variable, wrong database credentials, or PHP version mismatch.

Debug:

apexweave logs yoursite.com
# Read the error message — it's almost always explicit

For WordPress specifically:

apexweave bash yoursite.com
tail -50 /var/www/html/wp-content/debug.log

Enable WordPress debug temporarily:

apexweave run "wp config set WP_DEBUG true" yoursite.com
apexweave run "wp config set WP_DEBUG_LOG true" yoursite.com

Email not working after migration

Cause: Your old host's SMTP settings don't transfer. Many shared hosts relay email through local SMTP.

Fix: Install and configure WP Mail SMTP (WordPress) or configure SMTP in your app's settings:

apexweave env:set yoursite.com SMTP_HOST=smtp.mailgun.org
apexweave env:set yoursite.com SMTP_PORT=587
apexweave env:set yoursite.com SMTP_USERNAME=postmaster@mg.yourdomain.com
apexweave env:set yoursite.com SMTP_PASSWORD=your-key

Old host still receiving traffic days after DNS change

Cause: Some DNS resolvers cached the old A record and are still using it.

Non-issue: Traffic will stop once their cache expires (TTL). You can cancel the old hosting after 48 hours safely.

After Migration: Old Hosting Cancellation

Wait at least 48 hours after DNS switch before cancelling old hosting:
- Download a fresh backup from the old host before cancellation
- Verify no email MX records are using the old host's mail servers
- Confirm all DNS records are pointing to the new host

Then cancel. Most hosts pro-rate unused time — check their cancellation policy.

Migrate your site to managed container hosting at apexweave.com/git-deployment.php and apexweave.com/wordpress-hosting.php.

Deploy Your App with Git Push

Automatic builds, environment variables, live logs, rollback, and custom domains. No server management required.

Deploy Free — No Card Required

Powered by WHMCompleteSolution