Book a demo
Book a demo
Login

How to Migrate a WordPress Website from WP Engine to xCloud

Updated September 25, 2026 · 15 min read

If you would rather have it done for you, the xCloud team migrates sites for free: see free website migration. This guide shows you how to move one WordPress website from WP Engine to xCloud, validate it on an xCloud demo domain, and switch production traffic safely. Use xCloud’s migration plugin as the primary method. Use Migrate Guru when the token-based migration cannot complete. The procedure includes a verified WP Engine backup, source preparation, validation, DNS and SSL cutover, a short write freeze for stateful sites, and a rollback plan.

This is a single-site WordPress migration. It is not a full-server migration and does not move WP Engine account settings, platform services, or non-WordPress applications.

Choose the migration method

Method Best for Destination requirement Important boundary
xCloud migration plugin The primary path for a standard WordPress site Create the destination through Migrate An Existing WordPress Website in xCloud Source security, cache, two-factor authentication, or host controls can block the token connection
Migrate Guru An alternative when the xCloud plugin cannot connect or finish Create an xCloud destination or demo site first Migrate Guru must be active on both sites, and the xCloud migration key is unique to the migration

Neither method guarantees zero downtime. A store, membership site, forum, learning platform, or other site that accepts writes needs a short write freeze and a final migration decision before DNS changes.

Prerequisites

  • Administrator access to the source WordPress dashboard on WP Engine
  • Access to the WP Engine User Portal for the source environment
  • An xCloud account and a destination server with enough capacity for the site
  • Access to the authoritative DNS provider for the production domain
  • A current inventory of themes, plugins, redirects, cron-dependent tasks, transactional email, forms, integrations, and caching rules
  • A low-traffic maintenance window for the final sync and DNS cutover
  • A rollback owner who can restore the previous DNS records and reopen the WP Engine site
  • A plan for dynamic data created after the first copy, such as orders, form submissions, comments, memberships, and uploads

Before you start

Record the production DNS values and take screenshots or an export of the DNS zone at your DNS provider. Do not remove unrelated MX, TXT, DKIM, DMARC, verification, or mail records during the cutover. You normally change only the web host records that xCloud identifies for the production hostname.

WP Engine manages web hosting separately from the authoritative DNS provider. Confirm where the domain’s DNS is managed before the maintenance window.

Step 1: Create and verify a WP Engine backup checkpoint

In the WP Engine User Portal, open Sites, select the source environment, open Backups, and select Create backup. Add a clear description, request the completion notification, and wait until the checkpoint has completed.

Open the completed checkpoint’s three-dot menu, select Prepare ZIP, prepare a full backup, and download it when WP Engine makes the archive available. Keep the archive outside the web root as your rollback copy. WP Engine states that prepared download links remain available for up to seven days.

Expected result: The Backups page shows a completed checkpoint, and you have a local downloadable copy containing the included site files and database.

A WP Engine full backup is not an unfiltered server image. WP Engine excludes caches, temporary files, logs, some local backup archives, and prohibited or obsolete software. That is expected.

Step 2: Inventory WP Engine-specific files and platform behavior

Record whether the site uses WP Engine caching, LargeFS, platform redirects, scheduled tasks, external API calls, transactional email, or a commerce integration. If LargeFS is enabled, WP Engine’s outbound-migration guide requires you to download the offloaded files from Amazon S3 separately because they are not supplied as ordinary local uploads.

WP Engine’s outbound guide lists platform-specific cache drop-ins and must-use components that should not be carried into another host unchanged. These include wp-content/advanced-cache.php,wp-content/object-cache.php,wp-content/mu-plugins/mu-plugin.php, and WP Engine components under wp-content/mu-plugins/. Keep the source backup intact. Remove or disable platform-specific components only in the destination copy or in a prepared export, following the migration method and WP Engine guidance.

Expected result: You have a written list of external services, dynamic data, offloaded files, scheduled work, and WP Engine-specific components that require validation or cleanup on xCloud.

Step 3: Prepare the source WordPress site

Clear the source cache. Temporarily disable WordPress security and cache plugins that can block migration requests. xCloud specifically advises disabling two-factor authentication if token migration fails and temporarily relaxing bot or application-security controls that reject the migration connection.

