Book a demo
Book a demo
Login

How to Migrate a Full Server from FlashPanel to xCloud

Updated September 25, 2026 · 14 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 migrate the WordPress sites on an eligible FlashPanel-managed server to a fresh xCloud server. Use xCloud’s full-server migration only when the source runs NGINX or OpenLiteSpeed on Ubuntu 20.04 or 24.04 LTS x64 and accepts root SSH on port 22. If the server does not meet every requirement, migrate each WordPress site separately instead of forcing the full-server workflow.

Choose the correct migration method

Confirm eligibility before creating the destination. FlashPanel can manage several server configurations, but xCloud’s full-server migration has a narrower source-server contract.

Your situation Use this xCloud path
You need to move multiple WordPress sites, and the FlashPanel server meets every full-server prerequisite below Full-server migration
You need to move one WordPress site Migrate an existing WordPress website in xCloud
Root SSH is unavailable, SSH does not listen on port 22, the OS is unsupported, or the web server is not NGINX or OpenLiteSpeed Site-level WordPress migration
The source contains non-WordPress applications, mailboxes, DNS zones, or server-level services Plan and migrate those components separately. Full-server migration discovers and copies WordPress sites, not the complete operating system.

Prerequisites

  • Owner or administrator access to the FlashPanel server.
  • Access to the VPS or cloud-provider console in case an SSH setting blocks remote access.
  • A source server running NGINX or OpenLiteSpeed on Ubuntu 20.04 or Ubuntu 24.04 LTS x64.
  • Root SSH access by password or public key on port 22.
  • A fresh xCloud destination server with no existing sites.
  • At least 1 GB of free destination storage beyond the total size of the selected sites.
  • A verified off-server backup of the source websites and databases.
  • Access to the authoritative DNS provider for every production domain.
  • An inventory of each site’s PHP version, plugins, scheduled jobs, email delivery, redirects, caching, and security controls.
  • A maintenance window and a rollback owner for sites that accept orders, form submissions, comments, memberships, or other writes.

Step 1: Inventory the FlashPanel server

Record every WordPress site you intend to move, including its production domain, approximate file and database size, PHP version, active cache and security plugins, scheduled jobs, outbound email method, and any external storage or service dependencies.

Also identify workloads that xCloud’s full-server migration does not cover, such as non-WordPress applications, mailboxes, DNS zones, custom system services, or server-wide cron jobs. Plan those as separate migrations.

Expected result: You have a site-by-site inventory and a separate list of components that will not move with the WordPress sites.

Step 2: Confirm that the FlashPanel server is eligible

Check the source server’s actual operating system, architecture, and active web server. Do not infer eligibility only because FlashPanel supports an operating system or web server in general.

The source is eligible only when all of these statements are true:

  • The operating system is Ubuntu 20.04 or Ubuntu 24.04 LTS x64.
  • The active web server is NGINX or OpenLiteSpeed.
  • SSH listens on port 22.
  • The root account can authenticate remotely by password or public key.
  • The server contains WordPress sites that root can read.

In FlashPanel, review Server → SSH before the migration. FlashPanel’s SSH interface can enable or disable root access and password authentication, restrict allowed users, and change the SSH port. If SSH currently uses another port, do not assume xCloud will accept it. The current xCloud full-server workflow requires port 22.

If any requirement is not met or cannot be verified, stop here and use the site-level WordPress migration.

Expected result: You have confirmed an eligible Ubuntu, NGINX or OpenLiteSpeed, root SSH, port-22 source server. Otherwise, you have selected the supported site-level fallback.

Step 3: Create and verify a FlashPanel backup

Open the source server in FlashPanel and select Backups. Use an existing off-server backup configuration or create one with a supported remote destination. FlashPanel documents Google Drive, OneDrive, Dropbox, SFTP, FTP, Amazon S3, and S3-compatible storage options.

Run the backup manually from the backup list. In Backup Histories, verify that the latest website and database backup reports a successful status and a plausible file size. A configuration that exists but has no successful history is not a verified recovery point.

Keep this backup unchanged until the xCloud migration, production validation, and rollback window are complete.

Expected result: Every in-scope WordPress site and database has a recent off-server backup with a successful FlashPanel history entry.

Step 4: Prepare the source sites

Schedule the migration outside peak traffic. Record the current settings before changing anything, then temporarily disable controls that can prevent xCloud from reading or copying a site:

  1. Disable two-factor authentication that applies to source-server access.
  2. Clear application and object caches.
  3. Temporarily disable cache plugins such as Object Cache Pro.
  4. Temporarily disable Wordfence or other security plugins that may block the migration.
  5. Identify host-specific must-use plugins and remove only those that are confirmed to be source-platform dependencies.
  6. Keep the source sites online for the demo migration unless your application requires a write freeze earlier.

Do not disable the source firewall broadly. Allow only the access needed for the migration, and restore the previous controls after xCloud no longer needs source access.

