Splitting an Addon Domain Into Its Own cPanel Account
Started one of your sites as an addon domain to save a few rupees a month, and now it's the one pulling all the traffic? At some point sharing resources, IP reputation, and PHP settings with the parent account stops making sense. Here's how to pull an addon domain out into its own standalone cPanel account without breaking mail or losing files.
Why you'd want to split it out at all
An addon domain isn't a second hosting account — it's a folder inside your main account that cPanel dresses up to look like one. That's fine when the addon site is small, but it causes real problems as it grows:
- It shares the parent account's CloudLinux LVE limits (CPU, entry processes, memory), so a traffic spike on the addon domain can starve the primary domain too.
- It shares the same PHP version and
php.iniunless you've gone out of your way to set a per-domain override in MultiPHP INI Editor. - It shares disk quota and inode count with everything else on the account.
- If the parent domain's mail server gets blacklisted, the addon domain's deliverability takes the hit too, even though it's a completely different brand.
- Billing and access control are messy — you can't hand a client or teammate their own cPanel login without giving them the whole account.
If any of that sounds familiar, it's time to give the addon domain a cPanel account of its own.
Before you start: what NOT to do
Don't just create a brand-new account and manually copy files over with FTP while the old site stays live. You'll end up with two live copies fighting over DNS, mismatched database credentials, and very likely a gap where mail bounces. Do it in order: new account first, content and mail moved and verified, DNS cut over last.
Step 1: Create the new hosting account
In WHM, go to Account Functions > Create a New Account and set the domain to the addon domain itself (not the parent domain). Give it its own username — don't reuse the parent account's username with a suffix, since that gets confusing fast during support tickets. Pick a plan with enough disk and bandwidth for what the addon domain is actually using; check current usage first under cPanel > Addon Domains or via du -sh on the addon's document root.
Step 2: Move the files
The addon domain's files live in a subfolder of the parent account's public_html, typically public_html/addondomain.com/. The cleanest way to move them is over SSH with rsync, run as root or through WHM's Terminal:
rsync -avz /home/parentuser/public_html/addondomain.com/ /home/newuser/public_html/If you don't have root/SSH access on your plan, zip the addon domain's folder in File Manager, download it, then upload and extract it into the new account's public_html. Either way, check file ownership afterward — files copied by an unprivileged process sometimes land owned by the wrong user, which then triggers 403 errors under CloudLinux's suPHP/LSAPI handler. Fix it with:
chown -R newuser:newuser /home/newuser/public_htmlStep 3: Move the database
In the parent account's phpMyAdmin, export the addon domain's database (Custom export, with structure, data, triggers, and routines checked — the default Quick export can silently skip triggers and views). In the new account, create a fresh database and user through MySQL Databases, then import the .sql file. Update the site's config file (wp-config.php for WordPress, or your app's equivalent) with the new database name, username, and password — they will not match the old ones.
Step 4: Move email — this is where people lose mail
Addon domain email accounts live under the parent cPanel account too, and they don't come along automatically. In the new account, recreate each mailbox under Email Accounts with the same addresses. Then, before you touch DNS:
- Have users temporarily set up the new mailbox as a second account in Outlook/Thunderbird so nothing is missed mid-transition.
- If there's mail you need preserved, use an IMAP sync tool (imapsync, or manually drag-copy folders in a mail client connected to both accounts) to pull messages from the old mailbox into the new one before cutover.
- Note the new account's mail server settings (usually
mail.addondomain.comonce DNS points there) so you can update devices right after the switch.
Do this migration step even if you think nobody actually uses that inbox — it's the single most common thing people forget, and the fallout (bounced client emails) shows up days later.
Step 5: Test before cutting over DNS
Don't point the domain at the new account yet. Test it first using a hosts-file override so only your machine sees the new site:
# On Windows: C:\Windows\System32\drivers\etc\hosts
# On Mac/Linux: /etc/hosts
203.0.113.10 addondomain.com www.addondomain.comReplace 203.0.113.10 with the new account's IP (find it in WHM's account list). Browse the site, log into wp-admin, submit a test form, place a test order if it's WooCommerce — anything that touches the database or sends mail. Remove the hosts entry once you're satisfied.
Step 6: Cut over DNS and remove the addon domain
Update the domain's A record (and any relevant CNAME/MX records) to point at the new account. If Getwebup manages the zone, do this in Zone Editor under the new account's DNS, or update it at the registrar if nameservers point elsewhere. Give it a few hours to propagate — check with dig addondomain.com +short from a couple of networks before assuming everyone's landing on the new server.
Only after traffic and mail have visibly moved to the new server should you go back to the parent account and remove the addon domain (cPanel > Addon Domains > Remove). Removing it deletes its DNS entries from that account and frees up its quota — but it does not touch the files unless you tick the option to delete them, so double-check that box's behavior before confirming.
Prevention: decide upfront, not after it's painful
| Signal | What it means |
|---|---|
| Addon domain gets more traffic than the primary domain | Give it its own account before an LVE limit on one site starts throttling the other |
| It needs a different PHP version than the parent | MultiPHP INI Editor can fake this short-term, but a dedicated account avoids the workaround entirely |
| A client or third party needs their own cPanel login | You can't scope access to just an addon domain — it needs to be a real account |
| The site is a different brand from the parent domain | Shared mail IP reputation means one brand's spam complaints can hurt the other's deliverability |
If this is a recurring pattern across your accounts — several addon domains that have all outgrown their parent — it's often cheaper to move to a small VPS where every site gets its own resource pool from day one, rather than running a string of separate shared accounts.
Frequently asked questions
Will splitting an addon domain into its own account change my hosting bill?
Usually yes — the addon domain moves from being covered under the parent plan to its own hosting plan with its own cost. Check current usage first so you don't over- or under-provision the new account.
Do I need to buy a new SSL certificate for the split-off domain?
No, AutoSSL will issue a fresh free certificate for the domain on its new account automatically once DNS points to it and the domain passes the HTTP validation check. It just won't be instant — allow up to a few hours after cutover.
What happens to the addon domain's old email addresses if I forget to migrate them?
They keep existing under the parent account until you remove the addon domain there. If you cut DNS over before recreating the mailboxes on the new account, incoming mail will start bouncing or silently routing to the old server depending on your MX setup — recreate mailboxes on the new account before changing DNS.
Can I split an addon domain without SSH access?
Yes. Use File Manager to zip and download the site files, phpMyAdmin to export/import the database, and cPanel's Email Accounts and Zone Editor for the rest. SSH with rsync is faster for large sites, but not required.
Is there a way to keep the same IP address after the split?
Generally no — the new account gets whatever IP is assigned to it (shared or dedicated, depending on your plan). If the domain has an SSL cert pinned to a specific IP for legacy reasons, flag that with support before migrating so it isn't a surprise after cutover.