Book a demo
Book a demo
Login

How to Migrate a Full Server from Ploi to xCloud

Updated September 25, 2026 · 15 min read

This guide shows you how to move the WordPress sites on an eligible Ploi-managed server to a fresh xCloud server. xCloud’s full-server migration copies the files and databases for the WordPress sites you select. It does not clone every package, service, mailbox, container, or non-WordPress application on the source server.

Use this method only when the Ploi source meets xCloud’s current operating system, web-server, architecture, SSH, and port requirements. If it does not, migrate each WordPress site separately instead of forcing the full-server workflow.

Is full server migration the right method?

A Ploi server is eligible for xCloud’s generic full-server migration only when all of these conditions are true:

Requirement Eligible source What to do if it does not match
Workload WordPress sites on a Ploi webserver Move non-WordPress applications with their own Git, Docker, database, and storage procedures
Web server NGINX or OpenLiteSpeed Use site-level migration unless xCloud confirms support for the exact stack
Operating system Ubuntu 20.04 or Ubuntu 24.04 LTS Use site-level migration for other releases
Architecture x86-64 Use site-level migration for ARM or another architecture
SSH account Direct SSH access as root Use site-level migration if you can only connect as ploi and cannot authorize direct root SSH
SSH port Port 22 Restore SSH to port 22 for the migration, or use site-level migration
Destination A fresh xCloud server Do not select an xCloud server that already hosts sites

Ploi’s standard webserver type uses NGINX, but Ploi also supports load balancer, database, Docker, plain, and other server types. A Ploi-managed server is not automatically eligible just because Ploi can manage it.

Ploi’s current SSH guidance says root access is key-only and password authentication is disabled. You can normally sign in as the ploi user and elevate with sudo su, but xCloud’s full-server migration requires its own direct root SSH connection. You must therefore install the public key shown by xCloud in the root account and verify that direct root key authentication works on port 22.

Prerequisites

  • Owner or administrator access to the Ploi server and the underlying cloud-provider account.
  • Owner or administrator access to xCloud.
  • A Ploi webserver that runs NGINX or OpenLiteSpeed.
  • Ubuntu 20.04 or Ubuntu 24.04 LTS on x86-64.
  • SSH reachable on TCP port 22.
  • Permission to add a temporary xCloud public key to the root account.
  • A fresh xCloud destination server with no existing sites.
  • At least 1 GB of destination storage free beyond the combined size of the selected sites.
  • Verified backups of every site’s files and database, stored away from the source server.
  • An inventory of domains, redirects, cron jobs, queue workers, email delivery, DNS records, custom NGINX rules, and external integrations.
  • A maintenance window and rollback window approved by site owners.
  • Access to authoritative DNS for every production domain.

Step 1: Inventory everything that will not move automatically

List each WordPress site and its domain, database, storage use, PHP version, scheduled tasks, workers, mail configuration, redirects, custom NGINX rules, and external services. Record any non-WordPress applications and server-level services separately.

Do not treat this workflow as a complete VPS clone. xCloud’s full-server migration discovers and copies selected WordPress sites. Ploi server types can also contain Docker workloads, workers, databases, caches, or custom software that require separate migration plans.

Expected result: You have a site-by-site inventory and a separate plan for every service that the WordPress migration does not cover.

Step 2: Verify the Ploi server’s eligibility

Connect to the Ploi server with your normal administrative account and inspect the operating system and architecture:

cat /etc/os-release
uname -m

Continue only when the operating system is Ubuntu 20.04 or Ubuntu 24.04 LTS and uname -m reports x86_64. Confirm that the Ploi server is a webserver running NGINX or OpenLiteSpeed, not a Docker, database, load-balancer, storage, worker, or plain server with an unsupported custom stack.

Confirm that SSH still listens on port 22. Ploi allows custom SSH ports, but xCloud’s current full-server workflow requires port 22.

Expected result: The source matches every row in the eligibility table. If any requirement is uncertain, stop and use site-level WordPress migration or ask xCloud support to confirm the source configuration.

