When your reseller accounts migrate to iWebVault, each one keeps its original cPanel username. An account called shop42 on your old server stays shop42 here. This consistency means logins, file paths, and configurations your customers depend on don’t change.
Why same-name matters
- Logins stay the same — your customers use the same cPanel username
- File paths line up —
/home/usernameis unchanged, so absolute paths in scripts keep working - Database access is preserved — combined with preserved database names, apps connect without edits
How collisions are handled
Before a bulk job runs, we confirm none of your usernames already exist on the destination. Since your reseller is freshly set up on iWebVault, there are no clashes — every account restores cleanly under its original name.
What if a name is already taken?
In the rare case a username already exists on the destination, we coordinate a plan with you before running — there’s no silent renaming. For a typical reseller move onto a fresh reseller account, this doesn’t arise.
The reseller account name
Your reseller account on iWebVault uses the username we provision for you. If it differs from your old reseller name, that’s only the reseller-level login — your individual client accounts still keep their own original usernames.
Why username continuity matters so much
A cPanel username is woven through an account in ways that aren’t obvious. It’s the login your customer uses. It’s part of the home directory path (/home/username), which absolute paths in scripts may reference. It’s tied to database access. Keeping the username identical means all of those relationships survive the move untouched.
The home directory path
Scripts, cron jobs, and configuration files sometimes hardcode the full path to a file, like /home/shop42/public_html/config.php. If the username changed, every such path would break. Because the username is preserved, /home/shop42 is still /home/shop42 on iWebVault, and those paths keep resolving.
Combined with preserved databases
Same usernames and preserved database names reinforce each other. Together they mean a migrated account’s files, paths, and database connections all line up exactly as before — which is why most end customers won’t notice anything changed beyond improved performance.
Collision handling, in detail
Before a bulk job runs, we verify none of your usernames already exist on the destination. Since your reseller account on iWebVault is freshly set up, it owns no accounts yet, so there are no clashes — every account restores cleanly under its original name. If a clash ever existed, we’d agree a plan with you first; there is never silent renaming.
Communicating with your customers
Because logins and usernames don’t change, your message to customers can be reassuringly simple: ‘We’ve upgraded our infrastructure; your login and site are unchanged, and you’ll notice faster performance.’ No password resets, no new usernames, no re-onboarding.
The ripple effects of a username
A cPanel username is referenced in more places than most people realise. It’s the customer’s login. It’s embedded in the home directory path that scripts and configs may hardcode. It’s part of how database access is scoped. Keeping the username identical through the migration means none of those references break — the account on iWebVault is, from the inside, the same account it was on the old host.
Why customers won’t notice
Combine same usernames with preserved database names and you get a migration that’s essentially invisible to end customers. Their login still works. Their site’s file paths still resolve. Their application still connects to its database. The only difference they’re likely to perceive is that their site is faster on iWebVault’s infrastructure. No password resets, no new usernames, no re-onboarding emails.
Collision handling in practice
Before any bulk job, we verify that none of your usernames already exist on the destination. Since your iWebVault reseller account is freshly provisioned and owns no accounts yet, there are simply no clashes — every account restores cleanly under its original name. In the rare event a name did already exist, we’d agree a plan with you beforehand; there is never silent, surprise renaming.
A simple message for your customers
Because nothing customer-facing changes, your communication can be short and reassuring: ‘We’ve upgraded our hosting infrastructure for better performance. Your login details and your website are unchanged — there’s nothing you need to do.’ That’s the entire customer impact of a well-run reseller migration, and it’s a direct benefit of preserving usernames.
The reseller login is the only new credential
The one credential that may differ is your own reseller-level login on iWebVault, which uses the username we provision for you. That’s separate from your individual client accounts, which all keep their original usernames. So even the single point of change is at the reseller level, never at the customer level.
Key takeaways
Accounts keep their exact cPanel usernames, so customer logins, home-directory paths, and database access all continue working unchanged. Combined with preserved database names and ownership, this makes the move essentially invisible to your customers — no password resets, no new usernames, no re-onboarding. Username collisions are checked beforehand; since your iWebVault reseller is freshly provisioned, there are none.
What do I tell my customers about the move?
Keep it short and reassuring: ‘We’ve upgraded our hosting infrastructure for better performance — your login and website are unchanged, and there’s nothing you need to do.’ Because nothing customer-facing changes, that’s genuinely the full extent of the impact on them.
What’s next
- Your Accounts Stay Under Your Reseller
- How Your Databases Are Preserved
- Bulk-Migrating a Reseller’s Accounts
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!
