Book a demo
Book a demo
Login

How to Migrate a WordPress Website from Cloudways to xCloud

Updated September 25, 2026 · 12 min read

Moving every site on a Cloudways Flexible server? Use the Cloudways full server migration instead, and if you would rather have it done for you, the xCloud team migrates sites for free: see free website migration. This guide moves one WordPress website from Cloudways to xCloud by using xCloud’s WordPress migration workflow. It is for site owners and administrators who can access the Cloudways-hosted WordPress dashboard, create a destination site in xCloud, and update the domain’s DNS. You will create a source backup, copy the site to a temporary xCloud destination, validate it, freeze writes for the final migration window, switch DNS, confirm SSL, and keep Cloudways available for rollback.

Choose the correct migration method

Use the xCloud migration workflow for one WordPress website. Do not use Cloudways’ WordPress Migrator plugin for this direction. Cloudways documents that plugin for migrations into Cloudways, not from Cloudways to xCloud.

Situation Recommended path
One WordPress site, with WordPress administrator access xCloud WordPress migration workflow
The xCloud migration workflow cannot complete, but both WordPress dashboards remain accessible Migrate Guru with xCloud
Several WordPress sites on one Cloudways Flexible server, with Master Credentials Cloudways full-server migration
Cloudways Autonomous or an account without server-level Master Credentials Use this site-level guide for each WordPress site. Do not substitute application credentials in the full-server workflow.

Prerequisites

  • Administrator access to the source WordPress dashboard on Cloudways.
  • Access to the Cloudways application so you can create and restore a backup.
  • An xCloud account and a destination server with enough storage for the site’s files, database, backups, and working space.
  • Access to the authoritative DNS provider for the production domain.
  • A list of forms, checkout flows, logins, redirects, scheduled tasks, and integrations that must work after migration.
  • A maintenance window for a short write freeze if the site accepts orders, comments, form submissions, memberships, or other changing data.
  • A current inventory of Cloudways-specific caching, security, mail, and must-use plugins.
  • A separate copy of business-critical data that you can restore without relying only on either hosting platform.

The xCloud source guide does not document an incremental final-sync feature for this plugin workflow. For a stateful site, plan a write freeze before the definitive copy. If the site is too active for that window, ask xCloud support which supported recopy or assisted migration method applies before changing DNS.

Step 1: Create a source backup in Cloudways

Open the selected application in Cloudways and use its application backup control to create an on-demand backup. In Cloudways Flexible, the current help material places this under Workflow/Tools → Backup/Restore → Take Backup Now. Interface labels can differ between Cloudways Flexible, Autonomous, and newer dashboard experiences.

Expected result: Cloudways shows a completed backup or restore point for the correct application. Record its time before continuing.

Step 2: Record the source site’s current state

Export or record the information you need to compare after migration: WordPress and PHP versions, active theme and plugins, permalink structure, administrator access, critical URLs, redirects, cron-dependent features, mail delivery, and external integrations. Record the current DNS values and the authoritative DNS provider separately from the domain assigned inside Cloudways.

Expected result: You have a migration checklist for the exact site and know where to reverse the DNS change if rollback is required.

Step 3: Prepare the Cloudways site for copying

Clear the application cache. Inventory Cloudways-specific caching, security, and must-use plugins before migration. Do not remove a source-side component blindly if the live site depends on it.

If the xCloud token cannot connect, follow xCloud’s documented troubleshooting sequence: temporarily disable Cloudways Bot Protection or another blocking security layer, then retry. Keep the exception as narrow and short-lived as possible.

Expected result: The source site remains healthy, and WordPress can accept the xCloud migration plugin connection.

Step 4: Create a temporary destination in xCloud

Sign in to xCloud, select Add New Site, choose the destination server, and select Migrate An Existing WordPress Website. Use a demo or temporary xCloud domain instead of assigning the production domain immediately.

Enter the source site URL, select the destination server, and review the destination settings, including the PHP version, database prefix, and site user choices.

Expected result: xCloud creates a destination workflow that you can test without directing production traffic away from Cloudways.

Step 5: Install the xCloud migration plugin on the source site

On the xCloud migration workflow’s Plugin step, download the plugin file and copy the authentication token. In the Cloudways-hosted WordPress dashboard, open Plugins → Add New → Upload Plugin, upload and activate the plugin, then paste the token into the plugin.

