Book a demo
Book a demo
Login

How to Migrate a Full Server from SpinupWP to xCloud

Updated September 25, 2026 · 14 min read

If you are still deciding, see xCloud vs SpinupWP first. This guide shows you how to move multiple WordPress sites from one eligible SpinupWP-managed server to a fresh xCloud server. It is for server owners who control the underlying VPS and can provide direct root SSH access on port 22.A standard SpinupWP sudo user is not sufficient for xCloud’s current full-server migration. If direct root SSH is unavailable, use xCloud’s site-level WordPress migration instead.

This process copies the selected WordPress sites before you change production DNS. It does not guarantee zero downtime. Plan a short write freeze for the final copy or reconciliation, keep the SpinupWP server available during the rollback window, and do not cancel the source server until the xCloud sites are accepted.

Is full server migration the right method?

Use full-server migration only when every item in the Eligible column is true.

Check Eligible for this guide Use a site-level migration instead
Workload Multiple WordPress sites on one SpinupWP-managed server One WordPress site or a non-WordPress application
Source stack NGINX A stack outside xCloud’s current prerequisites
Operating system Ubuntu 20.04 or Ubuntu 24.04 LTS on x86-64 Ubuntu 22.04, ARM/aarch64, or another operating system
SSH access Direct root login by password or public key on port 22 Only a SpinupWP sudo user, site user, or other non-root login is available
Destination A fresh server provisioned through xCloud An existing destination server that must be preserved

SpinupWP currently provisions fresh Ubuntu 24.04 x64 or ARM servers with NGINX. However, SpinupWP also disables SSH access for the root user by default and provides sudo users that authenticate with public keys. xCloud’s generic full-server workflow requires a direct root SSH session. Confirm the operating system, architecture, and root-login policy on the actual source server rather than assuming that every SpinupWP server is eligible.

If the source fails any check, migrate each site with xCloud’s WordPress migration workflow. Do not weaken the source server’s SSH policy unless the underlying cloud provider supports the change and your security policy permits it.

Prerequisites

  • Owner or administrative access to SpinupWP and the underlying cloud-provider account
  • Multiple WordPress sites on the same source server
  • Ubuntu 20.04 or Ubuntu 24.04 LTS on x86-64
  • NGINX on the source server
  • Direct root SSH access by password or public key on TCP port 22
  • Verified backups of every site’s files and database
  • A provider snapshot when available as an additional rollback point
  • A fresh destination server provisioned through xCloud
  • Destination capacity for all selected sites, with at least 1 GB free after migration
  • Access to the authoritative DNS zone for every production domain
  • A maintenance window and rollback window agreed with site owners
  • An inventory of plugins, must-use plugins, caches, cron jobs, email, and external integrations

Step 1: Inventory the SpinupWP server

Open the source server in SpinupWP and record the WordPress sites you intend to move, the public address, the SSH port, and the underlying cloud provider. Then connect with a SpinupWP sudo user and run:

cat /etc/os-release
dpkg --print-architecture
sudo nginx -v

The source passes xCloud’s published eligibility check only when it runs Ubuntu 20.04 or Ubuntu 24.04 LTS on x86-64 and uses NGINX. On Debian-based systems,dpkg --print-architecture should return amd64 for x86-64. An arm64 result is outside the current xCloud full-server prerequisites.

Expected result: You have a complete site inventory, and the source operating system, architecture, and web server match xCloud’s requirements.

Step 2: Create and verify backups

For every selected site, open SpinupWP → Site → Backups and create an on-demand backup of the database and files. SpinupWP labels this action Backup Database & Files Now. Wait until each backup appears in the backup listing with the expected file and database sizes.

SpinupWP documents site backups as complete copies of site files and the database. It does not provide full-server snapshots itself. If you need a server-level rollback point, create and verify a snapshot in the underlying cloud provider as an additional safeguard. A provider snapshot does not replace portable site and database backups.

Expected result: Every selected site has a recent completed backup, and you know how to restore it before continuing.

Step 3: Confirm direct root SSH access

SpinupWP disables root SSH access on managed servers by default. Its sudo users have system-wide privileges, but xCloud’s current full-server migration asks for the SSH username root and does not document sudo-user escalation as an alternative.

Use the underlying cloud provider’s supported access or recovery controls to determine whether direct root SSH can be enabled for the migration window. Then test the same path that xCloud will use:

ssh -p 22 root@203.0.113.10

Replace 203.0.113.10 with the source server’s public address when you run the command. Do not put the root password, a private key, or the real server address in a document, screenshot, or support message.

If the root session does not open, stop. A SpinupWP sudo user or site user does not satisfy this workflow. Use the site-level WordPress migration path unless xCloud documents another supported authentication method for SpinupWP.

Expected result: A direct root SSH session reaches the source on port 22 using the authentication method you will select in xCloud.

Step 4: Prepare the WordPress sites