Expected result: Root can read the WordPress files and databases, while the source remains available for a controlled demo copy.

Step 5: Provision a fresh xCloud destination server

Create a new server in xCloud for the migration. Do not use an existing xCloud server that already hosts sites, because the full-server migration requires a fresh destination.

Open the server’s overview and confirm that free storage exceeds the combined source-site size by at least 1 GB. Leave additional headroom for logs, temporary files, and growth.

Expected result: The destination is online, contains no sites, and has enough free storage for the migration.

Step 6: Connect xCloud to the FlashPanel server

In xCloud, open the fresh destination and go to New Site → Migrate Full Server. Enter the source server address, port 22, and SSH username root.

Choose the authentication method that the source already permits:

  • Password: Enter the root password.
  • Public key: Copy the public key displayed by xCloud and add that public key to the root account’s authorized keys on the source. Never copy a private key into xCloud.

Select Next after the credential is in place.

Expected result: xCloud connects successfully and displays the WordPress sites it discovered on the FlashPanel server.

Step 7: Select the WordPress sites

Compare the discovered-site list with the inventory from step 1. Select only the sites included in this migration and continue.

If a site is missing, do not proceed with an incomplete bulk move. Confirm that it is a WordPress installation on this server and that root can read its files and database. Use site-level migration for a site that the full-server workflow cannot discover.

Expected result: The selected list exactly matches the WordPress sites you intend to migrate.

Step 8: Run the first migration as demo sites

Choose Demo Site for each selected site and start the migration. Demo domains let you inspect the destination before production DNS changes.

xCloud copies the selected WordPress files, dumps and imports their databases, and updates URLs when the destination address differs. The duration depends on the combined site size and the connection between servers.

Do not select Go Live for the first copy unless you are ready to switch DNS immediately after it finishes.

Expected result: Each selected site completes on an xCloud demo domain without changing production traffic.

Step 9: Validate every demo site

Test each migrated site as both a visitor and an administrator. Use this checklist for every domain:

  • Frontend pages, navigation, media, and downloads load correctly.
  • WordPress administrator sign-in works.
  • Recent posts, users, orders, form entries, and other database records are present.
  • Forms, checkout, membership actions, and login flows behave as expected.
  • Plugins and the active theme load without fatal errors.
  • Scheduled tasks and any application-level cron behavior are accounted for.
  • Transactional email uses the intended provider and does not send unintended test messages.
  • Redirects, canonical URLs, and mixed-content behavior are correct.
  • Caching and security controls are ready to be re-enabled on xCloud.

Do not use demo validation as proof that new production writes will appear automatically. A demo copy is a point-in-time migration.

Expected result: Every site passes a recorded validation checklist, and any failed site remains on FlashPanel while you correct or rerun its migration through a supported path.

Step 10: Plan the final synchronization and write freeze

xCloud’s current generic full-server guide does not document an incremental final-sync or database-merge feature. Do not assume a second run will merge writes safely.

For a stateful site, schedule a short write freeze before the final supported copy or cutover decision. Put the source into maintenance or otherwise pause orders, form submissions, comments, membership changes, background workers, and scheduled jobs that write data. Keep the temporary destination read-only as well.

If production changed after the demo copy, contact xCloud migration support to confirm the supported recopy method, or use a site-level migration that you can repeat during the freeze. Do not copy a live database over a destination that has already accepted writes.

Expected result: One environment is designated as the authoritative data source, writes are paused on both sides, and the final copy method is confirmed before DNS changes.

Step 11: Cut over DNS and verify SSL

Lower the DNS time to live at least one existing-TTL interval before the maintenance window. At cutover, update each production domain’s authoritative DNS records to the xCloud destination by following xCloud’s DNS record guide.

Confirm that public DNS answers with the destination address. After DNS resolves, verify HTTPS. If xCloud does not provision the certificate as expected, follow Enable HTTPS and configure SSL certificates.

Keep the source server and its backup intact. Do not cancel the source service during the rollback window.

Expected result: The production domain resolves to xCloud, HTTPS loads without a certificate warning, and new traffic reaches the validated destination.

Step 12: Re-enable production processing

After DNS and HTTPS checks pass, re-enable destination cache and security controls one at a time. Then enable destination scheduled jobs, background processing, forms, checkout, comments, or other writes.

Keep the FlashPanel source read-only while DNS caches drain. Monitor error logs, application health, forms, checkout, email, scheduled tasks, and external integrations during the rollback window.

Expected result: xCloud is the only writable production environment, and the source remains available only as a controlled rollback point.

Verification checklist

