A cPanel migration carries less risk when you treat it as a fixed sequence and not as one big step. You record what the old account does, create a backup package, test the import with a dry run, import, check the result on the new server, and only then change DNS. The old account stays online until you are satisfied. The same order works for a move from cPanel to another control panel.
This guide shows how to migrate from cPanel to PFHW and, more generally, how to move from cPanel to another control panel, the control panel of our Managed Web Server. It covers how to create the package on the cPanel side, what the PFHW importer does, what it does not bring across, and how to go back if something is wrong. Where we have not verified a detail, we say so.
What a cPanel backup package contains
cPanel can produce two kinds of files that people call a backup. The first is a full account package, often called a cpmove file. The second is the Backup Wizard output, which a cPanel user can create without server administrator rights. They are not the same thing, so choose on purpose.
The cpmove package from pkgacct
The cPanel documentation describes the pkgacct script as the tool that creates a cpmove archive for one account. It is run as the root user and takes the account name and an output directory. If you give no directory, it uses the home directory with the most free space. The archive is compressed by default.
From the options that pkgacct can skip, you can see what a package normally includes: the home directory, databases and database users, mail and mail settings, mailing lists, DNS zones, DKIM keys, domains, FTP accounts, cron jobs, logs, SSL files, shell settings, disk quota and reseller settings. The cPanel page also says that two-factor authentication settings are not transferred, so each user sets up two-factor login again on the new system.
The Backup Wizard full backup
The cPanel Backup Wizard creates a full backup as a compressed tarball named by date. You can send it to the home directory, or to a remote server by FTP or SCP. The cPanel documentation states that a full backup cannot be restored in the wizard itself. It also says the home directory part holds only files that the user owns or can access, and that a full backup can fail when an account is at or over its disk quota.
In practice, when you migrate from cPanel and have root access or a host that will run pkgacct for you, use the cpmove package. PFHW documents import for cPanel backup packages in the cpmove form. We have not stated that every Backup Wizard file is accepted. The dry run described below will show you what the importer makes of a file before it changes anything.
Before the cPanel migration: a checklist
Most cPanel migration problems come from things nobody wrote down. Spend time on this list first. It costs little and it is the main protection against a surprise after the cut-over. The list combines the cPanel documentation with a published migration checklist from a hosting company.
| Item | What to record | Why it matters |
|---|---|---|
| DNS records and TTL | All records of each domain (A, AAAA, MX, TXT, CNAME) and their current TTL values. | Resolvers keep a record for the TTL time. A shorter TTL set early means the new address is picked up sooner at cut-over. |
| Cron jobs | Every scheduled command, its schedule and the paths it uses. | Paths and PHP versions can differ on the new server. Check that each job runs after the move. |
| Mailboxes, forwarders, autoresponders, filters, spam-filter settings and mailing lists. | Some of these are not imported by PFHW. See the table later in this guide. | |
| SSL certificates | Each certificate, its private key and the chain, including purchased ones. | PFHW does not issue certificates automatically. Plan to upload or buy a certificate for each domain. |
| PHP versions | The PHP version and the extensions each site needs. | PFHW sets PHP versions per domain, so you can keep an old site on the version it needs. |
| Databases | Database names, users, sizes, and which are MySQL or PostgreSQL. | PostgreSQL databases are imported only when the chosen plan allows PostgreSQL. |
| Two-factor login | Which users have it enabled. | cPanel does not transfer it. Each user sets it up again. |
Then lower the TTL. A published checklist advises lowering it well before the cut-over and waiting at least as long as the old TTL before you move. Write down the original values so you can restore them when the move is stable. We do not give a number of hours, because the right value depends on the TTL you start with.
Step 1: create the package on the cPanel server
Check disk space first. The cPanel documentation says free space must be greater than twice the size of the largest account, plus an additional 1 GB. Then run the script as root. The syntax from the cPanel documentation is:
/usr/local/cpanel/scripts/pkgacct USERNAME /path/to/output-directory
The result is an archive for that one account. Copy it off the server to a place you control. Keep a second copy until the migration is finished. Repeat for each account you want to move.
Look at the size of the file. The PFHW portal accepts uploads of up to 2 GB per package. A larger package must be imported with the command-line tool on the PFHW host. The cPanel script also has options to leave out parts, for example the home directory. We have not verified how the PFHW importer treats a package without its home directory. If you consider that route, test it with a dry run first. A site can also be uploaded by SFTP or Git.
Step 2: run the dry run in PFHW
The PFHW importer starts with a dry run. It reads the package and shows the changes it would make, and it makes none. Use the dry run on every package, even small ones. Read the output with your checklist next to it: are all domains, databases and cron jobs there, and does anything appear that you did not expect?
You can start the import from the portal, or with the command-line tool pfhw-import-cpanel on the host. The portal limit is 2 GB per package. See the PFHW help for the options of the command-line tool.
Step 3: run the import and choose the options
When the dry run looks right, run the real import. The importer offers these choices:
- Plan: the PFHW plan that the imported account will use.
- Customer: create a new customer, or use an existing one.
- Import DNS zone: bring the zones of the account into the PFHW DNS.
- Overwrite existing account: replace an account that already exists. Existing passwords are kept.
- Keep package: keep the uploaded package file after the import.
- Import mail: available when a mail server is connected to the panel.
Two behaviours matter. First, the importer shows new passwords once, so copy them at that moment. Imported accounts get a temporary password that must be changed at first login. Second, a failure rolls back the whole import. You do not end up with a half-built account that you must clean up by hand.
Step 4: check the result before you change DNS
Test the new site while the domain still points to the old server. You can do this by testing from a machine whose hosts file points the domain to the new server address, or by using a temporary address. Our documentation does not describe a built-in preview address, so we recommend the hosts-file method as general practice.
- Open every site and its main pages. Test forms, logins, uploads and the shopping cart.
- Check the PHP version of each domain and the error log.
- Check that databases are present and that the application connects. Update the database host in the application configuration if it changed.
- Run each cron job once and compare the result with the old server.
- Check the certificate of each domain. If none is installed yet, upload one or buy one before the cut-over.
- Send and receive a test email if you imported mail, and check that SPF, DKIM and DMARC records match the new setup.
Step 5: the DNS cut-over of a cPanel migration
When all checks pass, change the DNS records so the domain points to the new server. If you use the PFHW DNS, change the nameservers at your registrar. If you keep DNS elsewhere, change the A and AAAA records there. Lower the TTL as described in the checklist before this step and do the change in a quiet period for your site.
Mail needs extra care. Mail can arrive on either server while DNS changes spread, so plan a last mailbox sync after DNS has settled. After the change, watch the new server. Check the sites, the mail flow and the logs. Raise the TTL back to its normal value only when everything is stable.
The cPanel documentation gives one relevant warning for its own live transfer feature: update DNS before you remove accounts from the old server. The same principle applies here. Do not delete anything on the old server until DNS points to the new one.
The rollback path
You have three layers of protection. Each one covers a different moment.
- During the import: the PFHW importer rolls back the whole import if it fails.
- Before the cut-over: the old cPanel account is untouched. If a check fails, you stop, fix the cause, and import again. The overwrite option replaces an existing account and keeps its passwords.
- After the cut-over: keep the old account and your package copy. If the new site misbehaves, point the DNS records back to the old server. Because you lowered the TTL, the change spreads quickly. Data that users created on the new server in the meantime, such as orders, is not copied back automatically. Plan for that case.
Keep the old server and the package files until the new setup has run through your normal business cycle, for example a full month-end. How long you wait is your decision. We do not set a number.
What the cPanel migration does not bring across
A cPanel migration is only honest if you know the gaps in advance. These items are not imported, or exist differently in PFHW.
| cPanel item | In the PFHW import | What to do |
|---|---|---|
| Mailing lists (Mailman) | Not imported. The importer reports them as not imported. PFHW has no mailing-list feature. | Move the lists to a separate mailing-list service before the cut-over. |
| Autoresponders | Not in the PFHW portal and not imported. | Recreate them in the mail server's own pages, if it offers them. |
| Email filters | Not in the PFHW portal and not imported. | Recreate them in the mail server's own pages. |
| Spam-filter settings | Not in the PFHW portal and not imported. | Set them again in the mail server. |
| Automatic certificates (AutoSSL) | PFHW has no automatic certificate issuing. | Upload a certificate for each domain, or buy one from us. |
| Two-factor login | Not transferred by cPanel. | Each user enables it again in PFHW. |
| Dedicated IP per account | PFHW uses the shared server addresses (IPv4 and IPv6). | Check whether any service depends on a dedicated IP. |
| Other items | Not verified here. | The dry run shows the changes it will make. Compare it with your checklist. |
Email is a special case. In PFHW, email is a separate add-on on its own Mailcow server, and webmail is the mail server's own and not part of PFHW. The import-mail option works when a mail server is connected to the panel. If you use a different mail provider today, you may not need to move mail at all.
Where PFHW fits, and where it does not
PFHW fits a cPanel migration when you want to move cPanel accounts onto a managed server and keep a familiar structure of accounts, domains, databases, DNS and backups. Our server plans have no limit on sites or accounts in the control panel, and after a demo a trial server can be set up, so you can try the import before you commit. The dry run and the full rollback on failure reduce the risk of the technical step.
It does not fit every case. There is no server-to-server transfer tool like the cPanel Transfer Tool: accounts come in as a package file. Mailing lists, autoresponders, email filters and spam-filter settings are not imported. There is no AutoSSL, no per-account dedicated IP and no hotlink protection. The portal is in English only. If one of these is a hard requirement, test it first. Before you migrate from cPanel, decide whether the gaps are acceptable, because a move to another control panel changes what your clients can use.
Frequently asked questions
How do I start a cPanel migration and create a cpmove file?
If you have root access, run the pkgacct script with the account name and an output directory. The cPanel documentation describes this script as the tool that creates the cpmove archive. If you are a cPanel user without root access, ask your host to run it for you, or use the Backup Wizard and test the file with a dry run.
Can I test the import without changing anything?
Yes. The PFHW importer starts with a dry run that shows the changes it would make. Nothing is imported at that stage. Run it for every package before the real import.
What happens if the import fails?
The whole import is rolled back. You then fix the cause shown in the output and run it again. The import reads a package file and does not change the old server, which is the main safety net when you move from cPanel to another control panel.
My package is larger than 2 GB. What now?
The portal accepts up to 2 GB per package. For larger packages, use the command-line tool pfhw-import-cpanel on the PFHW host. A site can also be uploaded by SFTP or Git.
Are mailing lists and autoresponders moved?
No. The importer reports mailing lists as not imported, and autoresponders, email filters and spam-filter settings are not imported either. Rebuild them in another service or in the mail server before the cut-over.
When do I change DNS in a cPanel migration?
After the new server passes your checks, and after you have lowered the TTL and waited at least as long as the old TTL. Keep the old account until the new setup is stable, so you can point DNS back if needed.
Related resources
- cPanel alternatives in 2026
- Managed cPanel compared with managed PFHW
- Website backup strategy
- Web hosting control panels guide
Sources
- The pkgacct Script, cPanel documentation
- Backup Wizard, cPanel documentation
- Backup for cPanel, cPanel documentation
- Transfer or Restore a cPanel Account, cPanel documentation
- Transfer Tool, cPanel documentation
- Server migration checklist for hosting resellers moving cPanel accounts (2026), Cloudhouse Technologies
- Managed Web Server, CloudAcropolis (PFHW import behaviour)