Step 3: Create and verify source backups

Create fresh backups of every selected site’s files and database. Store a copy outside the Ploi server, then verify that the backup files are readable and that you know the restore procedure.

For a stateful site, briefly use maintenance or read-only mode while taking the final pre-migration database backup. Ploi also recommends maintenance mode when restoring a database so new writes do not change the database during the operation.

Do not rely on the migration copy as your only backup. Keep the original server and its backups unchanged through the rollback window.

Expected result: Each site has a recent file backup, a recent database backup, and a documented restore path.

Step 4: Prepare the WordPress sites on Ploi

Before xCloud scans the source, clear application and server caches. Temporarily disable Wordfence and other security plugins that may block migration activity. Disable cache plugins such as Object Cache Pro, remove host-specific must-use plugins when you have confirmed they are not required after migration, and pause any extra source-side security control that blocks the connection.

Record every change so you can restore the source if you roll back. Do not remove controls that are unrelated to the migration window.

Expected result: WordPress files and databases are readable by root, and security or caching layers will not block discovery or produce stale validation results.

Step 5: Make port 22 reachable without weakening the whole server

In Ploi, open the source server and go to Network rules. Confirm that TCP port 22 is allowed. If your cloud provider also applies a security group or network firewall, confirm port 22 there as well.

Ploi manages a UFW firewall from its Network section and opens ports 22, 80, and 443 by default for a standard webserver. If you previously changed the SSH port, restore port 22 safely and update Ploi’s server metadata so the panel keeps working. Keep the existing SSH session open until a second session proves the new rule works.

Restrict SSH by source address when you have a verified allowlist for the migration connection. Do not guess an address or remove all firewall protection to make the connection succeed.

Expected result: Port 22 is reachable by the approved migration connection, while unrelated inbound traffic remains blocked.

Step 6: Provision a fresh xCloud destination server

Create a new server in xCloud for this migration. Do not use an xCloud server that already hosts sites.

Size the destination for the total storage, memory, CPU, traffic, PHP workload, database workload, and background processing you recorded. Keep at least 1 GB of disk space free beyond the total size of the sites because xCloud needs working space during the copy.

Expected result: The xCloud destination is online, contains no sites, and has enough free storage and capacity for the selected workload.

Step 7: Open the full-server migration flow

In xCloud, open the fresh destination server. Select New Site, then Migrate Full Server.

Enter the source server address, set the port to 22, and set the SSH username to root. Do not enter the ploi account. xCloud must connect directly as root for this workflow.

Because Ploi disables SSH password authentication by default, choose the public-key method when xCloud offers the authentication choice.

Expected result: xCloud displays a public key that you can authorize on the Ploi source for the root account.

Step 8: Authorize xCloud’s temporary root key

Sign in to the Ploi server through your existing administrative path. If you start as the ploi user, elevate to root with:

sudo su

Add only the public key shown on xCloud’s full-server migration screen to the root account’s authorized keys. Do not copy a private key into xCloud, Ploi, a ticket, or a document.

Return to xCloud and select Next. If xCloud cannot connect, do not enable root password authentication as a shortcut. Recheck the root authorized key, port 22, the Ploi Network rule, and any cloud-provider firewall.

Expected result: xCloud connects directly to the Ploi source as root and lists the WordPress sites it discovers.

Step 9: Select the WordPress sites to migrate

Review the discovered sites and select only the WordPress sites included in your migration plan. Compare the list with your inventory before continuing.

If a site is missing, confirm that it is a WordPress installation on this server and that root can read its files and database. Do not continue with an incomplete list unless you have a separate, approved migration method for the missing site.

Expected result: The xCloud selection matches the approved site inventory, or every excluded site has a documented alternative path.

Step 10: Create demo sites first

Choose Demo Site for the first migration. This keeps production DNS on Ploi while xCloud creates testable copies on xCloud demo domains.