Do not expose credentials or leave protections disabled longer than necessary. If WP Engine controls a protection that you cannot change safely, contact WP Engine support or use the alternative migration method rather than deleting platform files from the live source.

Expected result: WordPress remains reachable, the source backup is safe, and the migration tool can make authenticated requests without a security or cache layer rejecting them.

Step 4: Create an xCloud demo destination

In xCloud, select Add New Site or +New Site, choose the destination server, and select Migrate An Existing WordPress Website. Enter the source URL, then choose the demo-site option so you can test the copy on an xCloud temporary domain before changing production DNS.

Review the PHP version, database prefix, site user, and other displayed settings. Match the source PHP requirements and plugin compatibility rather than selecting a version by guesswork.

Expected result: xCloud displays the migration-plugin step for a destination on a temporary demo domain.

Step 5: Connect the xCloud migration plugin

Download the migration plugin shown by xCloud and copy the displayed access token. In the source WordPress dashboard, upload and activate the downloaded plugin, then paste the token into the plugin.

Return to xCloud, confirm that the token has been added, and select Next.

Expected result: xCloud accepts the source connection and advances to the database migration options.

Step 6: Select the migration data and start the copy

Choose the option to migrate all database tables when you need the complete WordPress site. Use the file-system-only option only when you deliberately intend to keep the destination database.

Start the migration and leave the source site and destination available until xCloud reports completion. Do not change production DNS during this copy.

Expected result: xCloud reports that the migration completed, and the demo URL opens the copied WordPress site.

Step 7: Use Migrate Guru if the primary migration cannot complete

Create an xCloud destination or demo site if one does not already exist. Install and activate Migrate Guru on both the WP Engine source and xCloud destination.

On the xCloud destination, open Migrate Guru and select Migration Key, then copy the unique key. On the source site, open Migrate Guru, enter the notification email, select Migrate Site, choose Other Hosts, enter the destination migration key, and select Migrate.

Expected result: Migrate Guru reports a completed migration, and you can sign in to the xCloud copy with the source WordPress credentials.

Do not run both migration methods into the same destination at the same time. Choose one completed copy as the candidate for validation.

Step 8: Clean up the destination copy

Inspect wp-content/mu-plugins/ and the active plugin list on the xCloud copy. Remove or deactivate WP Engine-only cache, sign-on, strong-password, and security-auditor components according to WP Engine’s outbound-migration guidance. Do not delete ordinary must-use plugins that belong to your application without first identifying their purpose.

Confirm that the destination uses xCloud’s WordPress and database configuration. Do not copy WP Engine’s wp-config.php unchanged into xCloud. If you are using a manual backup as a recovery path, WP Engine instructs you to replace its configuration with a standard WordPress configuration populated with the destination database credentials.

Expected result: The destination no longer depends on WP Engine-only runtime components, and WordPress loads without platform-plugin or cache-drop-in errors.

Step 9: Validate the demo site

Test the demo URL before cutover. Check:

  • The home page and representative posts, pages, archives, and search
  • WordPress administrator sign-in and role permissions
  • Images, downloads, and any LargeFS content
  • Forms and their notification delivery
  • Checkout, payment sandbox behavior, accounts, subscriptions, and webhooks where applicable
  • Redirects, canonical URLs, menus, and internal links
  • Plugin and theme behavior under the selected PHP version
  • Scheduled tasks and background processing without allowing duplicate production actions
  • Transactional email with safe test recipients
  • Error logs for missing files, database errors, and PHP compatibility failures

Keep production-facing email, payment capture, webhooks, and scheduled work disabled or in a safe test mode on the demo copy. This prevents duplicate messages, charges, or automation while WP Engine still serves production traffic.

Expected result: The demo copy passes the functional checklist, contains the expected content, and produces no WP Engine-specific dependency errors.

Step 10: Create a destination backup before cutover

Create and verify an xCloud backup after the demo copy passes validation. Record the backup time and the validated demo URL in the migration notes.

Expected result: A restorable xCloud backup exists for the validated pre-cutover state.

Step 11: Prepare the final write freeze

