Bring your accounts over without a download in the middle.
Point Nimbopanel at your old server over SSH, or hand it a backup you already have. Either way it recreates the whole account — isolated, on your new server, with passwords intact.
Pick the one that suits your access
Server to server, over SSH
Give Nimbopanel the old server's address and a login. It asks the old panel to build a fresh backup, then streams it across directly — nothing passes through your laptop, so a twenty-gigabyte account is no harder than a small one. The transfer runs in the background and reports its progress; if it fails, it leaves nothing behind.
It can also stream an archive that is already sitting on the old server, instead of asking for a new one to be built.
Upload a backup you already have
A standard full-account backup — the cpmove or pkgacct archive cPanel already produces — can be uploaded from the panel. Useful when the old server is already gone, or when SSH to it is not yours to give.
Either route lands in the same place: a preflight that tells you exactly what is inside, and then one click.
The SSH route asks you to confirm the old server's key fingerprint before anything is transferred, and the credentials you type are used for that one transfer and never stored.
Pull and import in a single click
Tick “Import automatically” when you start an SSH transfer, and Nimbopanel does not just fetch the backup — it runs the whole import the moment the archive lands. No preflight step, no second click: the account, its files, databases, mailboxes and DNS are recreated for you, and the panel reports “Migrated — account X created” when it is done. Prefer to look first? The connect → preflight → import path is still there for when you want to inspect an archive before it lands.
Four steps, zero drama
Connect or upload
Enter the old server over SSH and confirm its fingerprint, or upload a cpmove / pkgacct archive from the panel.
Preflight
Nimbopanel reads the archive and reports exactly what will be imported: domains, databases, mailboxes, sizes — and anything it cannot bring across, named rather than dropped.
Import
One click recreates the account: isolated Linux user, files, databases and their users, mailboxes with their stored messages, DNS zone, addon and parked domains, and the PHP version the site was on.
Verify & switch
Test the site and mail on the new server, then point DNS. Passwords and app configs already match, so nothing needs re-typing.
Your .htaccess comes with you
WordPress permalinks, Laravel and Symfony routes, a security plugin's rules, a cache plugin's rules — all of them live in .htaccess, and all of them are written by software long after the move is over.
Detected during the import
If an account carries directives that cannot be reproduced on the faster nginx path, that account is created with a real Apache behind nginx. It happens automatically, and it happens per site — you are never asked a question you would need to research first.
Only where it is needed
A site that never touches .htaccess keeps the single, faster hop. On a server where no account needs Apache, no second web server runs at all.
Nothing else changes
PHP still runs as the account's own Linux user, and HTTPS still terminates at nginx — so certificates, renewals and isolation are exactly as they were.
Or see what would be translated
Prefer the nginx path? The panel converts what it can and lists, line by line, the directives it could not — so you decide, instead of finding out from a visitor.
Your customers won't notice — in a good way
The importer keeps the details that break lesser migrations.
Passwords kept
Database-user and mailbox passwords are preserved (hashes migrated), so apps and email clients keep logging in.
Same database names
Because the account keeps its cPanel username, database names line up — wp-config.php and friends work unchanged.
Email + old messages
Mailboxes, forwarders and the actual stored messages come across into the recreated mailbox.
Domains + DNS
Addon domains, subdomains, parked domains, and DNS zone records are recreated.
The PHP version the site was on
A site written for PHP 7.4 lands on PHP 7.4, in its own pool. Versions from 5.6 to 8.5 are available, chosen per account.
A boundary around the archive
A backup from another server is untrusted input. Paths are sanitised, only ordinary files are considered, size and file counts are capped, and nothing inside is ever executed.
Honest note: accounts are moved one at a time, and anything the archive holds that Nimbopanel has no home for is listed in the report rather than quietly dropped — you always see exactly what was and was not imported.
How your current setup maps to Nimbopanel
Every part of a traditional cPanel and WHM stack has a home here — often several separate products folded into the panel itself.
| Your current setup | In Nimbopanel |
|---|---|
| WHM (server administration) | The operator dashboard — accounts, plans, quotas, security and mail, all from one place. |
| cPanel accounts | Isolated accounts, each its own Linux user and PHP-FPM pool, walled off from every other. |
| EasyApache and MultiPHP | Per-site PHP from 5.6 to 8.5, chosen per account and running in its own pool. |
| AutoSSL | Let’s Encrypt AutoSSL for every domain — www and mail included — issued and renewed for you. |
| Account backups | Scheduled and off-server backups, with granular restore of single files, one database, mail or cron. |
| WHMCS for client billing | NimboBilling, built into every paid plan — invoices, tax, tickets and multi-gateway checkout, at no extra licence. |
| Per-account licensing | Per-server licensing — add as many hosting accounts as your server can handle, with no per-account tax. |
A plain mapping, not a scorecard — these are simply the Nimbopanel equivalents of the pieces you already run.
Ready to switch?
Start free, bring one account across, and see how clean the move is before you commit.