Migrating a Website from Shared Hosting to the Cloud (2026 Guide)

By Khimananda Oli | Last reviewed: August 2026

Shared hosting is cheap and convenient until the day it stops keeping up — a traffic spike returns 503s, a noisy neighbour eats the CPU you paid for, or you need a PHP extension the control panel will not install. Migrating a website from shared hosting to the cloud moves you onto a VPS or cloud instance you fully control, and done properly it costs your visitors almost no downtime. This guide is the exact runbook I use for client moves: inventory what you have, provision the server, copy files with rsync, move the database with mysqldump, wire up Nginx and SSL, then lower the DNS TTL and cut over. If you would rather hand the whole move off, the cloud migration and DevOps services cover it end to end.

What do you need before migrating a website to the cloud?

Every smooth migration starts with an inventory, not a server. Before you provision anything, write down exactly what the live site is made of so nothing is left behind on the old host. Capture the following:

• Application files — the document root, plus anything above it (config, cron scripts, .env).
• The database — name, size, character set, and the credentials the app uses.
• Runtime — the exact PHP version and enabled extensions (php -v and php -m on the old host).
• Cron jobs — export them with crontab -l; shared panels hide these in the UI.
• DNS records — the current A/AAAA, MX (email!), CNAME, and TXT/SPF records, and crucially the current TTL value.
• SSL — which domains need certificates after the move.

The one item people forget is email. If your MX records point at the shared host's mail service, do not change them during a web migration — leave MX untouched and only move the A record for the website. Getting this list right up front is what turns a stressful cutover into a routine one, the same discipline behind every project in the cloud deployment case studies.

How do you provision the cloud server and move the files?

Pick a VPS close to your audience — for a Nepal-heavy site, a Singapore or Mumbai region keeps latency low. A 2 vCPU / 4 GB instance running Ubuntu 24.04 LTS is a comfortable starting point for most brochure sites, blogs, and small apps. Install the same stack the app expects: Nginx, PHP-FPM matching the old PHP version, and MySQL 8. If you are new to standing up the web tier, the Ubuntu VPS with Nginx deployment guide walks through the server block and PHP-FPM setup step by step.

With the server ready, copy the files. Use rsync over SSH rather than a zip download — it transfers only what changed, preserves permissions and timestamps, and can be re-run to catch last-minute edits without recopying everything. Run this from the old host (or a machine that can reach both):

# Dry run first — see what would transfer, change nothing
rsync -avz --dry-run -e ssh /home/olduser/public_html/ \
    deploy@NEW_SERVER_IP:/var/www/example.com/

# Real sync once the dry run looks right
rsync -avz --delete -e ssh /home/olduser/public_html/ \
    deploy@NEW_SERVER_IP:/var/www/example.com/

The trailing slashes matter: public_html/ copies the contents into the target directory. Use --delete only on the final sync so the destination mirrors the source exactly. Then set ownership so the web server can read and write where it needs to:

sudo chown -R www-data:www-data /var/www/example.com
sudo find /var/www/example.com -type d -exec chmod 755 {} \;
sudo find /var/www/example.com -type f -exec chmod 644 {} \;

How do you migrate the database without losing data?

The database is the part that changes second by second on a live site, so it moves last and fast. Export it on the old host with mysqldump, transfer the file, and import it on the new server. The --single-transaction flag gives a consistent snapshot of InnoDB tables without locking writes, so the old site keeps serving during the dump:

# On the old host — consistent, gzip-compressed dump
mysqldump --single-transaction --routines --triggers \
    -u dbuser -p old_database | gzip > backup.sql.gz

# Copy the dump to the new server
scp backup.sql.gz deploy@NEW_SERVER_IP:/tmp/

# On the new server — create the DB, then import
mysql -u root -p -e "CREATE DATABASE example_db \
    CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
gunzip < /tmp/backup.sql.gz | mysql -u root -p example_db

Match the character set (utf8mb4) to the old database or you will corrupt emoji and non-Latin text — which matters for Nepali content. After importing, create a dedicated app user rather than reusing root, and update the application config to point at localhost (or your managed DB endpoint) with the new credentials. Load the site by IP or a temporary host entry and click through it before touching DNS.

How do you cut over DNS with minimal downtime?

This is where zero-downtime migrations are won or lost. The trick is the TTL (time to live) — the number of seconds resolvers cache your DNS record. If your A record has a 24-hour TTL, some visitors keep hitting the old server for a full day after you change it. So you lower the TTL before the move, not during it.

1. About 24 hours ahead, drop the A record's TTL to 300 (5 minutes). Wait for the old, long TTL to expire so resolvers pick up the short one.
2. At cutover, change only the A record's value to the new server's IP. Leave MX, TXT/SPF, and any mail-related records exactly as they were.
3. Within minutes, resolvers begin sending traffic to the new server. Confirm your own view with dig.
4. After a day or two, once you are certain everything landed on the new box, you can raise the TTL back to 3600 or higher.

# Check the current TTL and target before you change anything
dig +nocmd example.com A +noall +answer

# After cutover, confirm the record now returns the new IP
dig +short example.com @1.1.1.1

# Watch it flip from a machine near your users
dig +short example.com @8.8.8.8

How do you set up SSL and verify the new site?

Do not wait for DNS to point at the new box to think about HTTPS. Once the A record resolves to the cloud VPS, issue a free Let's Encrypt certificate with Certbot so the site is secure from the first request on the new server:

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com
# Certbot installs the cert, edits the Nginx block, and sets up auto-renewal

Certbot's HTTP-01 challenge needs the domain already resolving to the new server, so the natural order is: cut over DNS, confirm with dig, then run Certbot. If you need the certificate in place before cutover, use a DNS-01 challenge instead. Either way, the full walkthrough of issuance and renewal lives in the free SSL with Let's Encrypt and Certbot guide. After the certificate is live, run through a verification checklist:

• Every page loads over https:// with no mixed-content warnings.
• Forms, logins, and search actually submit and hit the new database.
• File uploads write to the correct directory and existing media still displays.
• Cron jobs are re-created on the new server (crontab -e).
• Server logs (tail -f /var/log/nginx/error.log) are clean under real traffic.
• Email still flows — because you left MX untouched.

What is the rollback plan if the migration fails?

The reason this whole approach is low-risk is the rollback path, and it costs you nothing to keep. Because you lowered the TTL and never deleted anything from the old host, backing out is simply changing the A record back to the old IP — and within about five minutes traffic returns to the shared host as if nothing happened. That safety net is why you keep the old hosting account active for at least a week after cutover, not cancel it the same day.

The only real risk is data written to the new database after cutover being lost if you roll back to the old one. Minimise it by doing the final database import as close to the DNS change as possible, and by keeping the migration window short. For a busy site, put the app in a brief maintenance mode during the final dump-and-import so no writes are stranded on either side. Keep the mysqldump file and a snapshot of the new server as your record of the exact state at cutover.

Conclusion

Migrating a website from shared hosting to the cloud is not a leap of faith when you sequence it correctly: inventory everything, provision the VPS, sync files with rsync and the database with mysqldump while the old site stays live, lower the DNS TTL a day early, then cut over and verify with the old host still standing by. That order is what keeps downtime to minutes and gives you a five-minute rollback if anything looks wrong. When you are ready to move — or want it done for you with the cutover planned around your traffic — get in touch or read more on the DevOps and cloud blog for the deployment steps that follow the move.