# How to Migrate a WordPress Website from Rocket.net to xCloud

> Move a WordPress site from Rocket.net to xCloud with the migration plugin and token, or Migrate Guru: backup, demo validation, write freeze, DNS, rollback.

If you would rather have it done for you, the xCloud team migrates sites for free: see [free website migration](/website-migration/). This guide moves one WordPress website from Rocket.net to xCloud while keeping the Rocket.net copy available for rollback. It is for site owners and administrators who can manage WordPress plugins, Rocket.net backups, DNS records, and an xCloud destination. Use xCloud's token-based migration flow first. If that transfer cannot connect or complete, use Migrate Guru as the supported alternative.

Do not cancel Rocket.net or remove the source site until the xCloud copy, DNS, HTTPS, forms, scheduled tasks, and recent content all pass verification.

## Choose the migration method

**Use a site-level WordPress migration for Rocket.net.** This guide does not use xCloud Full Server Migration because Rocket.net is a managed WordPress platform, not a source server on which you control root SSH and the web stack.

| Method | Use it when | Important boundary |
|---|---|---|
| xCloud migration flow | You can install the xCloud migration plugin on the Rocket.net WordPress site. | If the token cannot connect, troubleshoot security and caching before retrying. |
| Migrate Guru | The xCloud token flow still fails, or you prefer the alternative that xCloud documents. | Install and activate Migrate Guru on both the source and destination, then use the migration key from the xCloud destination. |
| Assisted or manual migration | Neither plugin route completes, or the site has unusual files, database tables, or platform-specific behavior. | Ask xCloud support to confirm the supported transfer method. Do not improvise a server-level copy from a managed host. |

## Prerequisites
- Administrator access to the Rocket.net WordPress dashboard.
- Access to the Rocket.net control panel and its current backup or restore points.
- Permission to install and activate WordPress plugins on the source site.
- An xCloud account with a ready destination server and enough storage for the site.
- Access to the authoritative DNS provider for the production domain.
- A record of the current A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC, and verification records.
- An inventory of active plugins, themes, redirects, scheduled tasks, transactional email, forms, integrations, and cache behavior.
- A maintenance or read-only plan for orders, memberships, comments, form submissions, uploads, and other stateful data.
- A rollback window during which the Rocket.net site and its backups remain available.

## Before you migrate

**Preserve the source and know what the migration will not reproduce automatically.** Rocket.net documents daily file and database backups. Confirm that the latest usable restore point predates your migration work. If your recovery policy requires an offline copy, ask Rocket.net support for the currently supported export method rather than assuming a panel backup is downloadable.

Record Rocket.net-specific behavior that may need a separate xCloud configuration, including CDN or firewall behavior, redirects, cache exclusions, PHP settings, scheduled jobs, email delivery, and any host-specific must-use plugins. Do not remove an unfamiliar must-use plugin from production without confirming its purpose.

## Step 1: Inventory the Rocket.net site

Open the source WordPress dashboard and record the WordPress version, PHP version, active theme, active plugins, must-use plugins, domain variants, redirects, cron-dependent features, transactional email path, and external services.

Check the site for content stored outside the normal WordPress files and database, such as externally stored media or a third-party search index. Record how each external component reconnects after migration.

**Expected result:** You have a component list that can be checked against the xCloud copy, including configuration that a plugin migration may not reproduce.

## Step 2: Confirm a recoverable Rocket.net backup

In Rocket.net, confirm that a recent backup exists for both the site's files and database. Rocket.net's published backup description states that daily backups cover files and databases and support point-in-time restoration.

Do not treat the hosting backup as your only safety copy if your organization's recovery policy requires an independent export. Obtain the additional copy through a Rocket.net-supported method before continuing.

**Expected result:** You can identify the restore point you would use if the source changes or the migration attempt causes a problem.

## Step 3: Prepare the source WordPress site

Update only the components you would normally update before a migration, then clear application caches. Record security, cache, and must-use plugins before changing anything.

Try the xCloud migration with normal Rocket.net protections in place. If the token connection fails, follow xCloud's guidance to review two-factor authentication, bot protection, cache plugins, and WordPress security plugins. Because Rocket.net manages its edge security, ask Rocket.net support to confirm a temporary allowlist or supported migration window instead of weakening controls without a recovery plan. Re-enable every changed control after the copy.

**Expected result:** The source remains operational, a current backup exists, and no known cache or security control is blocking the planned transfer.

## Step 4: Create the xCloud destination as a demo site

In xCloud, select **Add New Site**, choose the destination server, and select **Migrate An Existing WordPress Website**. Enter the Rocket.net source URL and choose a demo site or temporary domain for the first copy.

Using a temporary destination lets you validate the migrated site before changing production DNS. Do not point the production domain to xCloud at this stage.

