# How to Migrate a Full Server from ServerAvatar to xCloud

> Move every WordPress site on a ServerAvatar NGINX or OpenLiteSpeed server to xCloud in one run with root SSH: eligibility, backups, demo copies, validation, write freeze, DNS cutover, rollback.

If you are still deciding, see [xCloud vs ServerAvatar](/xcloud-vs-serveravatar/) first, and if you would rather have it done for you, the xCloud team migrates sites for free: see [free website migration](/website-migration/). This guide shows you how to move every compatible WordPress site from a ServerAvatar-managed server to a fresh xCloud server with xCloud Full Server Migration. Use it only when the source runs NGINX or OpenLiteSpeed on Ubuntu 20.04 or 24.04 LTS x64 and permits root SSH on port 22. The migration copies selected WordPress files and databases. It does not clone ServerAvatar, the operating system, Node.js applications, server-wide services, firewall rules, backup schedules, or panel settings.

## Choose the correct migration method

**A ServerAvatar server is not automatically eligible for xCloud Full Server Migration.** ServerAvatar can provision Apache, NGINX, or OpenLiteSpeed on Ubuntu 20.04, 22.04, or 24.04. xCloud's current full-server workflow accepts a narrower combination.

| Source condition | Correct xCloud path |
|---|---|
| NGINX or OpenLiteSpeed, Ubuntu 20.04 or 24.04 LTS x64, root SSH on port 22, WordPress sites | Follow this full-server guide. |
| Apache, Ubuntu 22.04, another operating system, no root access, or SSH on another port | Use [site-by-site WordPress migration](/docs/migrate-an-existing-wordpress-website-in-xcloud/) or ask [xCloud migration support](/docs/request-for-site-migration-support-from-xcloud/) to confirm a supported route. |
| Node.js or another non-WordPress application | Rebuild it with the appropriate xCloud Git or Docker workflow. Full Server Migration discovers WordPress sites only. |
| You need to move one WordPress site | Use xCloud's site-by-site migration instead of moving the whole server. |

## Prerequisites

Before you start, confirm every item in this checklist:
- Administrator access to xCloud, ServerAvatar, and the cloud or VPS account that owns the source server.
- A source server running **NGINX or OpenLiteSpeed** on **Ubuntu 20.04 or 24.04 LTS x64**.
- Root SSH access by password or public key on **port 22**.
- Firewall rules that allow xCloud to reach root SSH on port 22 during the migration.
- A **fresh xCloud destination server** with no existing sites.
- At least **1 GB of destination storage beyond the combined size of the sites** you will move.
- A verified backup of every source application and database, stored away from the source server.
- An inventory of all domains, aliases, databases, PHP versions and extensions, cron jobs, redirects, caching, email delivery, external storage, and DNS records.
- Access to the authoritative DNS provider for every production domain.
- A maintenance window and an approved write-freeze plan for stores, memberships, comments, form submissions, or any other changing data.
- A rollback owner who can restore the old DNS records and source processing if validation fails.

## Step 1: Confirm that the source server is eligible

Check the source operating system, architecture, web stack, and SSH access before provisioning the destination. From a trusted terminal, connect on the port xCloud requires:

```bash
ssh -p 22 root@SOURCE_SERVER_IP
```

After you connect, confirm the account and platform:

```bash
id -u
. /etc/os-release && printf '%s\n' "$PRETTY_NAME"
uname -m
```

`id -u` must return `0`. The operating system must be Ubuntu 20.04 or 24.04 LTS, and the architecture must be x86-64. Confirm in ServerAvatar or on the source server that the active web stack is NGINX or OpenLiteSpeed.

