Server Migration
Server Migration pulls whole hosting accounts into Panelica from another server over SSH: connect, discover what is there, decide who owns what, and watch it transfer live. What sets it apart is what happens when something goes wrong, because a real migration of a hundred sites over hours will hit a dropped connection, a full disk or a duplicate username, and this page documents exactly how each of those is handled.
Backup → Migrationhttps://YOUR-SERVER-IP:8443/backup/migrationA guided, five-step wizard
Migration is a wizard: Connect, Discover, Configure, Migrate, Complete, with a dashboard of saved sessions and past migrations as the entry point. Progress is checkpointed to disk, so you can close the tab and resume where you left off.
Connect: which panels
The panel connects to the source over SSH (username and password) and fingerprints what it is running from the files on disk. Recognized sources include cPanel, Plesk, DirectAdmin, CyberPanel, HestiaCP, CloudPanel, ISPConfig, Webuzo, aaPanel, CentOS Web Panel, another Panelica server, and even a panel-less raw server (plain Apache or Nginx). A keep-alive ping runs every thirty seconds to keep the session honest, and on connecting the panel reads the source's OS, uptime and disk.
Discover: two phases, opt-in
Discovery is deliberately two-phase to stay fast on large servers. Phase one lists domains quickly (name, user, document root, PHP version) and leaves them unselected; you pick what to migrate. Phase two runs the deep analysis only on your selection: sizes, databases, mailboxes, subdomains, SSL, cron jobs and large files, streamed live over a websocket that falls back to polling if it drops.
Configure: who owns what
Decide how source accounts map into Panelica: auto-create a Panelica user per source user, funnel everything into a single new user, assign to an existing user, or rebuild the source's reseller hierarchy. Then set the global choices: target PHP version, SSL provider (self-signed, Let's Encrypt, or none) and whether to include email. Every mode requires choosing a hosting plan, and the panel warns before you start if the selection would exceed that plan's domain count or disk quota.
Migrate: the pipeline
Each site runs through a fixed, ordered pipeline, and every step knows how to undo itself: create the user, create the domain, transfer files (rsync), migrate subdomains, import each database, import email, set up SSL, create DNS with the source's records, install cron jobs, and verify. Panelica-to-Panelica adds a Cloudflare step. You watch it live, per site, with a source-to-target animation, real transfer speeds and per-file progress.
wp-config.php, .env) transfer unchanged, so a migrated site connects to its database without edits. Email account passwords are preserved wherever the source exposes a usable hash (Panelica, cPanel, Plesk and most panels); a new password is generated and reported only when no source hash can be recovered.Resilience: what happens when it breaks
This is the part server administrators care about most, so here is the honest, mechanism-by-mechanism truth of how an interrupted or failing migration behaves.
One site failing never stops the others
Sites are processed one at a time, and each is fully isolated. If a site fails, it is marked failed, a webhook fires, and the migration continues to the next site. At the end you get an honest final status: if every site succeeded it says so, if some failed it reports "completed with errors: X of N migrated, Y failed" (not a false green), and if all failed the whole migration is marked failed. The per-site failure never cascades.
sites_completed and sites_failed so external automation sees the truth too.Every failure is classified, with a fix
When a site fails, the panel does not just say "error". It matches the failure to a known class and records the exact action you should take:
| Failure | Meaning | What to do |
|---|---|---|
| SSH auth failed | Wrong SSH credentials | Check the SSH username or password |
| SSH timeout | Source not responding | Verify the source server is reachable |
| Host unreachable | Refused / no route | Check the IP address and port |
| Connection lost | Reset / broken pipe | Retry the migration; the source connection dropped |
| Disk full | No space on target | Free disk on the target or migrate fewer sites |
| Source path not found | Document root missing | Check the source document root |
| Permission denied | SSH user cannot read | Give the SSH user read access to the files |
| Rsync failed | File transfer error | Check the connection and retry |
| MySQL dump failed | Cannot export a database | Check MySQL dump privileges on the source |
| MySQL import failed | Dump corrupted | Re-export from the source |
| Target user exists | Username taken | Choose a different username |
| Target domain exists | Domain already here | Pick a conflict mode: skip, rename or overwrite |
| Quota exceeded | Plan too small | Choose a bigger plan or fewer sites |
| Maildir not found | Mailbox path missing | Check the source email path |
Retries and connection recovery
A failing pipeline step is not fatal on the first stumble. Each step is retried up to three times with a short backoff (ten seconds, then twenty), but only for errors that are actually transient (connection resets, timeouts, "temporary", "refused", broken pipe, EOF); a permanent error like "user exists" returns immediately without wasting retries. Before each retry, and before each step and each site, the panel checks the SSH connection is alive and reconnects if it is not.
SSH reconnection is aggressive and patient at once: each check makes up to three reconnect attempts, deeper reconnection uses exponential backoff (capped so it never waits more than half a minute between tries), a background health monitor proactively reconnects if no successful ping has landed in two minutes, and, for very large sites, there is no artificial connection timeout so a multi-hour transfer of a 100 GB account is not killed mid-stream. A sliding-window rate limit stops a genuinely healthy long-lived connection from being locked out by old, stale failures.
--partial, so if the connection dies at 80% of a big file, the partial file is kept and the next attempt resumes from where it stopped rather than starting the file over. This is why a flaky link slows a migration down but does not doom it.Checkpoints and resume
Progress is checkpointed to disk continuously: automatically every thirty seconds, and immediately after each site completes (so a crash never loses a finished site). The checkpoint is written atomically (temp file, then rename), so it can never be half-written, and it records which sites are already done so a resume can skip them (failed sites are tracked in the database).
If the backend restarts mid-migration (a deploy, a reboot, a crash), the migration is moved to paused rather than silently dying, and you are told to press Resume. On resume, the pipeline skips every already-completed site and picks up from the first unfinished one. The panel deliberately does not auto-reconnect and barrel ahead after a restart; it waits for you to press Resume, so a restart never turns into an unattended surprise.
Pause, resume and cancel are different
- Pause is graceful: the current site finishes, and the migration stops before starting the next one. Nothing is undone.
- Resume continues from where a pause (or a restart) left off.
- Cancel is immediate and destructive on purpose: it interrupts the running step at once and rolls back everything that site created.
Rollback: nothing half-created is left behind
When a step fails after its retries, or you cancel, the site's completed steps are undone in reverse order: the mailboxes, databases, files, domain and user the migration created for that site are deleted. Two safety rules matter here. First, a domain or resource that already existed and was adopted rather than created is never deleted, because the migration only removes what it made. Second, file cleanup refuses to touch anything outside Panelica's own directory layout. If a rollback cannot run cleanly (a service is unavailable), it reports the problem loudly rather than leaving orphaned resources behind quietly.
Panelica to Panelica
Migrating from another Panelica server adds capabilities SSH alone cannot give: the target reaches the source's External API (HMAC-authenticated) to carry across things like Cloudflare credentials (decrypted on the source, re-encrypted on the target) that would otherwise be lost, making a Panelica-to-Panelica move the most complete migration path.
Access
A PRO and up licensed feature (migration), gated by the backup.migration page permission and scoped by the roles and permissions chain; assignable owners are limited to what the operator's role can create. The source password is used for the session only and is never stored.