Start the migration and monitor the status in xCloud. Migration time depends on the combined file and database size.

Choose Go Live only when you are ready to update DNS immediately after the copy. A demo migration is safer because it separates content validation from production cutover.

Expected result: xCloud completes the copy and provides a demo address for each selected site without changing production DNS.

Step 11: Validate every site on xCloud

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

  • homepage, representative pages, posts, archives, search, and redirects;
  • WordPress administration and user permissions;
  • images, downloads, and new media uploads;
  • forms, checkout, account login, and password-reset flows;
  • database records created shortly before the migration;
  • plugins, themes, custom code, and PHP compatibility;
  • outbound email and webhook delivery;
  • cron jobs, scheduled actions, queue workers, and their time zones;
  • third-party APIs, payment gateways, object storage, and allowlists;
  • application, PHP, database, and web-server logs;
  • custom headers, redirects, and caching behavior.

Recreate required server-level configuration on xCloud rather than assuming it copied from Ploi. Keep production workers and cron jobs disabled on xCloud during validation so both platforms do not process the same work.

Expected result: Each demo site passes the approved functional checklist, and any server-level differences have an explicit xCloud configuration.

Step 12: Prepare the final synchronization and cutover

Lower each DNS record’s TTL at least one existing-TTL interval before the cutover window. Verify the authoritative DNS response reflects the lower value before relying on it.

Identify sites that accept orders, registrations, form submissions, uploads, comments, or other writes. Schedule a short write freeze for those sites. Pause cron jobs, queue workers, imports, and webhooks on both Ploi and xCloud before the final copy or reconciliation.

xCloud’s generic full-server guide does not document an incremental merge of changes made after the initial copy. Agree on a supported final-copy or site-level synchronization method with xCloud support before the maintenance window. Do not assume that repeating a migration will merge databases safely.

Expected result: DNS is ready, both environments can be made read-only, background processing can be paused, and the team has an approved method for the final data state.

Step 13: Create a destination backup before production traffic

After the final data copy or reconciliation, create and verify a backup of the xCloud destination before you enable production workers, cron jobs, or DNS.

Keep the Ploi source read-only during this checkpoint. Compare timestamps and business-critical records with the approved final source state.

Expected result: You have a verified xCloud recovery point that matches the approved final migration state.

Step 14: Point DNS to xCloud and enable HTTPS

Update authoritative DNS to the xCloud destination by following xCloud’s DNS setup guide. Verify the authoritative response before treating the cutover as complete.

After DNS resolves to xCloud, confirm that xCloud provisions SSL for every production hostname. If certificate issuance does not complete, follow xCloud’s HTTPS and SSL guide.

Keep Ploi online and read-only while cached DNS answers expire. Do not cancel the source server during propagation.

Expected result: Authoritative DNS points to xCloud, every production hostname loads over HTTPS, and traffic is draining from Ploi.

Step 15: Enable destination processing and monitor the cutover

Enable cron jobs, queue workers, imports, and webhooks on xCloud only after DNS, HTTPS, and final data validation pass. Keep the equivalent processing disabled on Ploi.

Monitor frontend errors, PHP and web-server logs, forms, checkout, email, scheduled work, resource usage, and recent database records throughout the rollback window.

Remove the temporary xCloud public key from the Ploi root account only after the migration and immediate connection troubleshooting are complete. Return any temporary firewall rule or security control to its previous secure state.

Expected result: xCloud is the only writable production environment and the only platform running scheduled or asynchronous work.

Verify the migration

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

  • Authoritative DNS resolves every production hostname to xCloud.
  • HTTPS works without certificate or mixed-content errors.
  • Frontend pages, WordPress administration, forms, checkout, uploads, email, and redirects work.
  • Business-critical data matches the approved final source state.
  • Cron jobs and workers run once, on xCloud, in the intended time zone and execution context.
  • Logs show no unresolved migration errors.
  • Site owners accept the production result.
  • The Ploi source remains intact and read-only for the agreed rollback window.

