Migrating a WordPress Site from Cloudways to Getwebup

Cloudways doesn't hand you a cPanel account, so every WordPress migration guide written for shared hosting stops being useful the moment you try to follow it. There's no "full account backup" button, no Softaculous, and email was never part of the package in the first place. If you're moving a WordPress site from Cloudways to Getwebup, here's the version that actually matches what you'll see on screen.

Why this migration is different from a cPanel move

Cloudways runs your site inside its own container platform (DigitalOcean, AWS, Vultr, or GCE under the hood) and fronts everything with its own management panel. You get SSH and SFTP access, an Application Access panel with "master" and "application" credentials, and usually the Breeze caching plugin pre-installed. What you don't get is a familiar file manager, a one-click full backup you can just re-upload elsewhere, or mailboxes tied to the domain.

That last part catches people out the most. Cloudways has never hosted email — if mail@yourdomain.com currently works, it's routed through Google Workspace, Zoho, or some other third-party MX record, not through Cloudways at all. So unlike a HostGator or Bluehost move, you won't lose mailboxes mid-migration. You will, however, break mail delivery if you're not careful with SPF records once you add Getwebup's mail server into the mix.

Before you start: a 15-minute audit

• Note your SSH port. Cloudways assigns a random SSH port (not 22) per server. Find it under Server → Master Credentials in the Cloudways panel — you'll need it for every SFTP and SSH command below.
• Grab both credential sets. Master credentials give server-wide SSH/SFTP access; application credentials are scoped to one app's folder. Either works for a single-site move, but master is faster if you're comfortable with the whole filesystem.
• Find your database name. Cloudways names databases oddly (often a string like fjqfmqxxpz), not your domain name. It's on the Application → Access Details tab, not in wp-config.php at a glance — though it is in there too.
• Check who owns DNS. Cloudways doesn't sell domains, so your nameservers are almost certainly already pointed at Cloudflare, your registrar, or a third party. Confirm with dig NS yourdomain.com before you assume anything needs to move.
• Decide whether Breeze cache needs to come off. If Breeze is active, plan to deactivate it before export — a cached copy of old URLs baked into HTML can survive the move and serve stale pages.

Step-by-step migration

1. Export the database

SSH into the Cloudways server on its custom port:

ssh -p 22022 master_username@your-server-ip

Then dump the database from inside the app folder:

cd applications/yourappname/public_html
mysqldump -u db_user -p db_name > site-backup.sql

Compress it before you transfer it — Cloudways databases for busy WooCommerce stores routinely hit several hundred MB uncompressed:

gzip site-backup.sql

2. Package and pull the files

Deactivate Breeze cache from wp-admin first, then zip the whole webroot (skip wp-content/cache, it's dead weight):

zip -r site-files.zip public_html -x "public_html/wp-content/cache/*"

Pull both archives to your machine with scp, remembering the non-default port:

scp -P 22022 master_username@your-server-ip:~/applications/yourappname/public_html/site-files.zip .
scp -P 22022 master_username@your-server-ip:~/applications/yourappname/public_html/site-backup.sql.gz .

3. Create the destination and upload

In cPanel on Getwebup, create the database and a database user under MySQL Databases, assigning ALL PRIVILEGES. Then upload both archives through File Manager (or SFTP, faster for large files), extract site-files.zip into public_html, and import the SQL through phpMyAdmin — for anything over ~50MB, upload the .gz file directly and let phpMyAdmin decompress it rather than fighting the upload limit on a raw .sql.

4. Fix wp-config.php and search-replace URLs

Edit the new wp-config.php with the Getwebup database name, user, password, and localhost as the host (Cloudways sometimes uses a non-localhost DB host internally, which won't apply here). Then run a proper serialized search-replace — not a raw SQL UPDATE, which corrupts serialized arrays in widget and page-builder data:

wp search-replace 'https://yourdomain.com' 'https://yourdomain.com' --skip-columns=guid --all-tables

Even when the domain string is identical, this catches any hardcoded references to the old server IP or a Cloudways staging subdomain that leaked into post content.

5. Test before touching DNS

Point your own machine at the new server without changing DNS for anyone else, by editing your hosts file (/etc/hosts on Mac/Linux, C:\Windows\System32\drivers\etc\hosts on Windows):

203.0.113.10  yourdomain.com www.yourdomain.com

Browse the full site this way — checkout flow if it's WooCommerce, contact forms, login — before you touch a single DNS record.

6. Cut over DNS

Update the A record at wherever your nameservers actually live (Cloudflare, your registrar, whoever it turned out to be in the audit step) to point at the Getwebup server IP. Leave MX records exactly as they were — email was never on Cloudways, so it doesn't need touching. Propagation is typically visible within a couple of hours if the previous TTL was low.

Issues that show up after the move

Prevention: keep a rollback path

Don't delete the Cloudways app the moment DNS switches — Cloudways bills by the hour, so keeping it alive for 48-72 hours costs a few rupees and gives you a live fallback if something surfaces that testing missed. Once traffic and mail have run clean for a couple of days, pause or delete the old server.