Book a demo
Book a demo
Login

How to Migrate from EasyPanel to xCloud

Updated September 25, 2026 · 17 min read

If you would rather have it done for you, the xCloud team migrates sites for free: see free website migration. An EasyPanel server cannot be imported with xCloud’s one-run Migrate Full Server workflow. That workflow discovers WordPress sites on a source host running NGINX or OpenLiteSpeed on Ubuntu 20.04 or 24.04 LTS x64, with root SSH on port 22. EasyPanel normally runs applications as Docker services, initializes Docker Swarm, and routes public traffic through Traefik. Migrate the server workload by workload instead: use xCloud’s WordPress migration flow for WordPress services, and use xCloud’s native Git or Custom Docker flow for other applications.

This guide is for EasyPanel administrators who need to move all production workloads to xCloud without treating the two platforms as identical. It covers backups, service mapping, staging validation, a controlled write freeze, DNS and SSL cutover, and rollback. It does not promise zero downtime.

Choose the correct migration method

Use the method that matches each EasyPanel service. Do not submit the EasyPanel host to xCloud’s full-server importer. Root SSH access alone does not make the normal EasyPanel Docker and Traefik layout compatible with that importer.

EasyPanel workload xCloud destination Migration method
WordPress service WordPress site on an xCloud NGINX or OpenLiteSpeed server xCloud Migrate An Existing WordPress Website flow, one site at a time
App service with a supported repository-based runtime xCloud Git site Add New Site → Deploy Via Git
App service built from a Dockerfile or image Custom Docker site on a Docker + NGINX server Recreate the container input and settings in xCloud
Compose service Custom Docker site on a Docker + NGINX server New Site → Custom Docker → Docker Compose From Git
MySQL or MariaDB service xCloud server database, Compose database, or an external database Create a portable logical dump and restore it to a compatible target
PostgreSQL, MongoDB, or Redis service Compose service or an external managed service Use the database engine’s current export and restore procedure
Scripts scheduled in EasyPanel xCloud site or server cron, Supervisor, Laravel Queue, or a Compose worker Recreate the command, user, working directory, environment, timezone, and overlap behavior
Persistent App, Box, WordPress, or Compose data xCloud persistent storage supported by the selected deployment Export the actual files, then restore them to an explicit volume or eligible bind mount

If you only need to move standard WordPress sites from a non-EasyPanel NGINX or OpenLiteSpeed host, use xCloud’s full-server migration guide instead.

Prerequisites

  • Owner or administrator access to EasyPanel and every project being moved.
  • Root or equivalent administrative access to the source server for inventory and recovery, without assuming that root access makes full-server import compatible.
  • Access to each source repository, image registry, deployment branch, and build definition.
  • Access to all application environment values through an approved secret-handling process.
  • A tested external backup of each database and persistent data set.
  • An xCloud destination server with enough CPU, memory, and storage for the mapped workload.
  • A Docker + NGINX xCloud server for Custom Docker and Docker Compose sites.
  • A temporary xCloud demo or staging domain for every public workload.
  • Access to the authoritative DNS zone for every production domain.
  • A maintenance window for stateful services and a named rollback owner.
  • A rollback period during which the EasyPanel server, external backups, and previous DNS values remain available.

Step 1: Confirm that the EasyPanel host is not eligible for one-run full-server import

Open the xCloud full-server migration prerequisites and compare them with the source architecture. The importer requires source WordPress sites on NGINX or OpenLiteSpeed, Ubuntu 20.04 or 24.04 LTS x64, and root SSH on port 22.

EasyPanel’s standard installation runs Docker, initializes Docker Swarm, and starts EasyPanel. EasyPanel App and Compose services are containers, and their public domains are routed through Traefik. An NGINX process inside an EasyPanel WordPress container does not turn the host into the server layout expected by xCloud’s full-server importer.

Expected result: You have ruled out a single full-server import for the normal EasyPanel layout and selected a supported per-service route for every workload.

Step 2: Inventory every EasyPanel service

In EasyPanel, review each project and record every WordPress, App, Box, Compose, database, and cache service. For each service, capture the source type, repository or image, branch or tag, build method, command, domains, environment variable names, mounted storage paths, internal dependencies, published ports, scripts, scheduled jobs, and resource settings.

Use an inventory table like this:

Component EasyPanel source State to move xCloud destination
Public web service Git, image, Dockerfile, Box, or Compose Environment, domain, uploads, database Git site or Custom Docker site
WordPress service EasyPanel WordPress runtime Database,wp-content, configuration, users xCloud WordPress migration flow
Worker App or Compose command Queue settings, command, environment Compose service, Supervisor, or Laravel Queue
Scheduled script Script plus cron schedule Command, timezone, user, working directory xCloud site or server cron
Database MySQL, MariaDB, PostgreSQL, MongoDB, or Redis Engine version, schema, data, users Compatible xCloud, Compose, or external database
Persistent storage Volume or bind mount Files, ownership, permissions, mount path Explicit persistent destination storage
Domain EasyPanel domain routed through Traefik Hostname, redirects, TLS behavior xCloud site domain and DNS records

Do not treat one EasyPanel project as one xCloud site without checking its services. A project can contain several independently deployed applications and data stores.

Expected result: Every source service, dependency, stateful path, scheduled process, and public domain has one destination owner.

Step 3: Create and verify source backups

Open EasyPanel → Server Settings → Storage Providers and configure a remote destination if one is not already available. EasyPanel supports destinations such as SFTP, Amazon S3 and S3-compatible storage. Avoid relying only on local storage on the source server because it does not protect against a server or disk failure.

For each database, create or run its logical backup configuration. For App or Box volumes, configure a volume backup where the service supports it. For WordPress, protect both the database and persistent files. EasyPanel’s WordPress Import Export section can download a database export and WordPress files; keep both artifacts from the same point in time.

Run each new or changed backup manually, review its action log, and confirm that the expected object exists at the remote destination. Test recovery with non-production data when possible. A backup is not verified merely because a schedule exists.

EasyPanel documents database dumps and volume data as different backup types with different recovery workflows. Treat provider-native backups as rollback assets. Also prepare portable database dumps and file exports that can be restored outside EasyPanel.

Expected result: Every stateful service has a recent off-server backup plus a portable export whose existence and recovery path are known.

Step 4: Create the xCloud destination on temporary domains

Create the destination without changing production DNS.

For WordPress services

  1. In xCloud, select Add New Site and choose the destination server.
  2. Select Migrate An Existing WordPress Website.
  3. Enter the EasyPanel-hosted source site URL and choose a demo domain.
  4. Review the PHP version, database prefix, and site user settings.
  5. Download the migration plugin shown by xCloud and copy its access token.
  6. In the source WordPress administration area, install the plugin and enter the token.
  7. Return to xCloud, confirm the token step, choose the database and file scope, and start the migration.

Follow Migrate an existing WordPress website in xCloud for the current control names and sequence.

Expected result: Each WordPress site opens on an xCloud demo domain while the production domain still serves from EasyPanel.

For supported repository-based applications

  1. In xCloud, select Add New Site and choose the destination server.
  2. Select Deploy Via Git.
  3. Choose a public repository, connected GitHub repository, or private repository with an SSH deploy key.
  4. Confirm the detected application type, deployment branch, serving mode, web root, start command, and port.
  5. Choose an xCloud staging domain.
  6. Under Advanced, configure database handling, environment values, and the build and deploy script.
  7. Review the configuration and select Deploy.

Use this path only for application types supported by xCloud’s current Git flow. Follow Deploy Git projects in one click with xCloud for the current supported types and fields.

Expected result: The application builds and opens on a temporary xCloud HTTPS address without using production DNS.

For App or Compose workloads that need containers

  1. Provision or select an xCloud server with the Docker + NGINX stack.
  2. Put the portable Docker Compose definition in a repository. Use build: for a repository Dockerfile or image: for an existing image as appropriate.
  3. In xCloud, select New Site → Custom Docker → Docker Compose From Git.
  4. Choose a demo domain.
  5. Select the repository and branch, then enter the Compose filename or path.
  6. Select Auto-Detect Ports and choose the primary public service port.
  7. Map only additional public HTTP services that require their own domains. Keep databases and caches private unless the design requires external access.
  8. Enable Environment File and add reviewed destination values.
  9. Add only necessary post-deployment commands, then deploy.

Do not copy EasyPanel’s Traefik routing metadata into the destination Compose file. Configure xCloud domains and HTTPS through xCloud’s site controls. Follow Deploy a custom Docker application from Git for the current workflow.

Expected result: Each containerized workload runs on an xCloud demo domain with the intended primary service and no unnecessary public database or cache port.

Step 5: Move configuration, databases, and persistent files

Review each environment value before adding it to xCloud. Copy application-owned settings, but replace EasyPanel service names, internal addresses, domain-derived values, and storage paths with destination-specific values. Keep secrets out of repositories, shared logs, and documentation.

