Migrating from Plesk to Panelica: A Step-by-Step Walkthrough

Moving away from Plesk is rarely spontaneous. Usually something tips the balance: a licensing invoice that no longer matches the value you are getting, a January 2026 price revision that landed without much warning, or a growing awareness that your panel's architecture is a decade older than the problem you are trying to solve today. Whatever brought you here, the question is the same: can this migration actually be done without months of manual work?

Panelica has a built-in Migration wizard that handles Plesk migrations end to end. This walkthrough covers every step, every form field, and every decision point — with visual mockups of the actual interface so you know exactly what you are looking at before you start. If you are researching a Plesk alternative or a cPanel alternative, this is the most complete picture of how a modern migration works.

Before you click anything: 5-minute Plesk pre-flight checklist

A migration that fails halfway through is worse than one that never started. Run through this list on both the source (Plesk) and destination (Panelica) servers before launching the wizard.

On the Plesk source server:

• Confirm root SSH access is available. Panelica connects over SSH to read the Plesk configuration database (/var/lib/psa/) and the vhost file tree.
• Verify that TCP port 8443 (Plesk's default management port) is reachable from the Panelica server's IP address. Panelica's discovery engine connects to the Plesk API on this port during subscription enumeration.
• Check that rsync is installed on the source server: which rsync. If missing, apt install rsync or yum install rsync before starting.
• Note the Plesk admin username and password. The wizard uses these to authenticate against the Plesk XML API during the Discover step — you do not need a separate API key.
• Note your total vhost disk usage: du -sh /var/www/vhosts/*. Your Panelica server needs at least that much free space plus 10-15% headroom.
• If any subscriptions use WP Toolkit, note which ones. WP Toolkit metadata is read during discovery. The WordPress files and databases migrate normally — see the gotchas section below for WP Toolkit-specific notes.
• If you use Plesk-managed DNS, lower the TTL on your zones to 300 seconds a few hours before cutover. Plesk DNS zone data exports automatically via BIND-compatible format during the DNS stage.

On the Panelica destination server:

• Confirm you are on a Professional plan or higher. The Migration feature is available on all paid plans and throughout the 14-day free trial.
• Check available disk: df -h /. Plan for source size plus headroom.
• Ensure the panel is up to date via Settings > Updates before starting. The Plesk migration adapter was significantly updated in the 1.0.x series.
• If you manage active email, plan for a brief window where both the Plesk server and the Panelica server may receive incoming mail. MX cutover is always the last step.

Where the migration lives in the Panelica sidebar

The Migration wizard is nested under the Backup section in the left sidebar. Below is a representation of the sidebar structure showing exactly where to click:

The Migration item appears under Backup in the left sidebar. Click the Backup row to expand it — by default it is collapsed on a fresh Panelica install, revealing four children: Snapshots, Migration, Remote, and Schedule. Migration is the second item. Click it to open the 5-step wizard.

Migration is available on Professional and higher plans. If you are on the 14-day free trial, Migration is fully accessible for the trial period.

The 5-step wizard at a glance

Before walking each step in detail, here is the full wizard progress indicator as it appears at the top of every migration screen:

The step indicator sits at the top of every wizard screen. Completed steps turn green with a check mark. The active step glows blue. Steps not yet reached stay gray. You can click a completed step to revisit it — though certain fields lock once the migration itself starts at step 4.

Step 1 — Connect: pointing Panelica at your Plesk server

The first screen asks for the source server's hostname or IP address, a username with SSH access, and the corresponding password. Below is what the connection form looks like for a Plesk source:

Enter the hostname or IP of your Plesk server in the Host field. For username, root is standard. If your server restricts root SSH logins, use a sudo-capable account — the wizard escalates privileges during file transfer.

Click Test Connection. Panelica opens an SSH session to the source server, verifies credentials, confirms that rsync is available, and checks that port 8443 (Plesk XML API) is reachable from the destination. The connection indicator on the right changes from gray to green on success. Error messages are specific: wrong port, auth failure, missing rsync, or blocked firewall rule.

Credentials are not stored permanently. They are held in the active migration session only and discarded when the migration completes or is cancelled. You do not need to open or close the Plesk Migrator extension — Panelica's discovery reads the Plesk configuration directly and does not modify the Plesk installation in any way.

Step 2 — Discover: subscriptions, mail domains, databases

Once connected, Panelica scans the Plesk server using a combination of SSH filesystem inspection and the Plesk XML API. It enumerates Customers, Resellers, Subscriptions, Mail Domains, and Databases. Below is what the Discover step looks like once the scan completes:

Plesk uses the term "Subscription" where cPanel uses "Account" or "Site". Each Subscription row shows the associated Service Plan name (Web Pro, Web Admin, and so on), its disk size, and its status. The Service Plan name is informational — it carries over as a label so you can see what tier each subscription was on in Plesk. Panelica does not import Plesk Service Plans as billing plans; you assign those in step 3.

The counter strip at the top distinguishes Subscriptions from Mail Domains because in Plesk a single subscription can have multiple mail domains attached. The Discover step counts them separately so you know the full scope of what is coming. Individual subscription rows each have a checkbox. The search bar filters in real time, which matters when the source Plesk installation has 50 or more subscriptions.

The Rescan button re-runs discovery if you made changes on the source server. Show Results previews what would be created before you commit. When the selection matches what you want, click Continue.

Step 3 — Configure: mapping Plesk Customers and Resellers to Panelica users

Plesk organizes hosting using Customers and Resellers, each of which can own one or more Subscriptions. Step 3 is where you decide how that hierarchy maps to Panelica users. There are three modes:

Auto Create is the right choice for reseller and agency migrations. Panelica creates one new user per Plesk Customer and assigns the appropriate subscriptions to each. If the source Plesk installation has a Reseller tier, those accounts are created at the Reseller level in Panelica's RBAC hierarchy.

Single User collapses all subscriptions into one new Panelica user. Use this when you are migrating your own Plesk server — you are the only operator and want all your domains under one account.

Existing User lets you target a user that already exists in Panelica. This is useful for incremental migrations where you have already created the user manually and want the wizard to populate their domains and databases.

The plan limits banner at the bottom of step 3 shows exactly how many domains, databases, and emails you are about to add against your current plan limits, color coded green to red. You cannot advance past step 3 if the migration would exceed a hard limit.

What runs in the background: the 11-stage pipeline with Plesk-specific extraction

Between clicking Start and seeing the completion screen, Panelica runs each selected subscription through an 11-stage pipeline. Plesk-specific logic is active at multiple stages.

Stage 4 — Credential Harvest — has two Plesk-specific behaviors worth understanding. First, MySQL password hashes are read directly from the mysql.user table on the source server and transplanted verbatim to the destination, so your WordPress wp-config.php files do not need editing. Second, Plesk encrypts mailbox passwords using a per-server encryption key stored in the Plesk psa database. Panelica extracts that key automatically during the credential harvest stage and uses it to decrypt the passwords, then re-encrypts them in Dovecot's native format on the destination. Mail clients reconnect without any password changes required.

Stage 9 — Email Import — covers the full Plesk email subsystem: Mailboxes, Mail Forwarders, Mail Aliases, Autoresponders, Sieve Filters, and the Catchall flag per mail domain. The source Plesk mail spool is detected automatically — newer Plesk installations store mail in /var/vmail/ using Postfix and Dovecot; older installations may use /var/qmail/ with a different directory layout. Panelica's email metadata discovery handles both paths.

The pipeline stores a checkpoint after each stage. If a network interruption occurs at stage 7, you resume from stage 7 — not from stage 1.

Step 4 — Migrate: live progress, pause, cancel

Step 4 is where the actual data movement happens. The screen updates in real time via WebSocket. Below is what the in-progress view looks like for a Plesk migration with 32 subscriptions:

The overall progress bar represents the aggregate across all selected subscriptions. Each subscription below it has its own mini progress bar and a stage label — you can see which site is transferring files, which is importing its databases, and which has finished.

Pause suspends active transfers cleanly: Panelica writes a checkpoint, closes the rsync sessions gracefully, and waits. Resume picks up exactly where it stopped. This is particularly useful for large Plesk reseller migrations where you want to schedule heavy file transfers overnight and pause during business hours.

Cancel aborts the migration and rolls back whatever was partially applied — partial users, domains, and databases are removed. The source Plesk server is not modified at any point. Cancel is safe to use mid-flight.

Step 5 — Complete: verification before DNS cutover

Once all subscriptions finish their pipeline run, the wizard transitions to the Complete screen. Below is what the completion summary looks like for a 32-subscription Plesk migration:

The completion screen shows five numbers for a Plesk migration: subscriptions migrated, total data transferred, elapsed time, failed subscriptions, and Plesk Customers mapped (the source customer accounts that were enumerated and matched to Panelica users).

Before touching DNS, do a verification pass using the three buttons on this screen. Open View Domains and confirm each domain is listed with its document root and PHP version correct. Open Email Accounts and spot-check two or three mailboxes including a forwarded address if you have one. Open Databases and confirm database names and user associations match. This takes about five minutes and catches the rare cases where a subscription needs a manual adjustment before cutover.

DNS cutover and how Plesk-managed DNS records carry over

The migration wizard does not touch your DNS records. That is intentional — it lets you migrate, verify, and test everything while the source Plesk server continues serving live traffic. When you are ready to cut over, the process is the same whether your DNS was Plesk-managed or external.

For each migrated domain, update the A record (and AAAA if applicable) to point to your Panelica server's IP. If you were using Plesk's built-in DNS server, Panelica imports the zone data during stage 3 of the pipeline and sets up equivalent zones in its built-in BIND installation. You can review and edit the imported DNS records under Domains > DNS for each domain before cutover.

If your Plesk DNS zones used custom templates (Plesk DNS Template), those record sets are imported as raw zone data. Panelica does not carry over the template abstraction itself — imported zones are treated as explicit records. You can rebuild template-style zone defaults under Settings > DNS Templates in Panelica after migration if you want consistent record sets across new domains going forward.

For email, update the MX record after verifying that mailboxes exist and are accessible on the Panelica side. Panelica auto-generates DKIM keys during the email import stage. SPF and DMARC records are handled via Email > Authentication in the Panelica panel. If you are connecting Panelica to Cloudflare for DNS management, the Cloudflare integration lets you sync and update zones without touching the Cloudflare dashboard directly.

MX cutover timing: if your TTL was already low (300 seconds) the old MX expires within minutes of the change. If your TTL was 86400 (the Plesk default for many zones), plan to keep the Plesk server's mail stack running for another 24 hours after you flip the MX, so messages in transit reach the right destination.

Plesk-specific gotchas: WP Toolkit, Smart Updates, Sitejet, and the Firewall extension

Every Plesk migration has at least one surprise. Here are the most common ones and how Panelica handles them:

Choosing your migration window

The right time to run a migration depends on the size of your Plesk setup and the traffic patterns of the hosted sites. For a small reseller with 5-10 subscriptions totaling a few gigabytes, any low-traffic window works fine. For a 30-subscription Plesk installation with around 25 GB of data, expect 2-4 hours of transfer time between servers in the same region. An 80-subscription setup in the 70 GB range runs 6-10 hours. For larger Plesk Partner configurations with 500 or more subscriptions, a phased approach works better — migrate 50-100 subscriptions per night over a week rather than attempting a single large run.

The Pause and Resume controls in step 4 make phased migrations practical. Start a large batch before midnight, pause before morning traffic picks up, and resume the next night. The checkpoint system means you never restart completed subscriptions.

Plesk's January 2026 pricing revision prompted a wave of operators to evaluate alternatives seriously. That context is relevant here because it means many Plesk users are evaluating not just Panelica but the full landscape of cPanel alternatives as well. If you are in that position, the Plesk alternatives guide covers six panels side by side, and the cPanel alternatives comparison provides a broader view of the market across eight options. For a look at what security concerns are driving cross-platform migration decisions in 2026, the cPanel 30-day security storm writeup is worth reading — the architectural questions it raises about legacy panels apply beyond cPanel itself.

If you are migrating from cPanel rather than Plesk, the process is nearly identical — see the cPanel migration walkthrough for the cPanel-specific version of this guide. For a broader view of how Panelica positions against traditional panels, see the Plesk comparison page and the full panel comparison index. The licensing cost analysis covers real per-account numbers if you are building a business case. And if you are evaluating the Git workflow side of Panelica as part of your agency or development toolchain, the Git Manager overview is a good complement to this migration guide.

The migration pipeline is designed to be a Plesk alternative that removes manual orchestration from the equation. No XML export files you manage by hand, no database dumps you schedule separately, no forgotten mail password resets. The wizard handles the orchestration and you get a verified, running copy of every subscription on the new server. The only decision left after step 5 is when to flip DNS.