If ServerAvatar has disabled root login or password authentication, review its [Security Settings](https://serveravatar.com/docs/server/security-settings/) and temporarily enable only the access method required for the migration. Do not continue with an Apache source, Ubuntu 22.04, a non-x64 server, a nonstandard SSH port, or an application-level SSH account.

**Expected result:** You have verified an eligible stack and can open a root SSH session on port 22.

## Step 2: Inventory everything that must be recreated

Record each WordPress site's primary domain, aliases, document root, database, PHP version, PHP extensions, redirects, cron jobs, caching, SMTP or transactional email service, object storage, and external integrations. Also record ServerAvatar-managed items that the xCloud migration does not promise to copy, including application users, SSH keys, firewall rules, monitoring, notification channels, backup schedules, and Cloudflare integration settings.

ServerAvatar's native [Site Migration](https://serveravatar.com/docs/server/site-migration/) moves sites between ServerAvatar-managed servers. It does not document an outbound full-server export to xCloud, so use your inventory as the rebuild checklist.

**Expected result:** Every source site and every server-level dependency has an owner and a destination action.

## Step 3: Create and verify ServerAvatar backups

In ServerAvatar, open **Backups → Instant Backup → Create**. Create an **Application** backup for each WordPress application so the backup includes its files and database. Select a configured storage provider, retention period, file format, and database format, then start the backup.

Open **Instant Backup → Backups** and wait until every backup reports completion. Use the available download or restore action to confirm that the backup can be retrieved. ServerAvatar documents application backups as files plus a database, not as complete machine images, so retain a separate inventory of server settings.

Follow [ServerAvatar's Instant Backup instructions](https://serveravatar.com/docs/backups/instant-backup/) if you need the exact source-panel fields.

**Expected result:** Every site has a completed, retrievable backup stored outside the source server.

## Step 4: Prepare the source WordPress sites

Clear application and object caches. Temporarily disable cache and security plugins that can block copying, including Wordfence when installed. Disable WordPress two-factor authentication if it blocks the migration, and remove only source-host-specific must-use plugins that you have identified and backed up.

Do not delete generic must-use plugins or production configuration without understanding their role. Record every temporary change so you can restore it if the migration is cancelled.

**Expected result:** The source sites remain healthy, but host-specific caching and security controls no longer obstruct the copy.

## Step 5: Provision a fresh xCloud destination server

Create a new xCloud server that meets the sites' capacity and regional requirements. Do not place existing sites on it. In **Server Overview → Disk Usage**, confirm at least 1 GB of free space beyond the total size of the selected sites.

Keep production DNS pointed to the ServerAvatar source. Lower each relevant record's TTL at least one existing-TTL interval before the cutover, then confirm the authoritative DNS response shows the lower value.

**Expected result:** The destination is empty, has sufficient storage, and is ready for a staged migration without changing production traffic.

## Step 6: Enter the ServerAvatar source connection in xCloud

Open the fresh destination server in xCloud, then choose **New Site → Migrate Full Server**. Enter the source server's IP address, port `22`, and SSH username `root`.

Choose the authentication method:
- **Password:** enter the source root password.
- **Public key:** copy the public key displayed by xCloud and add it to the root account's `authorized_keys` on the source server.

Click **Next** only after root SSH works from outside the source network. Follow xCloud's [full-server migration guide](/docs/perform-a-full-server-migration-with-xcloud/) for the current connection fields.

**Expected result:** xCloud connects to the ServerAvatar source and lists the WordPress sites it discovers.

## Step 7: Select the WordPress sites to copy

Compare xCloud's discovered-site list with your inventory. Select the sites you intend to move, then click **Next**.

If a site is missing, stop before cutover. Confirm that it is a WordPress installation on this server and that root can read both its files and database. Move non-WordPress applications through their own deployment workflow.

**Expected result:** Every intended WordPress site appears once in the selection, with no unrelated application selected.

## Step 8: Start with demo sites

Choose **Demo Site** for the first migration so each selected site lands on an xCloud demo domain. Start the migration and wait for xCloud to finish copying files and importing databases.

Do not assume the demo copy receives later source changes. xCloud's generic guide does not document an incremental merge or final-delta synchronization. For a stateful site, keep the demo-validation window short and agree on a supported final recopy with xCloud support before you freeze writes.

**Expected result:** Each selected WordPress site is available on an xCloud demo domain while production still runs on the ServerAvatar source.

## Step 9: Recreate destination-only configuration and validate

Use your inventory to recreate items that are not part of the documented files-and-database copy: PHP settings and extensions, server cron jobs, redirects, SMTP or transactional email, external storage mounts, application users, SSH keys, monitoring, backup schedules, and security rules.

Test each demo site as a visitor and an administrator. Verify:
- home page, representative posts, search, media, and downloads;
- WordPress administration and user roles;
- forms, checkout, login, memberships, comments, and other writes;
- plugins, themes, redirects, permalinks, and cache behavior;
- database record counts or other application-specific totals;
- scheduled tasks, queues, outgoing email, webhooks, and third-party APIs;
- all primary domains and aliases in the planned DNS change set.

Keep destination cron jobs and write-producing workers paused after testing so they cannot create a second source of truth before cutover.

**Expected result:** The demo sites pass the recorded acceptance checks, and every non-migrated dependency has been recreated or explicitly deferred.

## Step 10: Create a destination backup

Before the production cutover, create and verify an xCloud backup for every migrated site. In the site dashboard, open **Backup → Previous Backups**, create a local or remote backup, and confirm it appears successfully.

Use [Site Backups in xCloud](/docs/site-backups-in-xcloud/) for the current backup controls.

**Expected result:** You have a recoverable xCloud checkpoint from the validated destination state.

## Step 11: Freeze writes and synchronize the final production state

At the agreed maintenance window, place the source sites in maintenance or read-only mode. Pause source cron jobs, queues, checkout, form submissions, and other write-producing processes. Keep destination workers and schedules paused too.

If the demo copy is now stale, use the final-recopy method confirmed by xCloud support. Do not improvise a database merge or assume rerunning the migration safely combines changes. Validate record counts, recent orders or submissions, uploads, and timestamps before changing DNS.

**Expected result:** One validated dataset is authoritative, and neither environment is accepting new writes during the cutover.

## Step 12: Switch DNS and verify HTTPS

Update the authoritative DNS records for each primary domain and alias to the xCloud destination. Follow [xCloud's DNS record guide](/docs/how-to-setup-dns-record-in-xcloud-server/) or its [Cloudflare DNS guide](/docs/using-xcloud-with-cloudflare-for-dns-management/) when Cloudflare is authoritative.

Wait for authoritative DNS to return the new destination before judging the cutover. xCloud provisions SSL after DNS resolves. If HTTPS does not become active, follow [Enable HTTPS and configure SSL certificates](/docs/enable-https-in-xcloud-configure-ssl-certificates/).

Test the public domain from more than one network. Check HTTPS, redirects, canonical URLs, forms, checkout, administration, email, scheduled tasks, and logs. Enable destination workers and cron jobs only after traffic reaches xCloud and the final data checks pass.

**Expected result:** Production domains resolve to xCloud, valid HTTPS loads, and one destination processes writes and scheduled work.

## Step 13: Secure the source access and retain the rollback window

Keep the ServerAvatar source intact and read-only until the rollback window closes. Remove the xCloud migration public key from the source root account when it is no longer needed. Restore the prior root-login and password-authentication policy in ServerAvatar, then re-enable any source controls that must remain active during retention.

Do not cancel the source server, delete backups, or raise DNS TTLs until the application owner signs off on production behavior and data integrity.

**Expected result:** Temporary migration access is revoked, but the source and its backups remain available for an agreed rollback period.

## Verify the migration

The migration is complete only when all of these checks pass:
- Authoritative DNS returns the xCloud destination for every production domain and alias.
- HTTPS is valid and no browser warning appears.
- Public pages, WordPress administration, media, forms, checkout, login, email, webhooks, and redirects work.
- Record counts and the latest stateful transactions match the approved final source state.
- Only xCloud runs production cron jobs, queues, and other write-producing processes.
- xCloud backups complete and can be located for restore.
- Monitoring and logs show no unexplained application, PHP, database, or certificate errors.
- The temporary root password or xCloud public key no longer grants migration access.
- The source remains retained, read-only, and recoverable until sign-off.

## Troubleshooting

| Symptom | Likely cause | Fix |
|---|---|---|
| xCloud cannot connect to the source | Root login is disabled, SSH is not on port 22, a firewall blocks access, password authentication is disabled, or the xCloud key was not added correctly. | Confirm root SSH on port 22, review ServerAvatar Security Settings and the cloud firewall, then verify the same authentication method before retrying. |
| xCloud connects but finds no sites | The source stack or operating system is ineligible, the application is not WordPress, or root cannot read the site's files or database. | Recheck the eligibility table and source permissions. Use site-by-site migration or an application-specific deployment for an ineligible workload. |
| A discovered site is missing recent data | The source accepted writes after the copy. | Freeze both sides. Keep the authoritative source unchanged and use the final-recopy method confirmed by xCloud support. Do not merge databases manually without an application-specific plan. |
| The demo site shows PHP errors or a blank page | The PHP version, extensions, filesystem permissions, or web-server behavior differs from the source. | Match the required PHP version and extensions, inspect xCloud logs, correct permissions or configuration, and retest before DNS cutover. |
| Forms or outgoing email fail | SMTP credentials, DNS records, or an external email service was not recreated. | Reconfigure the site's mail provider, verify required DNS records, and send a test message before launch. |
| HTTPS is pending or invalid | DNS still resolves to the source, a proxy serves an old route, or certificate issuance has not completed. | Verify authoritative DNS first, confirm the proxy target, then use xCloud's SSL guide. Do not remove the source until HTTPS works publicly. |
| Scheduled tasks run twice | Cron jobs or workers are active on both servers. | Pause both sides during final synchronization, then enable only xCloud after traffic and data validation pass. |
| Some visitors still reach ServerAvatar after cutover | DNS caches have not expired. | Keep the source read-only and healthy, monitor both environments, and wait for the previous TTL window to pass before resuming writes on only one side. |

## Common mistakes
- **Assuming every ServerAvatar server is eligible.** ServerAvatar supports Apache and Ubuntu 22.04, but xCloud's current full-server flow does not.
- **Using an application user instead of root.** Application-level SSH may not expose every site's files, databases, and server configuration required for discovery.
- **Treating “full server” as a machine clone.** The documented xCloud workflow migrates selected WordPress files and databases, not ServerAvatar or the complete operating-system state.
- **Moving Node.js or other non-WordPress workloads through this flow.** These applications need an xCloud Git or Docker deployment plan.
- **Treating a ServerAvatar application backup as a server image.** It protects application files and a database, but not all panel and operating-system settings.
- **Changing DNS before demo validation.** This turns a reversible copy into a production incident.
- **Allowing writes on both environments.** Two writable copies create split-brain data that DNS rollback cannot repair automatically.
- **Deleting the source too soon.** Retain the source and verified backups until DNS, HTTPS, application behavior, and data have all been approved.

## Rollback guidance

If production validation fails, put both environments in maintenance or read-only mode. Pause cron jobs, queues, and workers on both sides. Capture any writes that reached xCloud after cutover, choose which data store is authoritative, and reconcile or explicitly discard the destination-only changes before resuming service.

Restore the previous authoritative DNS records and wait until xCloud traffic drains. Verify that the ServerAvatar source still serves valid HTTPS and the approved dataset, then resume source writes and source-only processing. Keep xCloud read-only for investigation. Restore a ServerAvatar backup only if the source itself was changed or damaged.

DNS rollback does not reverse orders, comments, form submissions, or other writes already accepted by xCloud. If you cannot reconcile that delta, keep the site read-only and escalate rather than risking silent data loss.

## Frequently asked questions

### Can I use this guide for a ServerAvatar Apache server?

No. xCloud's current generic full-server migration supports NGINX and OpenLiteSpeed sources. Use site-by-site WordPress migration or ask xCloud support for a confirmed route.

### Can I migrate a ServerAvatar server running Ubuntu 22.04?

Not with the current generic full-server workflow. xCloud documents Ubuntu 20.04 and 24.04 LTS x64 as supported source operating systems.

### Does xCloud copy ServerAvatar users, firewall rules, backups, and monitoring?

No documented source says it does. Treat the workflow as a bulk WordPress files-and-database migration and recreate server-level controls from your inventory.

### Can I migrate without root access?

Not with this workflow. Use xCloud's site-by-site WordPress migration when you cannot provide root SSH on port 22.

### Does this migration guarantee zero downtime?

No. Stateful sites need a write freeze and a controlled final synchronization. DNS caching also means some visitors may reach the old server during cutover.

### Can I migrate Node.js applications from the same ServerAvatar server?

Not through Full Server Migration. Rebuild each non-WordPress application through the appropriate xCloud Git or Docker workflow, including its environment variables, databases, persistent files, workers, cron jobs, and domains.

## Related xCloud documentation
- [Full server migration to xCloud from any host](/docs/perform-a-full-server-migration-with-xcloud/) (the generic root-SSH flow this guide uses)
- [Migrate an existing WordPress website in xCloud](/docs/migrate-an-existing-wordpress-website-in-xcloud/) (site by site, no root needed)
- [Request site migration support from xCloud](/docs/request-for-site-migration-support-from-xcloud/)
- [Site backups in xCloud](/docs/site-backups-in-xcloud/)
- [Set up DNS records for an xCloud server](/docs/how-to-setup-dns-record-in-xcloud-server/) and [use xCloud with Cloudflare for DNS](/docs/using-xcloud-with-cloudflare-for-dns-management/)
- [Enable HTTPS and configure SSL certificates](/docs/enable-https-in-xcloud-configure-ssl-certificates/)
- [Migrate from RunCloud](/docs/migrate-from-runcloud-to-xcloud-full-server-migration/), [SpinupWP](/docs/migrate-from-spinupwp-to-xcloud-full-server-migration/) and [Ploi](/docs/migrate-from-ploi-to-xcloud-full-server-migration/), the same flow for other panels
- [xCloud vs ServerAvatar](/xcloud-vs-serveravatar/) if you are still comparing the two
- [Free website migration to xCloud](/website-migration/): every method, and how to have the xCloud team do it

If you run into any issues migrating from ServerAvatar, feel free to reach out to our [support team](/docs/access-built-in-support-portal-in-xcloud/) for help.