Migrating 100 Domains from cPanel to KubePanel: Step-by-Step

Migrating a large cPanel server is a project, not a task. Moving 100 domains means 100 databases, 100 filesystems, hundreds of email accounts, and dozens of DNS zones — and none of it can go wrong while your customers' sites stay live. This guide walks through KubePanel's built-in cPanel migration tool: how to connect to your WHM server, select domains in bulk, let the tool handle all the data transfer automatically, and cut over DNS with minimal downtime.

How the Migration Tool Works

When you start a migration in KubePanel, the platform spins up a dedicated migration receiver in the cluster: a Kubernetes Job with an embedded SFTP server. Your cPanel server pushes full account backups directly to this receiver via SCP. From there, the migration worker extracts each backup and imports the components — files, databases, email — into the new infrastructure. Domain accounts in KubePanel are created automatically as part of this process.

You never touch rsync, mysqldump, or imapsync manually. The tool handles all of it.

Before You Start: Preparation Checklist

• Create a WHM API token. In WHM, go to Development → Manage API Tokens. Create a token with access to backup and account management functions. You'll enter this in KubePanel.
• Inventory your domains. Know which sites are WordPress, which have large databases, which have heavy email usage. This helps you prioritize the migration order and set appropriate resource limits.
• Lower DNS TTLs. At least 24 hours before any DNS change, lower TTLs to 300 seconds (5 minutes). This minimizes propagation delays when you cut over.
• Set email DNS records early. KubePanel creates DKIM keys automatically. Add the DKIM, SPF, and DMARC DNS records for each domain 24–48 hours before cutover to ensure email deliverability isn't interrupted.

Step 1: Connect to Your cPanel Server

In KubePanel, navigate to Migration → New Migration. Enter your WHM server credentials:

• Hostname: Your cPanel server IP or hostname
• Port: WHM port (default 2087)
• Username: WHM account (typically root or a reseller account)
• API Token: The token you created in WHM

KubePanel connects to WHM, verifies the credentials, and discovers all hosted accounts on the server. This typically takes a few seconds.

Step 2: Select Domains and Configure Migration Options

You'll see a list of all domains discovered on the cPanel server. For each domain you want to migrate, configure:

• Target Owner: Which KubePanel user will own the migrated domain
• Target Package: Optional resource quota package to assign
• Database: Select the database to import (or skip if the site has no database)
• Email Accounts: Select which mailboxes to migrate
• Email Method:
  • From Backup — migrates mailbox contents from the cPanel backup archive (recommended for most cases)
  • Live IMAP Sync — syncs live mailboxes while both servers are running (useful to catch mail received after the backup)
  • Skip — migrate files and database only, skip email

You can select and configure all 100 domains on this screen, then start the migration in one batch.

Step 3: Start the Migration

Click Start Migration. KubePanel:

1. Provisions an SFTP receiver in the cluster (a Kubernetes Job with an embedded SFTP sidecar)
2. Triggers a full cPanel backup for each selected account via the WHM API
3. cPanel pushes the backup archives directly to KubePanel's SFTP receiver via SCP
4. The migration worker processes each account in sequence:
   • Creates the domain in KubePanel (Domain CR, namespace, PVC, MariaDB database)
   • Extracts the site files from the backup and restores them to the domain's storage
   • Imports the selected database (SQL dump extracted from backup, credentials updated automatically)
   • Imports email accounts and restores mailboxes from the backup's Maildir format
   • If Live IMAP Sync was selected: runs an incremental IMAP sync to catch any mail received after the backup

For WordPress sites, KubePanel automatically updates wp-config.php with the new database host, name, username, and password — no manual editing required.

Step 4: Monitor Progress

The migration dashboard shows real-time progress for each domain. Each domain moves through these stages:

Stage	What's Happening
Queued	Waiting for its turn in the batch
Fetching	cPanel backup being triggered and pushed to KubePanel
Creating	Domain account created in KubePanel (namespace, PVC, database)
Importing Files	Site files extracted from backup and written to domain storage
Importing Database	SQL dump imported into MariaDB, credentials updated
Importing Mail	Email accounts created, mailboxes restored
Syncing Mail	Live IMAP sync (if selected), catching new mail
Completed	Domain fully migrated and running on KubePanel

If a domain fails at any stage, the error is shown in the dashboard with details. Other domains in the batch continue running — a single failure doesn't block the rest.

Step 5: Validate Before Touching DNS

Before you change any DNS records, test each migrated site using a local hosts file override:

# On your local machine, add to /etc/hosts:
<kubepanel-ingress-ip> example.com www.example.com

Browse to the site. Check that the homepage loads, assets render, and database-driven functionality works. For WordPress, confirm admin login and WooCommerce checkout if applicable. Let's Encrypt certificates are issued automatically — SSL should be active from the first request.

Only after validation do you change DNS.

Step 6: Cut Over DNS

Update the domain's A record to point to the KubePanel cluster's ingress IP. With a 5-minute TTL set 24 hours earlier, propagation is fast. Monitor with:

watch dig +short example.com

Once the new IP propagates, your site is live on KubePanel. Keep the cPanel server running for at least 48 hours after cutover — don't delete anything until you're confident the migration is stable.

Recommended Migration Strategy for 100 Domains

Don't migrate all 100 domains at once on day one. A phased approach lets you catch problems early:

Phase	Domains	Goal
Test batch	5 low-traffic sites	Prove the process end-to-end, validate DNS cutover
Batch 2	20–25 simple PHP/WordPress sites	Build confidence, run in parallel with test batch validation
Batch 3–5	Remaining sites	High-traffic and complex sites migrated last, during off-peak hours

What Changes Operationally After Migration

Once you're fully on KubePanel, the operational model is different from cPanel:

• No more server-level PHP management. PHP version per domain is a configuration change — select the version in the domain settings, the container image swaps automatically.
• Hardware failure is handled automatically. A node failure triggers Kubernetes rescheduling. You get an alert but rarely need to act urgently.
• Resource complaints are diagnosable. The monitoring dashboard shows exactly which domain is consuming CPU or memory — no guessing.
• Backups are per-domain. VolumeSnapshot of the domain's PVC plus a mysqldump. Restoring one domain doesn't touch others.
• No more per-account licensing fees. KubePanel is flat-rate per tier, regardless of how many domains you run within that tier.