Migrations

Why Bulk Migration Runs One Account at a Time

Bulk migrations process accounts sequentially on purpose — to protect both servers and guarantee each account arrives intact. Here's the reasoning.

6 min read

When you watch a bulk reseller migration, you’ll see accounts complete one after another rather than all at once. That’s deliberate. Processing sequentially protects both the old and new servers and makes the whole job more reliable.

How every migration runs — one account at a time 1Connect2Backup3Pull4Restore5Verify6Done

Why not all at once?

Backing up and transferring many accounts simultaneously would hammer your old server — spiking its disk and CPU — and flood the destination. That risks failed backups, timeouts, and degraded performance for sites still live on the old host. One-at-a-time keeps the load gentle and steady.

Benefits of sequential processing

  • No server overload on either side — sites stay responsive during the move
  • Reliable backups — each account gets full resources to back up cleanly
  • Isolated failures — if one account hits a snag, the others are unaffected
  • Clear progress — you can see exactly which account is being processed

What this means for timing

Total time is the sum of each account’s migration. A reseller with dozens of accounts can take several hours overall. That’s expected and healthy — it’s the trade-off for a safe, low-impact move.

📘 NoteThe job runs unattended. You can start it and check the summary later; you don’t need to babysit it.

If one account fails

A failure on one account doesn’t stop the rest — the job continues and marks that account failed, so you can retry just that one afterward. See the article on retrying failed accounts.

The overload problem, concretely

Imagine backing up fifty accounts simultaneously. Your old server would try to compress fifty accounts’ worth of files at once — spiking its CPU and disk to the point where the customer sites still live on it slow to a crawl or error out. Meanwhile the destination would be hit with fifty incoming transfers. Sequential processing avoids both problems entirely.

Reliability through isolation

Processing one account at a time also means each migration gets the server’s full attention, so backups complete cleanly rather than competing for resources. And if one account hits a problem, it’s isolated — the system records the failure and moves on, instead of one bad account derailing a batch.

How the queue advances

The system picks the next pending account, takes it all the way through backup, transfer, restore, and ownership assignment, confirms it’s done, then picks the next. An account in progress is always carried to completion before a new one starts, so there’s never more than one heavy operation running at once.

📘 NoteThis is the same proven mechanism used for single-account migrations, simply applied in sequence across your whole fleet.

Implications for scheduling

Because total time is the sum of the parts, a large fleet is best migrated during a quiet period or overnight. The job runs unattended, so you can start it in the evening and review the summary in the morning. There’s no need to supervise it.

Watching it work

During the job you’ll see accounts tick over to completed one after another, with the current account shown as in progress. This visibility is a benefit of the sequential design — you always know exactly where the job is, rather than staring at a single combined progress bar that could mean anything.

A worked picture of the load problem

Suppose you tried to migrate forty accounts simultaneously. Your old server would attempt to compress forty accounts’ worth of files and dump forty databases all at once — its CPU and disk would saturate, and the customer sites still living on that server would slow to a crawl or start erroring. The destination would meanwhile face forty concurrent incoming transfers. Sequential processing sidesteps both problems by ensuring only one heavy operation runs at a time.

Reliability as a side benefit

Beyond protecting performance, one-at-a-time processing improves reliability. Each account’s backup gets the server’s full attention, so it completes cleanly rather than competing for resources and risking a corrupt or incomplete archive. And because accounts are independent, a problem with one is contained — recorded as a failure while the rest carry on — rather than derailing an entire concurrent batch.

How the queue advances

The mechanism is straightforward: the system selects the next pending account, carries it all the way through backup, transfer, restore, and ownership assignment, confirms completion, then selects the next. An in-progress account is always finished before a new one begins, so there’s a clean, predictable rhythm and never more than one account’s worth of load on either server.

Implications for how you schedule

Since total time is the sum of the parts, a large fleet is best started during the old host’s quiet hours or overnight. The job runs unattended — you start it in the evening and review the summary in the morning. There’s no need to supervise; the sequential design means it paces itself safely without intervention.

The visibility benefit

A pleasant consequence of sequential processing is clarity. Rather than staring at a single combined progress bar that could mean anything, you see accounts tick over to completed one after another, with the current account marked in progress. At any moment you know exactly where the job is and how much remains — far more informative than an opaque all-at-once operation.

Key takeaways

Accounts migrate sequentially on purpose: it prevents overloading either server, gives each backup full resources to complete cleanly, isolates any failure so it can’t derail the batch, and gives you clear account-by-account progress. The trade-off is that total time is the sum of the parts — a large fleet is best run overnight, unattended, with the summary reviewed in the morning.

Isn’t running them in parallel faster?

It would finish sooner in theory, but at real cost: simultaneous backups would spike your old server’s CPU and disk, slowing or breaking the customer sites still live on it, and risk corrupt or incomplete backups from resource contention. Sequential processing trades a little wall-clock time for reliability and zero impact on still-hosted sites — a worthwhile exchange.

If you’re coordinating a large fleet move with us, we’ll agree a start time that lets the sequence run through the old host’s quietest window, and we’ll monitor it to completion so you don’t have to. You’ll still get the same account-by-account visibility and a final summary — the sequential design simply means the work paces itself safely whether you’re watching or asleep.

Ready to move to iWebVault?Offshore, anonymous, DMCA-ignored hosting — and our migration tools bring your sites across for you.Start from $1 →

What’s next

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?