Schedule the cutover for a low-traffic period. Put the WP Engine site into maintenance or read-only mode for the shortest practical window, and pause order intake, forms, publishing, uploads, workers, and cron-driven actions that can change data. Keep equivalent processing paused on the xCloud copy.

For a stateful site, decide how you will bring across changes made since the first copy. The public xCloud migration guides reviewed for this procedure do not document an incremental merge of two live databases. Do not run two writable copies and assume their data can be combined. If your selected tool cannot perform a supported final recopy, keep the source read-only and contact xCloud support for the safest supported final-sync path.

Expected result: Both copies are protected from new writes, and you have one clearly identified authoritative data set for the final cutover.

Step 12: Complete the final copy and revalidate critical data

Run the supported final migration or recopy using the same selected method. Confirm the latest orders, users, form entries, posts, comments, uploads, and other stateful records on xCloud before changing DNS.

Keep workers, cron jobs, payment capture, outgoing email, and webhooks paused on both environments during this check.

Expected result: The xCloud database and files contain the agreed final state, with no newer records left only on WP Engine.

Step 13: Move the demo site to the production domain

In the xCloud site dashboard, open Domain, select Go Live, and enter the production domain under Domain Setup. Open DNS Setup and note the exact records xCloud displays.

Moving an xCloud demo site to live is a one-way change. xCloud states that the site cannot return to its former demo domain after it goes live.

Expected result: xCloud displays the DNS values required for the production domain and is ready to verify them.

Step 14: Update DNS at the authoritative provider

Change the production web record or records to the values shown by xCloud. Remove only records that conflict for the same web hostname. Preserve unrelated mail, verification, and service records.

Return to xCloud and select Verify My DNS. DNS caches update at different times, so some visitors can reach the old host while others reach xCloud during propagation.

Expected result: Authoritative DNS returns the xCloud destination for the production hostname, and xCloud verifies the domain.

Step 15: Enable and verify HTTPS

In the xCloud site dashboard, open SSL/HTTPS and select the certificate route that matches the domain setup: xCloud-managed free SSL, your own certificate, or Cloudflare-managed SSL. If you use xCloud’s free certificate behind Cloudflare, xCloud’s Let’s Encrypt guide says to disable the Cloudflare proxy during certificate issuance.

Load the production domain over HTTPS and inspect the certificate, redirects, pages, assets, forms, and administrator area.

Expected result: The production domain serves the xCloud site over HTTPS without certificate, redirect-loop, or mixed-content errors.

Step 16: Resume production processing on xCloud

After DNS and HTTPS validation, enable the destination workers, scheduled tasks, webhooks, transactional email, and payment processing that you intentionally paused. Keep the WP Engine copy in maintenance or read-only mode so it cannot create a second stream of production data.

Monitor application logs, form delivery, checkout events, scheduled actions, and external integrations through the rollback window.

Expected result: xCloud is the only writable production environment, and expected background and external services run once.

Verify the migration

The migration is complete when all of these checks pass:

  • The authoritative production DNS record resolves to the xCloud destination.
  • The production domain serves a valid HTTPS certificate.
  • Public pages, assets, downloads, redirects, forms, and search work.
  • WordPress administrator access and user roles work.
  • The newest expected content and dynamic records exist on xCloud.
  • WP Engine-specific must-use and cache components are not producing errors on xCloud.
  • Email, payments, webhooks, workers, and scheduled tasks run only on xCloud.
  • The xCloud backup and the original WP Engine checkpoint are both available.
  • The WP Engine source remains retained but read-only during the agreed rollback window.

Troubleshooting

