An ‘access denied’ error means the migration couldn’t authenticate to your old host. It’s almost always a credentials or access-type issue, and the fixes are quick. Here’s how to resolve it.
Check the obvious first
- Are you using the old host’s credentials (not your iWebVault login)?
- Is the username exactly right — lowercase, no spaces, no typos?
- Is the password current? Reset it on the old host if unsure.
- Is the hostname the server address, not your website domain?
Password vs token
If you’re using an API token instead of a password, make sure it’s a valid, unexpired token with the right scope on the old host. For most people, the cPanel password is simpler and avoids token-scope issues.
Reseller ‘access denied’
For a reseller bulk migration, ‘access denied’ can mean the reseller account lacks a required privilege on the old host — specifically the ability to create sessions into its own accounts. If your old host restricted reseller privileges, ask them to enable standard reseller account access, or contact us to adjust the approach.
Account suspended or expired
If your old account is suspended (for non-payment, for example), the old host will deny access. Make sure the account is active on the old side before migrating.
Still denied?
If credentials are definitely correct and access still fails, the old host may be blocking external connections. Open a ticket with the exact error and we’ll help identify the block.
What ‘access denied’ is really telling you
This error means the migration reached your old host but couldn’t authenticate — the host refused the login. It’s an authentication or permission issue almost every time, not a deep technical fault, which is good news because the fixes are quick and within your control.
The credential checklist
- Confirm you’re using the old host’s credentials, not your iWebVault login
- Check the username is exact — lowercase, no spaces, no stray characters
- Verify the password is current; reset it on the old host if you’re unsure
- Make sure the hostname is the server address, not your website domain
Password versus API token
If you opted to use an API token instead of a password, an ‘access denied’ can mean the token is expired, mistyped, or lacks the needed scope on the old host. For most people a current cPanel password is the simpler, more reliable choice, since the migration only reads from the account to build a backup.
Reseller-specific access denied
In a bulk reseller migration, ‘access denied’ can mean your reseller account on the old host lacks a privilege the migration needs — specifically the ability to create a session into the accounts you own. Most resellers have this by default. If your old host restricted reseller privileges, ask them to restore standard reseller account access, or contact us and we’ll adapt the approach.
Account state on the old host
If your old account is suspended — for non-payment, a policy hold, or being past due — the old host will deny access regardless of correct credentials. Confirm the account is active and in good standing on the old side before migrating. A suspended account simply can’t be read until it’s reactivated.
Firewalls and connection blocks
Less commonly, the old host’s firewall blocks external connections to its cPanel/WHM ports, refusing the migration before authentication even matters. If your credentials are definitely correct and access still fails, this is the likely cause. Open a ticket with the exact error and the source hostname, and we’ll help determine whether a block is in play and how to work around it.
A quick re-verification routine
Before retrying after an access-denied error: log into the old host’s cPanel yourself with the same username and password you entered. If you can log in, the credentials are right and the issue is elsewhere (token scope, reseller privilege, or a block). If you can’t log in either, you’ve found the problem — fix the login, then retry the migration.
Interpreting the error correctly
‘Access denied’ means the migration reached your old host but the host refused the login — an authentication or permission issue, essentially never a deep technical fault. That framing is reassuring: the fixes are quick and almost always within your control, usually amounting to correcting a credential or confirming the account’s state on the old side.
The most common cause, and how to rule it out
By a wide margin, the usual culprit is a credential mix-up — entering iWebVault (destination) details, or a website admin login, into the source fields, which expect your OLD host’s cPanel login. The fastest way to rule this out is to try those exact credentials in your old host’s cPanel yourself. If you can log in, they’re correct and the issue lies elsewhere; if you can’t, you’ve found the problem.
The full credential checklist
- Confirm you’re using the OLD host’s credentials, not your iWebVault login
- Check the username is exact — lowercase, no spaces, no stray characters
- Verify the password is current; reset it on the old host if unsure
- Make sure the hostname is the server address, not your website domain
Token, reseller, and account-state causes
If you’re using an API token, an access-denied can mean it’s expired, mistyped, or lacks scope — a current cPanel password is simpler and more reliable. For reseller bulk jobs, access-denied can mean your reseller lacks the privilege to create sessions into its own accounts; ask the old host to restore standard reseller access or contact us to adapt. And a suspended account on the old host — for non-payment or a hold — will deny access regardless of correct credentials, so confirm the account is active and in good standing first.
Firewalls and connection blocks
Less often, the old host’s firewall blocks external connections to its cPanel/WHM ports, refusing the migration before authentication even matters. If your credentials are definitely correct and access still fails, this is the likely cause. Open a ticket with the exact error and the source hostname, and we’ll help determine whether a block is in play and how to work around it.
The re-verification routine
Before retrying after access-denied, run this quick routine: log into the old host’s cPanel yourself with the same username and password you entered. If you get in, the credentials are right and the issue is token scope, reseller privilege, or a block — investigate those. If you can’t get in either, you’ve isolated the problem to the login itself; fix it on the old host, then retry the migration with confidence.
What’s next
- Finding Your Old cPanel Username and Password
- What Source Hostname to Enter
- Migrating as a Reseller Without Source Root
Still stuck? Our team can run or finish the migration for you — open a support ticket and we’ll take it from there.
Was this helpful?
Thanks for your feedback!