Return to xCloud, confirm that the token was added, and continue.

Expected result: xCloud recognizes the source WordPress site and allows you to continue to database settings.

Step 6: Set the definitive write freeze

For a site with changing data, enable maintenance mode or otherwise stop new orders, comments, form submissions, membership changes, and content edits immediately before the definitive copy. Pause any source cron job or queue worker that writes to the database or uploads directory.

Do not enable production cron jobs or background processing on the xCloud copy yet. This prevents both copies from processing the same task.

Expected result: Cloudways is the known authoritative copy, but it is no longer accepting writes that could be missed during migration.

Step 7: Start the migration in xCloud

In xCloud’s Database step, choose whether to migrate all database tables or only the filesystem. For a complete WordPress migration, use the option that includes the site’s required database content and files. Review the selection, then start the migration.

Keep the Cloudways site and its backup available. Do not change DNS while the copy is running.

Expected result: xCloud reports that the migration completed and the temporary destination loads.

Step 8: Validate the temporary xCloud site

Open the temporary xCloud URL and check the following before cutover:

  • Homepage, representative posts, pages, archives, and custom post types.
  • WordPress administrator login and role permissions.
  • Media Library items and direct upload URLs.
  • Forms, search, comments, checkout, memberships, and other write paths.
  • Permalinks, canonical URLs, redirects, and mixed-content warnings.
  • Theme output, plugin features, REST API consumers, and webhooks.
  • Transactional email using the destination’s intended mail configuration.
  • Scheduled actions, cron-dependent features, and any queue processing, without allowing duplicate production execution.

Remove or replace Cloudways-only caching, security, and must-use components on the destination when they are not compatible with the xCloud stack. Do not remove the source copy yet.

Expected result: The xCloud copy matches the Cloudways source for required content and behavior, and every blocking issue has a recorded resolution.

Step 9: Create an xCloud backup before cutover

Configure and run an xCloud site backup after the restored files and database pass validation. Confirm that the backup appears under the site’s backup history and is restorable according to Site Backups in xCloud.

Expected result: You have a known-good destination recovery point from before production traffic and background processing begin.

Step 10: Prepare DNS and domain cutover

At least one existing TTL interval before the maintenance window, lower the TTL for the records you will change. Confirm the authoritative DNS response shows the lower TTL before relying on it.

In xCloud, change the temporary site to the production domain or use the site’s current domain-change flow. Follow the DNS target values xCloud displays for that site. Update the relevant records at the domain’s authoritative DNS provider, not merely in Cloudways Domain Management.

Expected result: Authoritative DNS returns the xCloud destination values. Some users may still reach Cloudways until cached records expire.

Step 11: Verify HTTPS and production traffic

Wait for xCloud’s certificate workflow to issue or attach SSL for the production domain. Test both the apex and www hostname if both are used. Check HTTP-to-HTTPS behavior, canonical redirects, secure cookies, and mixed content.

Then repeat the critical validation checklist through the production domain. Review xCloud and application logs for errors while traffic moves.

Expected result: The production domain serves the validated xCloud site over HTTPS without certificate warnings or redirect loops.

Step 12: Resume destination processing

When DNS and HTTPS checks pass, enable the intended xCloud cron jobs, scheduled actions, queues, and other background processing. Keep the Cloudways copy read-only while cached DNS traffic drains.

Do not run equivalent processors on both hosts at the same time.

Expected result: xCloud handles production web traffic and background work, while Cloudways remains available only as a rollback source.

Verify the migration

The migration is complete only when all of these checks pass:

  • The production domain resolves to the xCloud destination from more than one network or DNS resolver.
  • HTTPS works for every production hostname without a browser warning.
  • WordPress administrator login works, and expected users and roles are present.
  • Recent posts, orders, comments, form entries, membership records, and uploads match the frozen Cloudways source.
  • Forms, checkout, search, redirects, email, webhooks, scheduled actions, and queues behave as expected.
  • xCloud has a verified destination backup.
  • Cloudways remains read-only and available during the agreed rollback window.

Rollback guidance

