Migrating from WHMCS
Before you start
You'll need:
- A WHMCS install between 7.0 and 9.x. Older or newer versions aren't supported — ask our support if you're outside that range.
- A full SQL dump of your WHMCS database.
- Admin access to your WHMCS install, so you can reconcile counts against the pre-flight report.
- Access to the same Stripe and PayPal accounts your WHMCS install charges through, if you want saved payment methods to keep working. See Payment methods.
You do not need to take WHMCS offline. Keep billing running there until you approve the migration and switch over — and if anything changes in the meantime, a top-up migration brings it across.
Taking the dump
Either method works. Use the command line if you have shell access, because it's faster, handles large databases better, and takes a consistent snapshot.
From the command line
From a shell on the server that hosts your WHMCS database:
mysqldump --single-transaction --quick \
-u YOUR_DB_USER -p YOUR_DB_NAME \
| gzip > whmcs-migration.sql.gz
--single-transaction gives you a consistent snapshot without locking the
tables, so this is safe to run on a live install.
Using phpMyAdmin
If you're on shared hosting without shell access, you can export from phpMyAdmin instead (in cPanel, it's under Databases → phpMyAdmin).
- Select your WHMCS database in the left-hand sidebar. If you're not sure
which one it is, the name is the
$db_namevalue in your WHMCSconfiguration.php. - Open the Export tab.
- Set Export method to Custom.
- Set Format to SQL.
- Under Tables, make sure every table is selected. That's the default, so leave it alone. A partial export is the most common cause of mismatched counts.
- Under Output, choose Save output to a file and set Compression to gzipped.
- Under Format-specific options, set Dump table to structure and data.
- Click Export and save the
.sql.gzfile.
phpMyAdmin exports one table at a time rather than as a single snapshot, so run it during a quiet period, not in the middle of your cron run or a renewal batch. On large installs it can also hit your host's time or memory limits and produce a truncated file. If your pre-flight counts come up short, that's the likely cause: use the command line or ask your host for a full database backup instead.
What comes over
Migrated live and exact
These touch active billing, so they're reproduced precisely:
- Users & Clients
- Active products and services
- Active subscription billing state — next due dates, billing cycles, and recurring amounts
- Saved Stripe and PayPal payment methods
- Recent and open tickets
- Account credit balances
Migrated as read-only history
Preserved so you and your customers can look back, but frozen — you can't edit or re-issue these:
- Invoices
- Payment history
- Closed tickets
Set up fresh in HostCore
Things that don't translate cleanly, and are better rebuilt than force-fitted:
- Settings — HostCore's configuration model doesn't map one-to-one onto WHMCS's
- Branding — logos, colours, and portal styling
- Email templates — HostCore uses a different template syntax
- Gateway credentials — you connect your own Stripe and PayPal accounts
- Modules
Never migrated
- Raw card numbers — see below
Payment methods
Saved Stripe and PayPal payment methods come over. If WHMCS charges a customer through Stripe or PayPal, the gateway token for their card or PayPal account migrates with them. Their next renewal in HostCore charges it automatically — the customer doesn't need to do anything.
Raw card numbers never do. Some WHMCS versions store card numbers in their own database rather than with a payment gateway. We will not accept, decrypt, or process that data under any circumstances. HostCore uses redirect-based checkout with Stripe and PayPal; raw card data never reaches our servers. Customers whose card is stored that way will need to add a payment method in HostCore before their next renewal.
Connect the same gateway accounts
A Stripe or PayPal token only works inside the account that created it. Connect the same Stripe account and the same PayPal business account your WHMCS install uses. Connect a different account and every migrated token will fail at renewal.
Tokens aren't checked on import
There's no way to confirm a saved card still works without charging it, so we don't try. Tokens come over exactly as WHMCS had them. If a card has expired, or the customer removed it from their account, it will fail at their first renewal in HostCore and go through normal failed-payment handling — the same thing that would have happened in WHMCS.
What this means in practice
- Connect the same Stripe and PayPal accounts before you approve.
- Email customers whose card was stored in WHMCS itself and tell them they'll need to add a payment method. Don't let the first they hear of it be a failed payment notice.
- Expect a few failures on the first renewal cycle from expired or removed cards. That's WHMCS's data, not a migration fault.
Passwords carry over
Your customers keep the passwords they already use. HostCore reads WHMCS's bcrypt hashes directly and re-hashes each one to our format (Argon2id) the first time that customer logs in.
No mass password reset. No "we've migrated, please set a new password" email.
How a migration runs
Upload your dump
On your hostcore.co dashboard, go to Migrations and upload your compressed
WHMCS dump (.sql.gz).
We restore it in an isolated sandbox
Your dump is restored into a disposable database instance with no network access at all. It can't reach the internet, your store, or any other tenant. When the migration finishes, the sandbox and everything in it is destroyed.
Pre-flight count ledger
We read your data and count everything: how many clients, how many active services, how many invoices, how many tickets. You get these counts before anything is written, so you can compare them against the numbers in your WHMCS admin area and catch a bad dump early.
You review and approve
The pre-flight report is a plain-language summary of exactly what will move, what will be frozen as history, and what you need to set up yourself. Every line links to the records it covers.
Nothing is written to your live store until you approve this report. If the numbers look wrong, cancel — nothing has happened yet.
Staged commit
On approval, records are written in dependency order — clients before services, services before subscriptions — and committed atomically. If the process is interrupted, it resumes safely from where it stopped without duplicating anything.
Final report
You get a closing report with the final counts and the list of set-up items still outstanding.
Top-up migrations
Once your main migration is committed, you can run a top-up migration from a newer dump of the same WHMCS database. It brings over anything created or changed in WHMCS since your last run — new clients, new services, updated due dates, new invoices and tickets — without duplicating what's already there.
This means you don't have to rush. The usual flow:
- Run your main migration early and approve it.
- Set up HostCore at your own pace while WHMCS keeps billing as normal.
- When you're ready to cut over, turn off automation in WHMCS by disabling its cron, so nothing else changes.
- Take a fresh dump and upload it as a top-up. It goes through the same sandbox, pre-flight, and approval steps as the main migration.
- Approve it and switch over.
A top-up has to come from the same WHMCS install as your main migration. Records are matched against what's already in your store, so if the dump doesn't line up with your existing migration, it won't run.
After go-live
Work through these in order:
- Reconcile the final report against your WHMCS admin. Counts should match exactly.
- Check your gateways are connected to the same Stripe and PayPal accounts WHMCS used.
- Rebuild branding and email templates.
- Email customers who need to re-add a card.
- Turn off automation in WHMCS — if you haven't already as part of a top-up, disable its cron before HostCore's renewal engine takes over, or both systems will invoice the same services.
Step 5 is the one people forget. Two active billing systems pointed at the same customers means duplicate invoices — and now that saved payment methods migrate, duplicate charges on the same card.
If something goes wrong
Because the migration doesn't write anything until you approve it, the failure you're most likely to hit is a bad or partial dump — and the pre-flight counts are designed to catch exactly that before it matters.
If the counts don't match your WHMCS admin, don't approve. Re-take the dump and start again.
If you find an issue with the migrated data after committing, contact our support team — we can roll it back for you.
Questions
Can I keep running WHMCS during the migration? Yes. Nothing about the import touches your WHMCS install — you're working from a dump. Keep billing there until you're ready to cut over, then run a top-up migration to bring across anything that changed.
Can I migrate more than once? Yes. Before you commit, you can run and cancel test migrations as often as you like. After you commit, you can run top-up migrations from newer dumps of the same WHMCS database. To migrate a different WHMCS install into the same store, contact our support team.
Do my customers need to re-enter their cards? Not if WHMCS charged them through Stripe or PayPal — those payment methods come over. Only customers whose card was stored in the WHMCS database itself need to add a new one.
What about my WHMCS addon modules? Data owned by third-party addons lives in their own tables and doesn't come over. Provisioning modules are replaced by HostCore's own integrations — see the modules page for the current list.
Do you support other billing platforms? Our automatic migration tool only supports WHMCS right now. If you're on something else, let us know and we'll help you migrate your data.
Need a hand?
Migrations are the part of switching we most want to get right, and we'll walk through yours with you. Ask our support team for help.