Most reseller fleets include a few suspended or overdue accounts. When you migrate, you need to decide what to do with them — bring them across, leave them behind, or handle them separately. This guide covers how suspended accounts behave in a migration and the choices you have.
Suspended accounts and the migration
A suspended account on the source can be a complication: depending on how it’s suspended, the migration may not be able to access it to build a backup. If you intend to bring a suspended account across, the cleanest path is usually to unsuspend it on the old host just long enough to migrate, then re-apply the suspension on iWebVault.
Decide what to bring across
- Active accounts — migrate normally
- Suspended-but-keeping — unsuspend on the source to migrate, then re-suspend on iWebVault
- Overdue you expect to recover — migrate so the customer’s site is ready when they pay
- Abandoned/closed — leave behind; no need to migrate dead accounts
Preserving suspension state
If an account should remain suspended on iWebVault (for example, a non-paying customer), you migrate it while temporarily active on the source, then suspend it again on iWebVault once it’s across. This preserves your business state — the account exists and is ready to reactivate if the customer pays, but isn’t serving while suspended.
Overdue accounts you expect to recover
For customers who are merely behind on payment but likely to return, migrating their account means their site is already on iWebVault and ready the moment they settle up. You can keep it suspended until then. This is often better than leaving it on the old host, which you’re trying to decommission.
Planning this with us
When scheduling a bulk migration, tell us which accounts are suspended and your intention for each. We’ll sequence the move so that accounts you want migrated are accessible, and you can re-apply suspensions on iWebVault afterward. It’s a quick conversation that avoids surprises mid-job.
Why suspended accounts need a decision
Every reseller fleet accumulates suspended and overdue accounts. They can’t just be ignored during a migration because, depending on how they’re suspended on the source, the migration may not be able to read them to build a backup. So before a bulk job, decide for each suspended account whether it’s coming across — and if so, how.
The clean approach for suspended accounts you’re keeping
If you want a suspended account on iWebVault — say, a non-paying customer you expect might return — the tidiest method is to briefly unsuspend it on the old host so the migration can access it, let it migrate, and then re-apply the suspension on iWebVault. The account ends up present but suspended, exactly as your business state requires.
A decision list
- Active — migrate normally
- Suspended, keeping — unsuspend on source to migrate, re-suspend on iWebVault
- Overdue, likely to recover — migrate so the site is ready when they pay
- Dead/abandoned — leave behind; don’t migrate
Overdue accounts as an opportunity
For customers merely behind on payment, migrating their account (kept suspended) means their site is already on iWebVault and ready to reactivate the instant they settle up — better than leaving it stranded on a server you’re trying to decommission. It turns a fleet migration into a chance to tidy up your account base while keeping recoverable customers’ sites ready.
Flag them in advance
When scheduling a bulk migration, tell us which accounts are suspended and your intention for each, so we can sequence the job to access the ones you’re keeping. An inaccessible suspended account left unflagged simply shows up as a failure in the job — entirely avoidable with a quick heads-up.
What’s next
- Retrying Individual Failed Accounts
- Reconciling Billing After a Reseller Migration
- 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.
Key takeaways
Suspended accounts need a decision before a bulk move: to keep one, briefly unsuspend it on the source so it can be migrated, then re-suspend it on iWebVault. Migrate overdue-but-recoverable accounts (kept suspended) so they’re ready when the customer pays; leave genuinely dead accounts behind. Flag suspended accounts in advance so they don’t register as failures.
What happens if I don’t flag a suspended account?
Depending on how it’s suspended on the source, the migration may be unable to access it to build a backup — so it can show up as a failed account in the job. That’s avoidable: decide each suspended account’s handling up front and tell us, so the ones you’re keeping are accessible when the job runs.
Common mistakes to avoid
- Leaving suspended accounts unflagged so they register as failures
- Migrating genuinely dead accounts you’ll never reactivate
- Forgetting to re-suspend a kept account after migrating it
- Assuming a suspended account can be backed up while still suspended
A fleet migration is a natural moment to tidy your account base: bring across the active and the recoverable, leave the dead behind, and preserve suspension state by unsuspending-then-re-suspending the ones you’re keeping. Decide each suspended account’s fate up front and the bulk job runs cleanly with no surprise failures.
When to let us handle it
When you’re planning a bulk migration that includes suspended or overdue accounts, the simplest path is to tell us about them in advance. Share which accounts are suspended and what you want done with each — keep and re-suspend, migrate as recoverable, or leave behind — and we’ll sequence the job so the ones you’re keeping are accessible when it runs. This short conversation up front turns what could be a string of puzzling failures into a clean job, and lets you use the migration as a moment to tidy your account base deliberately rather than by accident.
Was this helpful?
Thanks for your feedback!