The migration is complete only when all of these statements are true:

  • Every intended WordPress site exists on the xCloud destination.
  • Production DNS resolves to xCloud from more than one network or public resolver.
  • HTTPS presents a valid certificate for every production hostname.
  • Frontend and WordPress administrator checks pass.
  • Recent database records and uploaded files match the final source state.
  • Forms, checkout, login, email, redirects, plugins, scheduled jobs, and security controls work as expected.
  • Only xCloud accepts production writes.
  • The FlashPanel backup and source server remain available for the agreed rollback window.

Troubleshooting

Symptom Likely cause Fix
xCloud cannot connect to the source Root SSH is disabled, SSH is not on port 22, an allowed-user rule excludes root, or a firewall blocks the connection In FlashPanel, review Server → SSH. Confirm root access, port 22, the selected authentication method, and any user restrictions. Check the VPS firewall without exposing SSH more broadly than necessary.
Public-key authentication fails The xCloud public key is missing, malformed, or installed for the wrong account Add the exact public key shown by xCloud to the root account’s authorized keys, then retry. Never upload or paste a private key.
A WordPress site is missing from the discovered list The site is not on this server, is not a detectable WordPress installation, or root cannot read its files or database Confirm the inventory and permissions. Migrate the affected site with the site-level WordPress workflow if it remains undiscovered.
Migration stops because of storage The destination does not have the required free capacity Increase destination storage or reduce the selected migration scope. Keep at least 1 GB beyond the total selected-site size.
The demo site redirects to the production domain A plugin, theme, hard-coded URL, or cache still forces the old hostname Clear caches and inspect WordPress URL settings, redirects, and hard-coded configuration before cutover.
The site works on the demo domain but fails after DNS cutover DNS still points partly to the source, or HTTPS is not ready Verify authoritative A or AAAA records, wait for the published TTL, then check certificate issuance with xCloud’s SSL guide.
Orders or form entries are missing Writes continued after the point-in-time copy Stop writes on both environments and restore a known authoritative data set. Contact xCloud support for a supported recopy plan. Do not merge databases manually without an application-specific reconciliation plan.
SSH access breaks after a FlashPanel change An SSH option, allowed-user rule, or port change blocked the session Use the VPS provider’s console to restore a working configuration. FlashPanel states that its SSH interface validates settings, but you should still keep console access before changing authentication.

Common mistakes

  • Assuming every FlashPanel server is eligible. xCloud supports only the stated operating systems, web servers, root access, and port for this workflow.
  • Treating full-server migration as an operating-system clone. It migrates discovered WordPress sites, not mailboxes, DNS zones, arbitrary applications, or server services.
  • Skipping an off-server backup. A successful migration is not a substitute for a verified recovery point.
  • Using Go Live for the first copy. Demo Site provides a safer validation surface before DNS changes.
  • Assuming demo data stays current. Production can change after the copy, so stateful sites need a write freeze and a confirmed final-copy method.
  • Allowing both environments to process writes. Duplicate workers, cron jobs, orders, or form submissions create split-brain data.
  • Turning off the source too early. Keep FlashPanel and its backup available until validation and the rollback window are complete.

Rollback guidance

Rollback must preserve one authoritative data set. If a blocking issue appears after cutover:

  1. Put both FlashPanel and xCloud into read-only or maintenance mode.
  2. Pause scheduled jobs and background workers on both environments.
  3. Record any writes that reached xCloud after cutover.
  4. Decide whether those destination writes can be reconciled into the source. Do not assume reverse synchronization exists.
  5. Restore authoritative DNS records to the FlashPanel source.
  6. Wait until destination traffic has drained according to the DNS TTL and live checks.
  7. Verify the source site’s frontend, administrator access, HTTPS, forms, checkout, email, and recent data.
  8. Resume source writes and processing only after xCloud no longer receives production traffic.

If destination-only writes cannot be reconciled, rollback can lose those changes. Make that decision explicitly with the site owner before resuming the source.

Frequently asked questions

Does this move everything managed by FlashPanel?

No. xCloud’s full-server migration discovers and moves WordPress sites. Mailboxes, DNS zones, non-WordPress applications, custom services, and server-level jobs need separate plans.

Can I use a custom SSH port?

Not for the current xCloud full-server workflow. The published prerequisite is root SSH on port 22. Use site-level migration if you cannot safely meet that requirement.

Can I migrate a FlashPanel server running Ubuntu 22.04?

FlashPanel documents Ubuntu 22.04 as a supported server connection option, but xCloud’s current full-server migration prerequisites list Ubuntu 20.04 or 24.04 LTS x64. Route an Ubuntu 22.04 source through site-level migration unless xCloud support confirms another supported path.

Does the migration provide zero downtime?

No. Demo validation reduces risk, but stateful sites can require a short write freeze for the final copy and DNS cutover. The duration depends on the site, DNS TTL, and chosen final-copy method.

When can I remove the FlashPanel source?

Remove it only after the rollback window ends, DNS consistently resolves to xCloud, HTTPS is valid, application checks pass, and stakeholders confirm that no rollback is needed.

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