A common worry for resellers is: ‘I don’t have root on my old server, only reseller access — can I still move all my accounts?’ The answer is yes. iWebVault’s bulk migration is built specifically to work with reseller-level access, no root required.
Why root usually gets demanded
Traditional server-to-server transfers use root-only tools that copy whole accounts. If you’re a reseller on a shared WHM, you don’t have root — so those tools simply refuse to run. That’s where many reseller migrations get stuck.
How iWebVault does it differently
Instead of root-level transfer tools, the bulk migration uses your reseller’s normal ability to access the accounts you own. For each account, it creates a standard session into that account and triggers a backup — exactly the kind of action a reseller is allowed to perform.
What permissions you actually need
- List your own accounts
- Create a session into accounts you own
- Trigger a backup within those accounts
These are standard reseller privileges. No root, no shell access, no server-admin involvement on the old host.
What about the reseller account itself?
Your reseller account on iWebVault is set up in advance (we provision it). The migration then moves your owned accounts and assigns them to that reseller, so your hierarchy is preserved without ever needing root on either side for the account moves.
The technical reason root is usually demanded
Traditional whole-server transfer tools operate at the root level: they read every account’s files directly from disk and recreate them on the destination. That requires root because only root can read across all accounts’ home directories. As a reseller on a shared WHM, you don’t have root, so those tools simply refuse — which is where many reseller migrations stall.
How session-based backup sidesteps this
Instead of reading from disk as root, iWebVault uses your reseller’s legitimate ability to access the accounts you own. For each account, it creates a normal session into that account — exactly as you would when logging in to help a customer — and triggers that account’s own backup. The account backs itself up; no cross-account root reading is involved.
What the destination does
The backup is then pulled to iWebVault and restored as root on the destination — which is fine, because iWebVault controls the destination server. The asymmetry is the key insight: you don’t need root on the source you’re leaving, only legitimate reseller access there; the privileged work happens on the iWebVault side, which we own.
Privileges to confirm on the old host
- List the accounts your reseller owns
- Create a login session into those accounts
- Trigger a backup within an account
These are default reseller capabilities. Only if your old host explicitly stripped them would there be a problem — and even then, the fix is asking them to restore standard reseller privileges, not obtaining root.
Why this matters when leaving a difficult host
Some hosts make leaving hard — they won’t give resellers root and won’t assist with migrations. This approach means you’re not dependent on their cooperation: with your normal reseller login, you can move your entire customer base to iWebVault yourself, or have us do it for you.
Putting it plainly
Here’s the whole idea in one sentence: the migration borrows the access you already have as a reseller on the old server — the ability to reach your own accounts — and does all the privileged restore work on the iWebVault side, which we control. You never need root on the host you’re leaving.
Why this design exists
It was built specifically for the real-world situation resellers face: you’ve built a customer base on someone else’s WHM, you don’t have root there, and you want to leave. Traditional root-only transfer tools simply don’t work for you in that position. By using ordinary reseller access on the source and handling privilege on the destination, the migration meets you where you actually are.
Confirming your access is sufficient
If you can log into your reseller WHM on the old host, see your list of accounts, and access those accounts to manage them, you have what the migration needs. The specific capabilities — listing your accounts, creating sessions into them, triggering their backups — are standard reseller privileges that come with virtually every reseller account.
The rare exception and its fix
The only time this hits a snag is if your old host explicitly stripped standard reseller privileges — for instance, disabling your ability to create sessions into your own accounts. Even then, the fix isn’t obtaining root; it’s asking the old host to restore normal reseller privileges, or contacting us to adapt the approach for your specific restrictions. Open a ticket and we’ll work it out.
The strategic advantage
This matters most precisely when leaving is hardest. Some hosts make departure difficult, withholding root and declining to help migrate. Because iWebVault’s bulk migration depends only on your normal reseller access, you’re not at their mercy — you can move your entire customer base on your own terms, or hand it to us to run for you, without ever needing their cooperation or root access.
Key takeaways
You don’t need root on the host you’re leaving. The migration borrows the access you already have as a reseller — listing your accounts, creating sessions into them, triggering their backups — and performs the privileged restore work on the iWebVault side, which we control. If you can manage your customers’ accounts from your reseller WHM, you have everything the migration needs.
My old host won’t give me root or help me migrate — am I stuck?
No — that’s exactly the situation this design solves. Because the migration depends only on your normal reseller access, you’re not dependent on the old host’s cooperation or root. You can move your whole customer base on your own terms, or hand the job to us to run for you.
What’s next
- Bulk-Migrating a Reseller’s Accounts
- Your Accounts Stay Under Your Reseller
- “Access Denied” Connecting to Your Old Host
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!
