Moving a Growing WordPress Site to Cloudways: Migration, Costs, and Rollback

A growing WordPress site is harder to move than a new one. Its database changes while you copy it. Contact forms send messages. Scheduled tasks run. The old host may still receive visitors after you change DNS.

The copy is only part of the migration. You also need a controlled switch and a way to return without losing activity that happened afterward.

This guide provides a migration runbook for Cloudways Flexible, one WordPress installation, and an unchanged public domain. It is based on official documentation checked on September 30, 2026. We have not yet run the full migration and rollback on a representative site, so this draft makes no claims about measured downtime, speed improvements, or completion time.

1. Confirm What the Move Should Solve

Write down the reason for migrating: resource limits, an unmanageable renewal bill, slow uncached requests, or a need for more control over hosting capacity.

Capture a baseline before changing hosts. Record the current monthly cost, WordPress and PHP versions, database size, media storage, and the behavior of representative public and logged-in pages.

A host change will not automatically fix oversized images, slow third-party scripts, or an expensive plugin query. If performance is the goal, keep the site configuration comparable during the migration and optimize afterward.

Before beginning, have access to the source WordPress administrator account, hosting backups, DNS controls, and the destination Cloudways account. Also inventory email delivery, cron jobs, CDN rules, external storage, payments, and webhooks. An application copy does not establish that those separate services are correctly configured.

Multisite and domain changes require additional planning and are outside the sequence below.

2. Budget for the Entire Move

Cloudways advertises Flexible hosting starting at $11 per month. Treat that as a starting point, not the price of every suitable server. Check the provider, region, resources, and selected configuration on the External link: current pricing page (opens in a new tab).

For example, an $11 server plus one $1.50 mailbox starts at $12.50 per month before backups, taxes, other add-ons, and the old host. That is a budget illustration, not a recommended server size or checkout quote. The mailbox rate comes from the External link: Rackspace add-on FAQ (opens in a new tab).

Cloudways documents Flexible offsite backups at $0.033 per GB, rounded up in $0.50 increments. Retained backup storage is not necessarily the same as the live site's size; monitor actual usage. See External link: backup billing (opens in a new tab).

Flexible uses monthly pay-as-you-go billing. Stopping a DigitalOcean, Linode, or Vultr server does not pause its charges. Separate test servers and excess usage can also affect the bill. Review the External link: payment rules (opens in a new tab) and External link: billing guide (opens in a new tab).

We may earn a commission if you buy through affiliate links.

3. Write the Cutover and Rollback Plan First

Use a migration record that someone else could follow. Record the current DNS values and TTL, old and new origin addresses, backup locations, the person responsible for each step, and the conditions for stopping.

Define a write freeze: the period when neither copy accepts new content, uploads, orders, registrations, or submissions. A maintenance page alone may not stop API clients, payment callbacks, scheduled jobs, or administrator changes. Account for those writers explicitly.

Our suggested sequence is:

Keep the old hosting account active throughout the agreed rollback window. A useful cancellation date follows a stable operating period and successful backup verification; it should not be tied solely to the moment you edit DNS.

4. Create Backups and the Destination

Take a source backup containing the database and website files, and store an independent copy outside the old hosting account. Confirm that you can restore it to a disposable environment. A successful download is not a restore test.

Create a new WordPress application on Cloudways Flexible. Match the source's supported PHP version and required extensions where practical; avoid combining the host move with a major runtime, theme, or plugin upgrade.

If the site depends on Apache .htaccess behavior, review the stack choice before copying. Cloudways recommends its Hybrid Stack for sites relying on those rules, while its Lightning Stack uses a different serving setup. See the stack guidance in the External link: Migrator instructions (opens in a new tab).

Configure destination backups and choose their frequency and retention. Cloudways documents one-to-four-week retention and on-demand backups in its External link: server-backup guide (opens in a new tab).

5. Rehearse the Application Copy

On the source WordPress site, install and activate Cloudways WordPress Migrator. Open its wizard and choose Flexible. Supply the destination application URL, server address, database name, and SFTP credentials from Cloudways. Provide HTTP authentication details if either environment requires them.

Review whether extra database tables or custom directories need inclusion, then start the transfer. Keep credentials out of screenshots and notes intended for publication. Follow the External link: official plugin walkthrough (opens in a new tab) for the current fields.

If you prefer assistance, ask Cloudways to confirm the scope, eligibility, cost, and responsibilities for your particular site through its External link: managed-migration process (opens in a new tab). Do not assume that copying the application includes every external integration or your rollback rehearsal.

After copying, keep destination background jobs, outbound notifications, and real payment processing disabled during testing. A copied production database can contain active schedules and credentials. Use test modes and controlled recipients where appropriate.

Test the Real Hostname Before Public DNS Changes

Set the existing domain as the application's primary domain and add the aliases you use. Mapping domains in Cloudways does not change public DNS; see External link: primary and additional domains (opens in a new tab).