Create each destination database with the required engine and compatible version. Restore the portable export with that engine’s official restore procedure. Do not adapt a PostgreSQL command to MySQL, MariaDB, MongoDB, or Redis. Review restore errors, then compare schema objects, critical record counts, and representative recent records.

Restore persistent files into a named volume, eligible bind mount, or other explicit durable location supported by the selected xCloud deployment. Preserve the application path, ownership, and permissions. Container filesystem changes that are not stored persistently can disappear when the service is recreated.

For each migrated Docker site, create an xCloud backup before production cutover. Open Backup → Previous Backups → Backup Now and wait for the backup to reach Completed. Confirm that eligible named volumes or bind mounts and the deployment configuration are included. See Back up and restore Docker apps in xCloud.

Expected result: The destination reads its own database and files, no connection points back to EasyPanel, and a completed destination backup exists.

Step 6: Recreate workers, scripts, and schedules

EasyPanel scripts can run manually, on a cron schedule, or through a webhook. Recreate each one deliberately in xCloud. Record the original command, container or service context, user, working directory, environment loading, timezone, retry behavior, and overlap behavior.

Use a separate Compose service when a worker belongs inside a multi-container application. For supported non-container applications, use xCloud Supervisor where appropriate. Use the xCloud site-level or server-level cron controls for scheduled commands, and use Laravel Queue for Laravel workers when that matches the application.

Keep destination workers and schedules paused after testing. They must remain paused during final synchronization so the source and destination do not process the same job or modify the same external system.

Expected result: Every background process has one destination definition and remains disabled until the final cutover step.

Step 7: Validate every workload on its temporary domain

Test while EasyPanel still serves production traffic. Validate:

  • Public pages, APIs, health checks, redirects, and canonical URLs.
  • Authentication, sessions, permissions, and logout.
  • Representative create, read, update, and delete operations using reversible test data.
  • Database schema, record counts, and recent representative records.
  • File uploads, downloads, generated assets, ownership, and persistence after redeployment.
  • Queue submission, worker completion, retries, and failure handling.
  • Scheduled commands with a safe test invocation.
  • Transactional email and webhooks through sandbox targets or test recipients.
  • Application, worker, database, and proxy logs.
  • WordPress administration, media, forms, checkout, plugins, cron, and email where applicable.

Do not enable production side effects only to prove that a page loads. Use sandbox endpoints and reversible records.

Expected result: Every destination workload passes an application-specific acceptance check without depending on a service that will be retired with EasyPanel.

Step 8: Perform the final sync and production cutover

A stateful migration normally needs a short write freeze. Plan the sequence before changing DNS.

  1. Lower the DNS TTL at least one existing-TTL interval before cutover when your DNS policy allows it, then verify the authoritative response shows the lower value.
  2. Enable maintenance or read-only behavior on both the EasyPanel source and temporary xCloud destination.
  3. Pause workers, scheduled scripts, cron jobs, and webhook-driven jobs on both platforms.
  4. Allow in-flight requests and background jobs to finish.
  5. Create the final database dump and file export from EasyPanel.
  6. Restore the final data to xCloud.
  7. Compare critical record counts, recent records, file counts, and checksums where appropriate.
  8. Change the xCloud site from its demo domain to the production domain or use the site’s domain-change flow.
  9. Update the authoritative DNS records with the values xCloud displays.
  10. Confirm that authoritative DNS returns the new value.
  11. Wait for xCloud to provision the production certificate, then verify HTTPS and required aliases.
  12. Enable xCloud workers and schedules only after new production traffic reaches xCloud.
  13. Keep EasyPanel read-only during the rollback window.

Use Set up DNS records for an xCloud server and Enable HTTPS and configure SSL certificates for the current xCloud controls.

Expected result: Authoritative DNS points to xCloud, the production hostname has a valid certificate, new writes appear only in the xCloud destination, and asynchronous work runs only on xCloud.

Verification checklist

  • No workload was submitted to the incompatible EasyPanel full-server import path.
  • Every EasyPanel service and dependency has a documented xCloud destination.
  • Every database and persistent data set has a verified external backup.
  • Production hostnames resolve to xCloud from multiple resolvers.
  • HTTPS is valid for each hostname and required alias.
  • Critical routes, logins, APIs, forms, and uploads work.
  • Database counts and recent records match the final source export.
  • Persistent files remain after a controlled destination redeployment.
  • Workers and schedules run only on xCloud.
  • Logs show no repeated connection, permission, missing-variable, or health-check errors.
  • EasyPanel remains available but read-only until the rollback window closes.

Troubleshooting