Schedule this work immediately before migration so protection is not disabled longer than necessary. Following xCloud’s current full-server prerequisites:

  1. Record the active plugins, themes, must-use plugins, caching layers, cron jobs, and external integrations for each site.
  2. Clear page, object, and application caches.
  3. Temporarily disable cache or security plugins that can block the copy.
  4. Remove only source-specific must-use plugins that should not move to xCloud, after confirming they are covered by the backup.
  5. Record every temporary change so you can restore it during rollback.

Do not disable provider firewalls, SSH restrictions, or application security earlier than required. Keep the migration window short and limit temporary access to the smallest scope your cloud provider supports.

Expected result: The selected sites are backed up, their temporary changes are recorded, and migration-blocking cache or security layers are inactive.

Step 5: Provision a fresh destination server in xCloud

Create a new server through xCloud for the migration. Do not choose an existing xCloud server that already hosts sites because the current full-server workflow requires a fresh destination.

Size the server for the combined files and databases, expected growth, and at least 1 GB of free storage after the copy. Wait until xCloud marks the destination server as active.

Expected result: A fresh xCloud destination server is active and has sufficient storage.

Step 6: Open the full-server migration flow

In xCloud, open the fresh destination server, choose New Site, and then select Migrate Full Server. This opens the source-server connection form described in How to migrate a full server to xCloud from any host.

Expected result: xCloud displays fields for the source address, SSH port, username, and authentication method.

Step 7: Connect xCloud to the SpinupWP server

Enter the source server’s public address, port 22, and username root. Choose one authentication method:

  • Password: Enter the current root password.
  • Public key: Copy the public key shown by xCloud and add it to the root account’s authorized_keys through an existing root session or the cloud provider’s supported recovery workflow.

Continue only after xCloud accepts the connection. Never add a private key to xCloud, and never copy a root password into a ticket or documentation.

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

Step 8: Select the WordPress sites

Compare the discovered sites with the inventory from Step 1. Select only the sites approved for this migration, then click Next.

If an expected site is missing, stop. Confirm that it is a WordPress installation on this server and that its files and database are readable by root. Do not continue with an incomplete site list.

Expected result: The selection matches the approved SpinupWP site inventory exactly.

Step 9: Create demo sites first

Choose Demo Site for the first migration rather than sending the sites live immediately. Start the migration and monitor it until xCloud reports completion.

Keep the SpinupWP server online while xCloud copies files and databases. Do not change production DNS during this stage.

Expected result: xCloud creates non-production copies of the selected sites on demo domains for validation.

Step 10: Validate every migrated site

Test each demo site as a visitor and as a WordPress administrator. Check:

  • the homepage, key landing pages, forms, redirects, and media files;
  • administrator login and a safe non-production content edit;
  • recent posts, users, comments, orders, subscriptions, or other business data;
  • plugin and theme behavior;
  • scheduled actions and cron-dependent features;
  • transactional email through the intended provider;
  • external APIs, webhooks, payment sandboxes, search, and object storage;
  • PHP compatibility, caching behavior, and application logs;
  • the final production domain and HTTPS plan.

Compare a small set of business-critical records between SpinupWP and xCloud. A working homepage does not prove that the database, uploads, email, or scheduled work migrated correctly.

Expected result: Site owners approve the demo copies, and every discrepancy is resolved or documented before cutover.

Step 11: Plan the final synchronization and write freeze

Lower each production DNS record’s TTL at least one existing-TTL interval before cutover. Record the current DNS values, then confirm that the authoritative DNS response shows the lower TTL.

xCloud’s public full-server guide does not document an incremental final-sync or database-merge procedure. For stores, membership sites, forms, forums, or any site that accepts writes, arrange a supported final-copy or reconciliation plan with xCloud support before the maintenance window. Do not assume that rerunning the migration will merge changes safely.

Immediately before the approved final copy or cutover:

  1. Put the source sites into maintenance or read-only mode.
  2. Pause source cron jobs, queue workers, imports, webhooks, and other writers.
  3. Keep the xCloud copies read-only and pause equivalent destination processing.
  4. Complete the supported final copy or reconciliation.
  5. Recheck critical record counts, uploads, and recent data.

Expected result: No uncontrolled writes can create divergent source and destination data during cutover.

Step 12: Switch DNS and verify HTTPS

Update the authoritative DNS records to the xCloud destination values. Follow How to set up DNS records for an xCloud server for the xCloud side of the change.

Wait until authoritative DNS returns the new values, then open every production domain over HTTPS. If certificate issuance does not complete, follow How to enable HTTPS and configure SSL certificates in xCloud.

Test the frontend, WordPress administration, forms, uploads, redirects, email, scheduled work, integrations, and logs again through the production domains. Enable destination cron jobs and workers only after xCloud is authoritative and the final data check passes.

Expected result: Production traffic reaches xCloud, HTTPS is valid, and data and background processing behave as expected.

Step 13: Close the migration window safely

Keep the SpinupWP server intact and read-only during the rollback window. Re-enable only the caching and security controls appropriate for the new xCloud environment.

Remove the temporary xCloud public key from the source root account, return the source SSH policy to its prior secure state, and close any temporary firewall access. Do not cancel the source server or delete its backups until site owners accept the xCloud deployment and the rollback window expires.

