A cheaper panel is a good reason to look at moving. A missing mailbox or a shop that stops taking orders is a good reason to stay. Before you leave cPanel, make a record of what each account runs and decide how you will prove it works on the new server. This checklist gives you that record, a test plan and a way back if the move fails.
It is for small hosting providers, resellers and agencies moving customer sites. You can use it with any destination panel. The ArcPanel section explains what to prepare if that is where you are heading.
1. Confirm who can move what
Start with access. A cPanel account, a reseller login and root access to WHM give you different ways to export and restore data. Ask the current provider which backups you can download and whether it will help with the final copy. Confirm access to the registrar and the authoritative DNS provider too; they may belong to your customer.
In cPanel, Backup can generate a full account archive when the host enables the feature. Restoring that full archive automatically requires WHM or the provider's help; the cPanel account interface cannot do it. cPanel also warns that an account near its quota may fail to produce a backup. Check free space before you start. See cPanel's backup documentation.
- Confirm who owns the hosting account, DNS zone and domain registration.
- Download a completed backup and keep a copy away from both servers.
- Agree on a maintenance window and tell customers what they need to test.
- Keep the source hosting active until you accept the new server.
2. Map every domain to the site it serves
One cPanel account can hold several websites. Copying only its main public_html folder can leave you with an incomplete move. Open Domains and record each name, its document root and its redirect. Those fields are listed in cPanel's Domains documentation.
Use a row for every main domain, add-on domain, subdomain and alias. Here is a fictional account to show the distinction:
| Name | What it serves | Check after the move |
|---|---|---|
example.com |
The main website | Pages, uploads and contact form |
shop.example.net |
A separate shop and database | Product pages, login and a test order |
staging.example.com |
A separate test site | Correct files and access restrictions |
www.example.com |
An alias or redirect | The expected destination and HTTPS |
Add the PHP version, required extensions, rewrite rules, custom error pages and background processes to each row. A page loading on the new server proves only that page works. Test the functions customers depend on, including uploads, password resets and payment callbacks.
3. Treat mail as a separate move
Decide whether mail is moving at all. If a customer uses an external mail provider, preserve its MX records while moving the website. If mail lives on the cPanel server, inventory it separately:
- Every mailbox, its quota, used space and folders.
- Forwarders, aliases, catch-all behavior, filters and automatic replies.
- The server names and ports customers use in their mail apps.
- Website forms and applications that send through SMTP.
- The plan for mailbox passwords, including resets if the chosen transfer method cannot preserve them.
Plan an initial copy and a final synchronization for messages that arrive during the move. Test folders and older messages as well as the inbox. Send mail to an outside address, reply from it, and check delivery in both directions.
Record SPF, DKIM, DMARC and reverse DNS before changing the sending server. Check them against the destination's settings before it sends customer mail. cPanel's Email Deliverability guide explains these records and distinguishes local mail from third-party services.
4. Match databases to applications
For each application, record the database name, database user, server version, character set and collation. Keep credentials in your password manager. Export a fresh database dump and test importing it on the destination before the maintenance window.
Check the application's connection settings after import. Account prefixes, database names or users may differ on the new panel. In ArcPanel, database names and database users receive the account name as a prefix: shop under alice becomes alice_shop. The database guide covers naming, imports and connection settings.
For a shop, booking system or forum, agree when writes will stop on the old server. Take the final database copy after that point. An earlier test copy cannot contain orders or posts created later.
5. Copy the jobs that run when nobody is watching
Record cron schedules, commands, working directories, PHP paths and the server time zone. Include queue workers, application processes and scripts that send invoices or clean up files. Check integrations that allow only your old server's IP address.
Rewrite paths for the destination account and runtime. ArcPanel cron jobs run as their owner and follow the server's clock. Its cron guide recommends the full path of the intended PHP version.
Give each job one active home during the switch. If both servers run the invoice job, customers may receive duplicate invoices. Keep destination jobs paused until you are ready to hand them over, then check the next scheduled run.
6. Plan DNS and HTTPS before switching traffic
Record the authoritative name servers and the full DNS zone. Include A and AAAA records, aliases, MX, TXT verification records and any service-specific entries. A forgotten IPv6 record can still direct visitors to the old server after you change IPv4.
- Decide whether you are changing individual records or moving the whole DNS zone.
- If you lower TTLs, do it early enough for the previous TTL to expire before the switch.
- Prepare HTTPS for every public name and decide how certificates will be issued or transferred.
- If DNSSEC is enabled and DNS hosting changes, coordinate the registrar's DS record with the new DNS provider.
- Keep a copy of the old record values and record each change you make.
When moving to ArcPanel, DNS can stay at an external provider. Its mail and DNS guide covers both arrangements, external mail templates and the records you need. Creating a zone inside a panel does not change which name servers the registrar delegates to.
7. Rehearse one account on the destination
Choose a small account with the kinds of sites you actually host. Include an add-on domain and a mailbox if your customers use them. Restore or copy it to the new server, test it with the original hostnames through a local DNS override, and write down every adjustment.
ArcPanel installs on a fresh supported Debian or Ubuntu server with an amd64 processor. Prepare a separate server rather than running the installer over the cPanel machine. Check the current requirements before ordering it.
ArcPanel includes a cPanel backup importer. The project's broader check of add-on domains, subdomains and mail transfers is still pending as of 26 October 2026. Use a rehearsal to establish what works for your accounts. This checklist does not promise that importing an archive recreates every setting.
Map each site to an ArcPanel web domain or alias, select its runtime and template, and compare it with the inventory. The web domains guide explains aliases, custom document roots, PHP versions and templates. Check reseller ownership and package limits too if customers manage their own accounts.
8. Set the acceptance checks and the way back
Before switching DNS, name the person who accepts each account and the conditions that would make you return traffic to the old server. Use this list for the rehearsal and again after the final copy:
- Every domain, alias and redirect reaches the intended site over HTTPS.
- Logins, uploads, forms and a test transaction work.
- Applications connect to the right databases and contain the final data.
- Mailboxes contain the expected folders and messages; inbound and outbound mail work.
- Cron and workers run once, on the intended server, at the expected time.
- Customers can sign in and see only the accounts they should manage.
- A destination backup has completed, an off-server copy exists, and a restore has been tested.
Write the switch order: pause application writes and old jobs, make the final copies, verify the destination, change the planned DNS records, then enable destination jobs and writes. Keep checking both servers for traffic and mail while DNS caches expire.
Keep the old server until the account owner accepts the move and your agreed observation period has passed. On ArcPanel, use the backup guide to test a restore and keep a copy outside the server.
Make the first move small
Your next step is one completed inventory and one rehearsed account. Those give you a basis for estimating the rest of the move. If a required integration or transfer fails, resolve it before committing customers to a date.
Want help reviewing the move? Ask about a cPanel migration with your account count, domain count, mail setup and required integrations. Share the inventory through an agreed secure channel; leave passwords and backup archives out of the initial message.