Symptom Likely cause Fix
xCloud’s full-server importer cannot discover the EasyPanel sites The importer expects host-level WordPress sites on NGINX or OpenLiteSpeed, while EasyPanel services run in Docker and use Traefik routing Stop the full-server attempt. Route WordPress through the xCloud WordPress migration flow and other services through Git or Custom Docker.
A Git deployment fails EasyPanel’s builder behavior or runtime dependency was not represented in xCloud Compare the source build, start command, runtime, and system dependencies. Use Custom Docker when the native Git flow does not support the workload.
A Compose deployment fails port checks The source Compose file publishes a host port or sets a fixed container name that conflicts on the destination Remove unnecessary public host ports and fixed container names. Use xCloud domain routing for public HTTP services.
The application starts but cannot reach a dependency An EasyPanel internal service name, network address, or environment reference remains Replace it with the xCloud Compose service name, xCloud database address, or external endpoint selected in the migration plan.
Restored files disappear after redeployment The destination wrote state to the container layer Map the write path to persistent storage, restore the files again, and verify persistence after another controlled redeployment.
The database restore fails Engine version, extensions, ownership, encoding, or target permissions differ Align the target engine and required extensions, restore with an authorized user, and use that engine’s official restore diagnostics.
Jobs run twice EasyPanel and xCloud workers or schedules are active together Pause both sides, reconcile queue and external side effects, then enable only the destination process.
Some users still reach EasyPanel Recursive resolvers still cache the previous DNS answer Keep EasyPanel available but read-only. Monitor both environments until the previous TTL expires.
HTTPS remains pending DNS still points to EasyPanel, a proxy conflicts with validation, or propagation is incomplete Compare authoritative DNS with xCloud’s displayed values, remove obsolete records, review proxy settings, and retry certificate issuance after propagation.

Common mistakes

  • Assuming root SSH makes EasyPanel eligible for full-server import. The source web stack and application layout also have to match xCloud’s importer prerequisites.
  • Migrating only public web containers. Databases, caches, workers, scripts, volumes, domains, and redirects require explicit destinations.
  • Copying environment values unchanged. EasyPanel internal addresses and domain-derived settings may not describe the xCloud network.
  • Treating a provider backup as a portable export. Keep EasyPanel backups for rollback, but prepare database dumps and file exports that can be restored outside EasyPanel.
  • Using the first database restore during cutover. Rehearse the restore before the maintenance window.
  • Starting destination jobs before the final sync. This can duplicate emails, webhooks, queue processing, or scheduled changes.
  • Deleting EasyPanel immediately. DNS caches, delayed jobs, and rollback needs outlive the first successful browser test.

Rollback guidance

Keep EasyPanel, its external backups, and the previous DNS values intact until the rollback window closes. If production validation fails, pause xCloud workers and schedules first. Put xCloud in maintenance or read-only mode and keep EasyPanel read-only while you decide which copy owns the latest data.

If xCloud accepted writes, capture the destination write delta before changing DNS back. Reconcile that delta into the chosen authoritative data store, or document an explicit decision to discard it. Restore the previous DNS records, wait for destination traffic to drain, verify that the source is healthy, then re-enable EasyPanel writes and background processing.

Do not operate both copies as writable production systems. A reverse synchronization path may not exist for every database or file set, so rollback after destination writes can require manual reconciliation and may otherwise lose data.

Frequently asked questions

Can xCloud migrate an EasyPanel server in one run?

No. xCloud’s full-server migration workflow is for WordPress sites on a source host that matches its NGINX or OpenLiteSpeed, Ubuntu, and root SSH prerequisites. The normal EasyPanel Docker, Docker Swarm, and Traefik layout does not match that source model.

Does EasyPanel’s WordPress NGINX runtime make the host eligible?

No. NGINX inside an EasyPanel WordPress container is not the host-level site layout expected by the full-server importer. Migrate each WordPress site through xCloud’s WordPress migration flow.

Should an EasyPanel Compose service move directly to xCloud Compose?

Use the source Compose definition as a starting point, not as an unchecked copy. Remove EasyPanel-specific routing, confirm image or build inputs, map persistent storage, review secrets, keep private services private, and configure public domains through xCloud.

Can this migration be completed without downtime?

Do not assume zero downtime. Stateless services may cut over quickly, but databases, uploads, queues, and scheduled work normally need a short write freeze and final synchronization.

When can I remove the EasyPanel server?

Remove it only after DNS caches have expired, production validation has passed, destination backups are confirmed, background jobs are stable, and the rollback window has closed.

If you run into any issues during the migration, feel free to reach out to our support team.