Expected result: The xCloud sites remain stable, temporary root access is revoked, and a usable rollback point remains.

Verify the migration

The migration is complete when all of the following are true:

  • Authoritative DNS resolves every production domain to xCloud.
  • HTTPS loads without certificate or mixed-content errors.
  • Frontend pages, WordPress administration, forms, uploads, and redirects work.
  • Recent business-critical records match the approved final source state.
  • Destination cron jobs and workers run once, in the intended timezone and context.
  • Application, PHP, and web-server logs show no unresolved migration errors.
  • Site owners approve the production result.
  • The SpinupWP source remains available and unchanged for the agreed rollback window.

Troubleshooting

Symptom Likely cause Fix
xCloud cannot connect to the source SpinupWP’s default root-login restriction is still active, port 22 is blocked, or the authentication method is wrong Test a direct root SSH session on port 22. If only a sudo user works, stop and use site-level migration
The server is Ubuntu 22.04 or ARM The SpinupWP server is valid for SpinupWP but outside xCloud’s current full-server prerequisites Use site-level WordPress migration unless xCloud confirms support for that exact source configuration
The source connects but no sites appear The sites are not readable by root, are not WordPress installations, or discovery does not support the layout Confirm the workload and file/database access. Use site-level migration when full-server discovery is unsuitable
Migration stops because of storage The fresh xCloud server lacks space for files, databases, and temporary copy data Increase destination storage or reduce the selected set, then preserve at least 1 GB free after migration
Demo content is stale New writes occurred on SpinupWP after the copy Keep both sides read-only and use the approved final-copy or reconciliation plan
Production still reaches SpinupWP Authoritative DNS was not changed or cached records have not expired Verify the authoritative record and TTL. Keep SpinupWP online while traffic drains
HTTPS fails after cutover DNS does not fully point to xCloud or certificate issuance is incomplete Confirm authoritative DNS first, complete the xCloud SSL workflow, and retest
Scheduled work runs twice Cron jobs or workers are active on both platforms Pause both sides during final sync, then enable processing only on the authoritative xCloud destination

Common mistakes

  • Treating a SpinupWP sudo user as root SSH. Sudo privileges do not satisfy xCloud’s documented requirement for the SSH username root.
  • Assuming every SpinupWP server is eligible. SpinupWP supports ARM servers, while xCloud’s current full-server guide lists x86-64 only.
  • Confusing full-server migration with a complete VPS clone. This workflow discovers and copies WordPress sites, not every daemon, package, mailbox, or non-WordPress application.
  • Skipping backup verification. A configured backup schedule is not enough. Confirm a recent file-and-database backup and its restore path.
  • Going live before demo validation. Test application behavior, data, uploads, integrations, logs, and HTTPS before DNS cutover.
  • Assuming the first copy includes later writes. Stateful sites need a write freeze and an approved final-copy or reconciliation plan.
  • Running cron jobs on both platforms. Duplicate email, imports, queues, and scheduled actions can corrupt state or repeat customer-facing work.
  • Deleting the source too early. Keep SpinupWP available until traffic drains, validation passes, and the rollback window ends.

Roll back to SpinupWP

Rollback is a controlled cutover, not only a DNS change.

  1. Put the xCloud and SpinupWP sites into maintenance or read-only mode.
  2. Pause cron jobs, queue workers, imports, and webhooks on both platforms.
  3. Identify any writes accepted by xCloud after cutover.
  4. Choose the authoritative data store and reconcile the xCloud write delta back to SpinupWP when a supported reverse-sync method exists. If none exists, document the data-loss risk before proceeding.
  5. Restore the previous authoritative DNS values.
  6. Wait until production traffic drains from xCloud and reaches SpinupWP again.
  7. Verify HTTPS, recent data, forms, email, scheduled work, integrations, and logs on SpinupWP.
  8. Resume writes and background processing on SpinupWP only after verification.

Keep the xCloud destination unchanged until the rollback result is accepted. This preserves evidence and a second recovery point.

Frequently asked questions

Can I use a SpinupWP sudo user for xCloud full-server migration?

No. SpinupWP sudo users can run commands with elevated privileges, but xCloud’s current generic full-server migration requires a direct SSH login as root. Use site-level WordPress migration if direct root login is unavailable or prohibited.

Can I migrate a SpinupWP server on Ubuntu 22.04 or ARM?

Not under xCloud’s current published full-server prerequisites. The documented source combinations are Ubuntu 20.04 or Ubuntu 24.04 LTS on x86-64. Use site-level migration unless xCloud confirms support for your exact source.

Does this migrate every service on the server?

No. xCloud’s full-server migration discovers and moves selected WordPress sites. Inventory mail services, custom daemons, monitoring agents, non-WordPress applications, and other server-level workloads separately.

Is the migration zero downtime?

No. Demo validation reduces risk, but sites that accept writes still need a short write freeze and a supported final-copy or reconciliation plan before DNS cutover.

Should I keep SpinupWP running after cutover?

Yes, keep the source intact and read-only for an agreed rollback window. Cancel it only after DNS traffic has drained, xCloud validation passes, and site owners accept the result.

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