Rollback is a traffic and data decision, not only a DNS reversal.

  1. Stop writes and background processing on xCloud.
  2. Keep Cloudways read-only while you inspect any data created after cutover.
  3. Choose which database is authoritative. Reconcile the xCloud write delta back to Cloudways using a supported application-specific process, or explicitly accept that discarding it can lose data.
  4. Restore the previous authoritative DNS records.
  5. Wait for xCloud traffic to drain according to the DNS TTL and resolver caches.
  6. Re-enable source-side writes, cron jobs, and queues only after Cloudways is serving traffic again.

Do not allow both copies to accept writes during rollback. The xCloud plugin source does not document reverse synchronization from xCloud to Cloudways.

Troubleshooting

Symptom Likely cause Fix
xCloud cannot authenticate the source plugin Cloudways Bot Protection, a security plugin, 2FA enforcement, or another request filter blocks the token flow Clear caches, temporarily relax only the blocking control, retry, then restore the control after the copy completes.
Migration stalls or times out A large fileset, cache directory, security scan, or resource limit slows the source Remove disposable caches from the migration set, confirm source health, and contact xCloud support before retrying. Keep the completed Cloudways backup.
The destination shows old or missing content The copy excluded required database tables or writes continued after the copy began Keep both sites read-only, compare the frozen source with xCloud, and repeat only through a supported migration or assisted recopy process. Do not merge production databases manually without an application-specific plan.
Images return 404 Uploads did not copy completely, paths changed, or rewrites are stale Compare the uploads directory, regenerate permalinks if appropriate, clear destination caches, and inspect representative media URLs.
The site redirects to the temporary or Cloudways URL WordPress URL values, cache, a plugin rule, or an external redirect still references the old host Confirm the production domain in xCloud and WordPress, clear caches, and inspect redirect and canonical settings.
SSL issuance fails DNS does not yet point to xCloud, an old record remains, or a proxy blocks validation Verify authoritative A/AAAA/CNAME records against xCloud’s displayed values, remove conflicting records, and retry the supported certificate flow.
Emails are not delivered Cloudways mail settings did not transfer or the destination lacks an authenticated mail provider Configure the intended transactional mail service on xCloud and test delivery before reopening forms or checkout.
Orders or scheduled actions run twice Both hosts have active cron jobs, queues, or webhooks Pause processing on both hosts, choose the authoritative dataset, reconcile any duplicate effects, then enable processing only on xCloud.

Common mistakes

  • Using the wrong Cloudways plugin. Cloudways’ WordPress Migrator is documented for moving a site into Cloudways. Use xCloud’s migration flow for Cloudways to xCloud.
  • Choosing full-server migration for one site. Site-level migration needs WordPress access. Full-server migration is a separate workflow for eligible Cloudways Flexible servers with Master Credentials.
  • Changing DNS before validation. A temporary xCloud domain lets you test the copy without exposing visitors to an incomplete migration.
  • Assuming Cloudways Domain Management controls authoritative DNS. It assigns the domain to the Cloudways application. Change public records at the actual authoritative DNS provider.
  • Letting both copies accept writes. This creates split-brain data that DNS rollback cannot repair automatically.
  • Copying host-specific must-use plugins without review. A component designed for the Cloudways stack can conflict with destination caching or security behavior.
  • Cancelling Cloudways immediately. Keep the source and backup available until DNS caches drain and the rollback window closes.

Frequently asked questions

Can I migrate without Cloudways Master Credentials?

Yes. The primary workflow in this guide uses WordPress administrator access and xCloud’s site migration plugin. Master Credentials apply to xCloud’s separate Cloudways full-server migration flow.

Should I use Migrate Guru instead?

Use xCloud’s WordPress migration workflow first. Migrate Guru is a documented xCloud-compatible alternative when you can access both WordPress dashboards and the primary workflow cannot complete.

Will the migration have zero downtime?

Do not assume zero downtime. A stateful site needs a short write freeze unless xCloud confirms a supported final-sync method for your case. DNS caches can also send some visitors to the source after records change.

Does the Cloudways SSL certificate move with WordPress?

No documented source supports transferring the Cloudways certificate as part of this plugin migration. Provision and verify SSL for the production domain on xCloud after the domain points to the destination.

When can I remove the Cloudways site?

Remove it only after production DNS, HTTPS, content, logins, forms, email, scheduled work, and backups are verified, the rollback window has closed, and no traffic remains on the source.

If you run into any issues migrating from Cloudways, feel free to reach out to our support team for help.