**Expected result:** xCloud creates the migration setup for a temporary destination and shows the settings and plugin steps.

## Step 5: Configure the destination settings

In the xCloud migration wizard, choose the required PHP version, database prefix, site user, and other displayed settings. Match the source PHP version initially unless you have already confirmed that the application supports a different version.

Continue to the plugin step only after checking the destination settings against your source inventory.

**Expected result:** The xCloud destination configuration matches the source application's current runtime requirements.

## Step 6: Install the xCloud migration plugin on Rocket.net

From the xCloud plugin step, download the migration plugin and copy the authentication token. In the Rocket.net WordPress dashboard, open **Plugins → Add New Plugin → Upload Plugin**, upload the downloaded file, install it, and activate it.

Paste the xCloud token into the plugin on the source site. Return to xCloud, confirm that the token has been added, and continue.

Treat the token as a credential. Do not paste it into tickets, screenshots, chat messages, or this guide.

**Expected result:** xCloud confirms that the source plugin and token are connected.

## Step 7: Choose the migration scope and start the copy

In the xCloud **Database** step, choose the full file and database migration unless you have a verified reason to exclude database tables or transfer only files. Start the migration and leave the Rocket.net site online for the initial copy.

Do not change themes, plugins, URLs, or database content while the copy runs. If the migration reports an error, preserve the source and use the troubleshooting table below before starting repeated transfers.

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

## Step 8: Validate the xCloud demo site

Open the xCloud demo URL and compare it with the Rocket.net site. Check the home page, representative posts and pages, search, menus, media, forms, login, WordPress admin, redirects, scheduled tasks, transactional email, and any commerce or membership workflow.

Use safe test transactions and test addresses. Confirm that the destination is not sending duplicate production email or processing production background jobs during validation.

**Expected result:** The demo site matches the source, and every business-critical path has a recorded pass or a resolved discrepancy.

## Step 9: Create an xCloud backup before cutover

Configure the supported xCloud site-backup storage, then create and verify a destination backup after validation. Keep the Rocket.net restore point as a separate rollback layer.

Do not proceed until you can identify both the Rocket.net source restore point and the xCloud destination backup.

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

## Step 10: Perform the final sync under a write freeze

Schedule a low-traffic cutover window. Put the Rocket.net site into an appropriate maintenance or read-only state, pause source cron jobs and background processing where the application allows it, and stop test processing on xCloud.

Capture all changes made since the first copy. The public xCloud migration guide does not describe an incremental merge that safely combines concurrent writes. For a stateful site, ask xCloud support whether to rerun the supported migration or use an assisted final copy. Do not run two writable copies and assume orders, form submissions, memberships, comments, or uploads will merge.

**Expected result:** The source and temporary destination are not accepting conflicting writes, and the final xCloud data matches the source at the agreed cutover point.

## Step 11: Point the production domain to xCloud

In the xCloud site dashboard, open **Domain → Go Live**, enter the production domain, and follow the displayed DNS instructions. Change only the web records identified by xCloud. Preserve unrelated mail, verification, and service records.

Prepare DNS in advance by lowering the relevant record's TTL at least one existing-TTL interval before the cutover. After changing DNS, verify the authoritative response before relying on a local browser cache.

**Expected result:** The authoritative production hostname resolves to the xCloud destination while non-web DNS records remain intact.

## Step 12: Enable HTTPS and complete production checks

After the domain resolves to xCloud, open the site's **SSL/HTTPS** area and enable HTTPS with the supported certificate method. Confirm that the certificate covers every required hostname and that HTTP redirects to HTTPS without a loop.

Repeat the demo-site checks against the production domain. Verify recent content, forms, checkout or membership actions, email, scheduled tasks, redirects, cache behavior, logs, and WordPress admin access. Re-enable destination cron jobs and background processing only after production traffic reaches xCloud. Restore any source security setting changed for migration, but keep the source read-only during the rollback window.

**Expected result:** The production domain serves the xCloud copy over a valid HTTPS connection, and only xCloud processes new writes and background work.

## Verification checklist

The migration is complete only when all of these checks pass:
- The production hostname resolves to the xCloud destination.
- HTTPS is valid for the apex domain and every required subdomain.
- The latest expected posts, users, orders, submissions, comments, memberships, and uploads are present.
- WordPress admin login works for an approved administrator.
- Forms, transactional email, search, redirects, scheduled tasks, webhooks, and external integrations work.
- No source and destination worker or cron pair is processing the same task.
- An xCloud destination backup and a Rocket.net source restore point are both available.
- Monitoring and logs show no new recurring application, PHP, database, or certificate errors.

## Troubleshooting

