Migrate cPanel accounts to InterWorx with mass transfer

InterWorx ships a built-in cPanel importer that pulls account backups over SSH and restores them as SiteWorx accounts. For the standard end-user account — files, databases, mail, DNS, SSL — it works cleanly. For everything around the edges (WHM resellers, Softaculous installations, custom cron, SpamAssassin scoring) you either lose data or need an adjacent workflow.

This guide runs the full mass import, then enumerates what does not migrate and how to handle each case. Considering InterWorx in the first place? Read the InterWorx vs cPanel comparison.

Prepare the InterWorx server

Install InterWorx on the target box and activate the license. Make sure the target has at least as much disk as the sum of source account home directories plus 30% headroom for the temporary tarballs the importer writes to /home/interworx/import/ during the run.

Generate an SSH key on the InterWorx server for root, and add the public key to /root/.ssh/authorized_keys on the source cPanel server. The importer authenticates as root over SSH to invoke pkgacct and stream backups across:

ssh-keygen -t ed25519 -N ''
ssh-copy-id root@source-cpanel.example.com
ssh root@source-cpanel.example.com 'echo ok'   # verify

Run the mass import

In NodeWorx go to SiteWorx Accounts → Import → cPanel. Enter:

• Source server IP or hostname — the cPanel box
• SSH port (22 default)
• Root SSH key path — usually /root/.ssh/id_ed25519

InterWorx connects and lists every cPanel account. Tick individual accounts or Select all for a bulk transfer. Start the import.

For each account InterWorx runs pkgacct remotely, streams the resulting cpmove-<user>.tar.gz, then restores it into a fresh SiteWorx account with the same username, password hash, primary domain, mail, DNS zone, and database. Throughput is typically 1-2 accounts per minute on a 1 Gbps link, dominated by pkgacct runtime on the source. A 500-account migration runs overnight.

If a single account fails (corrupt backup, oversize home directory, character-set issues in MySQL), InterWorx logs it and moves on. Re-run failed accounts individually after addressing the root cause. Logs land in /home/interworx/var/log/import/.

DNS and SSL

DNS zones come across — they end up as SiteWorx zones on InterWorx's bundled DNS. Update the NS records at the registrar to point at the new InterWorx server, or set the InterWorx server as a slave to the existing NS infrastructure during the transition. AutoSSL (Let's Encrypt) certificates do not migrate; InterWorx reissues via its own Let's Encrypt integration once DNS points at the new server.

What does not migrate

The importer covers SiteWorx-shaped data. The following do not, and need a separate workflow:

WHM reseller accounts

InterWorx has no first-class "reseller" concept the same way WHM does. Reseller hierarchies collapse: each child account becomes a top-level SiteWorx account in your single NodeWorx, and the reseller itself becomes — at best — a single SiteWorx with a NodeWorx-Reseller role. For multi-reseller estates, plan to consolidate into one reseller or migrate each reseller's accounts as a separate import to a separate NodeWorx tenant.

Softaculous installations

The on-disk app files migrate (they live in the home directory and tar up like anything else), but the Softaculous installation registry does not. Customers' WordPress sites still run, but neither InterWorx-side Softaculous nor end users can manage them through the panel — updates appear as "unmanaged installations".

Fix: install Softaculous on the InterWorx server, then in Softaculous admin run Remote Import pointing at each restored account. Softaculous scans the home directory, detects known apps, and re-registers them. Budget 5-10 minutes per 100 accounts.

Custom cron entries

User crontabs migrate. System-level cron entries that cPanel installed in /etc/cron.d/ (for example custom backup scripts placed there by your ops team) do not — InterWorx restores the user-scoped crontabs only. Audit /etc/cron.d/ and /etc/cron.daily/ on the source for anything you need to recreate.

SpamAssassin scores and Bayes data

SpamAssassin per-account scoring thresholds migrate as part of the user config. Trained Bayes databases (~/.spamassassin/bayes_*) usually do — they sit in the home directory — but legacy cPanel installs put them elsewhere. Verify post-import that sa-learn --dump magic returns sensible token counts; if not, customers need to retrain.

Server-level customisations

Apache config tweaks, PHP php.ini overrides at the server level, custom MTA routing — none of this migrates. The importer handles account-scoped data only. Inventory anything that lives outside /var/cpanel/users/ or /home/<user>/ on the source and recreate on the target.

Cut over

Once a test cohort works, point DNS for affected domains at the new InterWorx IP. With a low TTL set 24 hours ahead, the cutover is propagation time only. Run a final delta import for accounts that received changes during the migration window. Keep the cPanel server reachable on an internal hostname for 30 days for support escalations.

Next steps

• Understand which backup format the importer accepts: cPanel backup format for InterWorx.
• Compare the panels side-by-side: InterWorx vs cPanel.
• Activate the target server's InterWorx license.