Migrate a Website to Cloud Hosting

Pick the cloud shape before you copy anything

Moving a site to cloud hosting means choosing a cloud shape, copying files and the database to the new instance, syncing changes twice, issuing SSL, then switching DNS with a TTL short enough to roll back. Keep the old server running for a week. The database is the part that needs the second sync.

Cloud is a shape, not a brand. A brochure site gains nothing from a root server, and a Node app cannot run on a shared cPanel plan. Pick the row that matches what the site actually is today.

Prices above are per month and before 18% GST. If the current site fits the first row, a cloud migration is a purchase you do not need yet.

Audit what the site depends on

The audit is what stops a migration from becoming an outage. Copy the versions, not just the files: a site built on PHP 7.4 will fatal on a PHP 8.3 image before the home page finishes rendering.

• PHP version and modules: php -v and php -m. Note anything non-standard.
• Cron and workers: crontab -l, plus systemd units or queue workers the app needs.
• Disk and database size: du -sh public_html, and the table sizes in phpMyAdmin.
• DNS: A, AAAA, CNAME, MX, TXT (SPF, DKIM), and the TTL on each record.
• Outbound services: SMTP provider, payment webhooks, external APIs bound to the server IP.

Anything that names the old IP has to change. That includes firewall allow-lists at a payment gateway and SPF records that name a mail server by address.

Snapshot the source and test the restore

A backup you have never restored is a guess. Take the archive, restore it once on the new machine, and only then start the real copy.

1. On the old server, create a full archive of the document root and a database dump, and download both.
2. Provision the cloud instance, then restore the archive into a staging folder, not the live path.
3. Import the dump into a scratch database, point a copy of the config at it, and load the site by IP.
4. Delete the staging copy or keep it as the rollback reference. Do not leave two configs in one folder.

You know the backup is real when the staging copy loads with images, stylesheets and a working login. If it fails here, it would have failed after the cutover with visitors watching.

Copy files and the database to the cloud server

rsync is better than a download and upload for one reason: run it twice and the second pass moves only what changed. The database needs its own path because it cannot be rsynced while open.

1. Sync the files: rsync -aHAX --numeric-ids --info=progress2 -e "ssh -p 22" /home/USER/public_html/ root@NEW-IP:/var/www/example.com/
2. Dump on the old server: mysqldump --single-transaction --quick --routines --triggers -u USER -p DBNAME | gzip > db.sql.gz
3. Import on the new one: gunzip -c db.sql.gz | mysql -u USER -p DBNAME
4. Set ownership and permissions: chown -R www-data:www-data /var/www/example.com, folders 755, files 644.
5. Update the config file with the new database host, user and password, then load the site by IP.

Keep the same domain name through the test and no URL search-replace is needed. The site sees its real hostname from the hosts file, so links and redirects behave normally.

Sync the delta and freeze writes

Between the first copy and the cutover, the old site keeps taking orders and comments. The delta sync closes that gap: stop writes, copy again, then take a second database dump.

1. Put the application in maintenance or read-only mode. On WordPress that is wp maintenance-mode activate.
2. Run the same rsync command again with --delete so files removed on the old server disappear on the new one. Check the destination path before you press enter.
3. Take the second dump and import it over the first. This is the copy that carries the last orders.
4. Compare a row count and the newest order ID or comment ID on both sides. They must match exactly.
5. Lift maintenance on the new server only, and leave the old one read-only until the week is over.

A shop that cannot close for even ten minutes can keep the cart read-only instead of taking the whole site down. The sync is the same; the customer simply sees a paused checkout.

Issue SSL before the cutover

A Let's Encrypt HTTP-01 challenge fails while DNS still points at the old server, because the validation request never reaches the new machine. Plan for that instead of discovering it at midnight.

• DNS-01: add the _acme-challenge TXT record at the DNS provider and issue with certbot certonly --manual --preferred-challenges dns -d example.com -d www.example.com. This works before the switch.
• Copy the existing certificate and private key from the old server if it is a paid certificate you already own. The hostname is the same, so the pair stays valid.
• Issue after the switch only if a browser warning for a few minutes is acceptable. It is not, for a store.

Check the new machine before DNS moves: openssl s_client -connect NEW-IP:443 -servername example.com should return the certificate for your domain, not a self-signed default.

Cut DNS over with a rollback plan

Lower the TTL to 300 seconds a day before the change, then switch the A record. A short TTL is the difference between a rollback that takes minutes and one that takes a day.

1. Record the current answers: dig +short A example.com, dig +short AAAA example.com and dig +short NS example.com.
2. Take a snapshot of the new instance immediately before the switch, so a bad deploy can be rolled back at the disk level.
3. Change the A record to the new IP, or move the nameservers if the whole zone is moving. The nameserver guide covers the registrar side.
4. Verify from two resolvers: dig +short example.com @1.1.1.1 and dig +short example.com @8.8.8.8.
5. Keep the old server running and paid for a week. Cancel only after mail, forms, cron and logins have all worked for seven days.

To roll back, point the A record at the old IP and wait one TTL. If customers wrote data on the new server in the meantime, dump that database back to the old one after the DNS change, or restore the instance snapshot if the machine itself is the problem.

What cloud hosting costs on WebJi

WebJi® Cloud Entry is ₹5,900 a month for 2 vCPU, 8 GB RAM and 100 GB storage, before 18% GST. Cloud Business is ₹7,900 for 4 vCPU, 16 GB and 250 GB, and Cloud Pro is ₹11,900 for 8 vCPU, 32 GB and 500 GB.

Move up a row when CPU or RAM stays above about 70% at normal traffic, not because a migration is happening. The cloud hosting page lists what each plan includes, and the migration service, ₹700 one-time for one domain with files and up to five databases, covers the copy if you would rather not run the commands. SSL is on the certificate page. Free migration is subject to terms and approval.