Symptom Likely cause Fix
xCloud cannot connect with the migration token Two-factor authentication, a security plugin, cache layer, bot protection, or host control rejects the request Clear caches, temporarily disable the blocking WordPress control, retry, or use Migrate Guru. Do not weaken controls longer than the migration requires.
Migration finishes but images or downloads are missing Uploads were excluded, offloaded, or stored with LargeFS Compare the WP Engine backup contents with the source. If LargeFS is used, download the offloaded objects from Amazon S3 and restore them to the destination.
The destination shows WP Engine plugin or cache errors WP Engine-specific cache drop-ins or must-use components remain active Remove only the WP Engine-specific components identified in WP Engine’s outbound guide, then clear xCloud and WordPress caches.
The site connects to the wrong database or fails after a manual restore WP Engine’s wp-config.php was copied unchanged Use the destination WordPress configuration and xCloud database settings. Do not reuse WP Engine database credentials.
Some visitors still see WP Engine after cutover DNS caches have not expired, or a conflicting record remains Check the authoritative answer, verify the exact host record, remove same-host conflicts, and allow propagation. Do not delete unrelated DNS records.
HTTPS fails after DNS verification DNS is not fully pointed, Cloudflare proxying blocks issuance, or the wrong certificate route was selected Confirm DNS first. Follow the selected xCloud SSL route and disable the Cloudflare proxy during xCloud-managed certificate issuance when required.
Orders or form entries differ between hosts Both copies accepted writes, or the final state was not recopied Keep both copies read-only, identify the authoritative data set, capture any destination-only writes, and use a supported restore or reconciliation plan before reopening production.
Duplicate emails, charges, or scheduled actions occur Automation was active on both environments Pause processing on both sides, identify the authoritative environment, then enable each integration only on xCloud after cutover.

Common mistakes

  • Treating the task as a full-server migration. This guide moves one WordPress site. It does not reproduce WP Engine’s hosting platform or account configuration.
  • Skipping the WP Engine checkpoint. The migration tool is not your rollback backup. Create and download a checkpoint before changing the source.
  • Testing only the home page. Missing uploads, checkout failures, role problems, webhooks, and cron errors often appear away from the home page.
  • Copying WP Engine’s configuration unchanged. WP Engine-specific cache files, must-use components, and wp-config.php settings do not automatically belong on xCloud.
  • Changing DNS before the final state is ready. Validate the demo copy and complete the write freeze and final recopy first.
  • Leaving both sites writable. This creates split-brain data that ordinary WordPress migration tools may not merge safely.
  • Deleting the entire DNS zone. Change only the required web-host records and same-host conflicts. Preserve mail and verification records.
  • Decommissioning WP Engine immediately. Keep the source and its backup available through the rollback window.

Rollback guidance

Rollback is safe only while you can identify one authoritative data set.

  1. Put the xCloud site into maintenance or read-only mode and pause its workers, cron jobs, email, webhooks, and payment processing.
  2. Keep the WP Engine site read-only while you identify any writes that reached xCloud after cutover.
  3. Export or record destination-only orders, users, submissions, uploads, or other writes before changing traffic.
  4. Decide whether those writes will be reconciled into WP Engine or explicitly discarded. Do not resume both copies as writable production sites.
  5. Restore the previous web DNS records at the authoritative provider.
  6. Wait until production traffic has drained from xCloud and the domain consistently reaches WP Engine.
  7. Verify HTTPS and critical functions on WP Engine.
  8. Resume writes and automation on WP Engine only after the source is again authoritative.

A rollback can lose post-cutover data when no supported reverse synchronization exists. State that risk in the maintenance plan before migration begins.

Frequently asked questions

Can I migrate directly to the production domain?

xCloud supports entering a custom domain during migration, but its documentation recommends using a temporary demo domain first. The demo route lets you validate the copy before production DNS changes.

Does this migrate my WP Engine account and platform settings?

No. It migrates WordPress files and selected database content. Recreate or replace platform-specific caching, redirects, email, scheduled work, external services, and security behavior on xCloud as needed.

Can I keep WP Engine must-use plugins on xCloud?

Do not carry WP Engine-only components into xCloud unchanged. WP Engine’s outbound guide identifies platform-specific cache drop-ins and must-use components to remove from the exported copy. Keep application-specific must-use plugins only after you verify what they do.

Can I avoid all downtime?

Do not promise zero downtime. DNS propagation and the final stateful-data sync can create a short period of inconsistent access. Use a low-traffic window, a write freeze, clear ownership of the authoritative database, and a tested rollback plan.

When should I use Migrate Guru?

Use it when the primary xCloud token migration cannot connect or finish and both WordPress dashboards remain accessible. Install it on both sites, obtain the migration key from the xCloud destination, and choose Other Hosts on the source.

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