Cloudways documents External link: local hosts-file testing (opens in a new tab). On your test computer, temporarily map the real hostnames to the destination IP. For example:

203.0.113.10 example.com
203.0.113.10 www.example.com

The address above is reserved for documentation. Replace it and both names with your destination IP and actual domain. On Windows, the hosts file is C:\Windows\System32\drivers\etc\hosts; on macOS and Linux, it is /etc/hosts. Editing it requires elevated permissions. Back up the file and remove only your added entries after testing.

Check that your browser actually reaches the new origin, using destination access logs or another origin-specific check. A local override affects your computer; external callbacks still follow public DNS.

Arrange Valid HTTPS Before Switching Visitors

A hosts-file override does not issue a certificate, and the old host's certificate is not automatically installed on the new one. Cloudways offers Let's Encrypt and custom certificate installation in its External link: SSL guide (opens in a new tab).

Its External link: onboarding guide (opens in a new tab) places ordinary certificate issuance after DNS points to Cloudways. For an already-public HTTPS site, arrange an appropriate certificate and validation method with the provider before routing visitors to the new origin. If pre-cutover issuance is unavailable, agree a controlled traffic-blocking or maintenance arrangement that maintains valid TLS while issuance completes.

Do not dismiss certificate warnings, turn off HTTPS, or assume a local test proves public certificate readiness. A maintenance page on an origin with an invalid certificate still produces a browser warning.

6. Define What Must Pass

Use the same checks for the rehearsal and final copy:

Use uncached or logged-in checks as well as cached public pages. Record the plan, versions, page URLs, test conditions, and observed results. This draft includes no benchmark figures because those tests have not been performed.

If temporary URLs remain embedded in the database, investigate before replacing them. WordPress-aware search-and-replace tools can handle serialized data; first preview changes with --dry-run and retain a backup. See the External link: WP-CLI command reference (opens in a new tab). Do not apply a broad SQL text replacement to the whole database.

7. Freeze, Copy Again, and Switch

Lower the relevant DNS TTL in advance if your provider permits it, allowing the previous TTL to expire before cutover. Lowering it immediately before switching does not invalidate older cached records. Cloudflare explains this in its External link: TTL documentation (opens in a new tab).

At the agreed migration window:

1. Pause all identified writers and notify the people who publish or operate the site.
2. Take a fresh source backup and record the last accepted content or transaction.
3. Repeat the transfer from the frozen source. Keep the destination controlled and rerun the acceptance checks.
4. Verify HTTPS readiness and save the DNS configuration you will change.
5. Update the website's routing to the destination. Preserve email and unrelated DNS records; review www, AAAA records, and any CDN origin setting separately.
6. Check from an unmodified device and another network, and inspect access and error logs.
7. Once the destination passes, reopen writes there and enable only its intended jobs and integrations. Keep the old origin unable to accept conflicting writes.

DNS changes do not reach every visitor at once. A safe plan accounts for people still arriving at the old origin instead of letting both databases evolve independently. Cloudways' External link: onboarding guidance (opens in a new tab) distinguishes domain mapping from the DNS update itself.

Keep monitoring form delivery, application errors, new content, and scheduled tasks after the first successful page load.

8. Roll Back According to the Data State

Before the Destination Accepts New Writes

If acceptance checks fail while both copies remain frozen, restore the saved DNS or CDN origin settings and verify routing and valid HTTPS on the old host. Keep the destination read-only. Reopen the old site's writers only after confirming its data is the intended source of truth.

Some visitors may continue reaching the destination while cached routing expires. Keep its controlled response active until traffic has drained. A DNS reversal is not an instantaneous recovery.

After the Destination Accepts New Writes

Stop further writes and scheduled work on both environments, then back up both databases and uploaded files before changing anything else.

Identify the changes since cutover: posts, uploads, orders, registrations, inventory changes, form submissions, and external payment or webhook events. Decide with the site owner whether to fix forward or move the current data back to the old host.

For a content site, you may be able to transfer a current consistent copy after testing compatibility. For a store or membership site, involve someone who understands its data model and transaction history. Blindly merging tables or restoring the pre-migration backup can lose valid activity, duplicate processing, or create inconsistent records.

Only restore traffic and reopen writes once the chosen origin contains the agreed current data. Use the saved routing values as a reference, not as permission to ignore data created after cutover.

9. Retire the Old Host After Stability Is Demonstrated

Keep the source account available until your agreed operating and recovery checks pass. Verify destination backups, observe important scheduled work, and check the real hosting invoice and add-ons.

Then remove temporary hosts-file overrides, retire migration credentials and plugins where appropriate, archive the source backup and migration record securely, and confirm that no email, cron, or integration still depends on the old account.

Cancel only the services you have verified are no longer needed. Keep domain registration and email responsibilities clear. Record the cancellation confirmation and any final invoice.

The useful outcome is a site whose pages, data, integrations, and recovery process all work on the new host. A completed copy or a changed DNS record proves only one part of that result.