Troubleshooting

Symptom Likely cause Fix
xCloud cannot connect to the source xCloud’s key is not authorized for root, port 22 is blocked, or direct root SSH is unavailable Recheck the root authorized key, Ploi Network rules, the cloud-provider firewall, and direct root key authentication. Use site-level migration if direct root access cannot be provided safely
xCloud asks for a password but Ploi rejects it Ploi disables SSH password authentication by default Use xCloud’s public-key method. Do not enable root password authentication as a shortcut
The Ploi server uses a custom SSH port xCloud’s current full-server workflow requires port 22 Safely restore SSH to port 22 and update Ploi metadata, or use site-level migration
The source is Ubuntu 22.04, ARM, Docker, or a custom stack The server is valid for Ploi but outside xCloud’s current published full-server prerequisites Use site-level WordPress migration unless xCloud confirms support for the exact source
A WordPress site is missing from discovery The site is not on this server, root cannot read it, or its layout is unsupported Confirm the site location and root access. Move that site with the site-level workflow if discovery still fails
Migration stops because of storage The fresh xCloud server lacks space for site data and temporary copy operations Increase destination storage or migrate a smaller approved set. Keep at least 1 GB free beyond total site size
Demo data is stale The Ploi site accepted writes after the first copy Put both environments into maintenance or read-only mode and use the approved final-copy or reconciliation plan
Scheduled work runs twice Cron jobs or workers are active on both platforms Pause both sides during final synchronization, then enable processing only on xCloud
Production still reaches Ploi Authoritative DNS was not changed or cached records have not expired Verify the authoritative record and TTL. Keep Ploi online and read-only while traffic drains
HTTPS fails after cutover DNS does not fully resolve to xCloud or certificate issuance is incomplete Correct authoritative DNS, then complete xCloud’s SSL workflow and retest

Common mistakes

  • Assuming every Ploi server is eligible. Ploi supports several server types and custom configurations. xCloud’s generic workflow has narrower requirements.
  • Enteringploias the migration user. The current xCloud full-server flow requires a direct root SSH connection on port 22.
  • Enabling root passwords to bypass a key problem. Ploi’s current root access is key-only. Fix the temporary public-key authorization instead.
  • Treating the migration as a complete server clone. Selected WordPress files and databases move. Custom services, containers, mail, and non-WordPress applications need separate plans.
  • Skipping backup verification. A configured backup is not enough. Confirm both file and database recovery paths.
  • Going live before demo validation. Test behavior, recent data, integrations, logs, workers, 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 method.
  • Running background work on both platforms. Duplicate jobs can send repeated email, process an order twice, or corrupt shared state.
  • Deleting Ploi too early. Keep the source intact through DNS propagation, production validation, and the rollback window.

Roll back to Ploi

Rollback is a controlled data decision, not only a DNS change.

  1. Put the xCloud and Ploi 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. Reconcile the xCloud write delta back to Ploi only when a supported reverse-sync method exists. If none exists, document the possible data loss before proceeding.
  5. Restore the previous authoritative DNS values.
  6. Wait until production traffic drains from xCloud and reaches Ploi again.
  7. Verify HTTPS, recent data, forms, email, scheduled work, integrations, and logs on Ploi.
  8. Resume writes and background processing on Ploi 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 xCloud migrate every service on my Ploi server?

No. xCloud’s full-server workflow discovers and moves selected WordPress sites. Inventory Docker containers, custom daemons, mail services, monitoring agents, databases used by other applications, and other server-level workloads separately.

Can I use the ploi SSH user?

Not for xCloud’s current generic full-server flow. You may use the ploi account to administer the source and elevate with sudo su, but xCloud itself must connect directly as root on port 22 using the public key shown in the migration screen.

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

Not under xCloud’s current published full-server prerequisites. Use site-level WordPress migration unless xCloud confirms support for that exact source configuration.

Is the migration zero downtime?

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

Should I keep Ploi running after cutover?

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

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