| Symptom | Likely cause | Fix |
|---|---|---|
| xCloud cannot validate the migration token | A cache, WordPress security plugin, two-factor check, or Rocket.net edge rule blocks the request. | Clear caches, verify the token, and follow xCloud's failure-only security checks. Ask Rocket.net support for the supported allowlist or migration path before changing managed edge protection. |
| The migration stops or times out | The site is large, a plugin blocks long requests, or the transfer was interrupted. | Keep the source unchanged, review the migration error, and retry only after correcting the reported cause. Use Migrate Guru or request assisted migration if the token path continues to fail. |
| The demo site redirects to Rocket.net | The database or a plugin still contains the production URL, or a platform redirect was recreated incorrectly. | Recheck the destination URL handling, WordPress home and site URLs, and recorded redirects. Do not change production DNS until the demo URL stays on xCloud. |
| Images or downloads are missing | Media is external, excluded, or stored outside the copied WordPress paths. | Compare the source inventory with the destination and move or reconnect the missing storage through its supported export method. |
| Forms work but email does not arrive | The destination mail path, sender authentication, or DNS record is incomplete. | Configure the approved transactional mail service and preserve or update the required SPF, DKIM, and DMARC records before enabling production sends. |
| HTTPS cannot be issued | DNS has not reached xCloud, an old AAAA record still points elsewhere, or a proxy blocks validation. | Verify authoritative A, AAAA, and CNAME responses, remove only conflicting web records, then retry certificate issuance. |
| Content differs after cutover | Writes continued on Rocket.net after the final copy, or both environments processed background work. | Freeze both sides, identify the authoritative data set, capture the write delta, and ask xCloud support for a supported reconciliation or final-copy method. Do not overwrite newer data blindly. |

## Common mistakes
- **Using full-server migration for Rocket.net.** A managed WordPress account is a site-level migration source, not a root-controlled server that meets xCloud's full-server prerequisites.
- **Changing DNS before validating the demo site.** This moves real traffic onto an unverified copy and reduces the time available to fix missing data.
- **Treating a Rocket.net backup as a portable export.** A restore point protects the source, but it is not automatically an offline migration package.
- **Disabling protection without a rollback plan.** Try the normal security posture first, change only the control that blocks the migration, and restore it immediately after the copy.
- **Running both copies as writable production sites.** Concurrent orders, submissions, uploads, scheduled tasks, or webhooks can create split-brain data.
- **Replacing the whole DNS zone.** Change only the web records identified by xCloud. Preserve mail and verification records.
- **Cancelling Rocket.net immediately after DNS changes.** DNS caches and rollback decisions need time. Keep the source available and read-only until the agreed rollback window ends.

## Rollback guidance

If production validation fails, keep both environments read-only while you decide which data set is authoritative. Capture any writes that reached xCloud after cutover. If those writes cannot be merged safely, document whether they will be reconciled manually or discarded with explicit approval.

Restore the previous web DNS records, verify that production traffic has drained from xCloud, and only then reopen writes and background processing on Rocket.net. Do not resume source processing while requests are still reaching both platforms. Keep the xCloud backup and logs for diagnosis.

## Frequently asked questions

### Can I use xCloud Full Server Migration from Rocket.net?

No. Rocket.net is managed WordPress hosting, so use a site-level WordPress migration. xCloud Full Server Migration is for a compatible source server with the required operating system, web stack, root SSH access, and port configuration.

### Should I point DNS to xCloud before the migration?

No. Create and validate an xCloud demo site first. Change production DNS only after the files, database, forms, integrations, background work, and recovery checkpoints are ready.

### Does the first plugin copy include writes made later on Rocket.net?

Do not assume it does. The public xCloud guide does not document a conflict-aware incremental merge. Use a short write freeze and confirm the supported final-copy method for a stateful site.

### When can I cancel Rocket.net?

Cancel only after the production domain consistently serves xCloud, HTTPS and application checks pass, the rollback window has ended, and you no longer need Rocket.net backups or source data.

## Related xCloud documentation
- [Migrate an existing WordPress website in xCloud](/docs/migrate-an-existing-wordpress-website-in-xcloud/), the plugin-and-token flow this guide uses
- [Migrate a website with Migrate Guru](/docs/migrate-a-website-with-migrate-guru-plugin/), the fallback
- [Migrate from Kinsta](/docs/migrate-from-kinsta-to-xcloud/) and [from WP Engine](/docs/migrate-from-wp-engine-to-xcloud/), the same site-level path from other managed WordPress hosts
- [Go live from an xCloud demo site](/docs/how-to-go-live-from-demo-site/)
- [Enable HTTPS and configure SSL certificates](/docs/enable-https-in-xcloud-configure-ssl-certificates/)
- [Site backups in xCloud](/docs/site-backups-in-xcloud/)
- [xCloud vs Rocket.net](/xcloud-vs-rocket-net/) if you are still comparing the two

If you run into any issues during the migration, feel free to reach out to our [support team](/docs/access-built-in-support-portal-in-xcloud/).