Retrying Individual Failed Accounts in a Bulk Job

In a large bulk migration, it’s possible for a single account to fail while all the others succeed — maybe its backup hit a transient issue. The good news: you retry only that account, not the entire job.

Failures are isolated

Because accounts migrate one at a time, a failure on one doesn’t affect the others. The job continues, completes the rest, and marks the failed one so you can see exactly which needs attention.

How to retry

1. Open the bulk job’s status page
2. Find the account marked failed and read its short error reason
3. Use the retry action on that account
4. It re-enters the queue and runs through the migration stages again

Common reasons one account fails

• A transient connection blip to the old host during its backup
• The old host briefly rate-limited backup creation
• An unusually large account that needed more time than allowed

Most of these clear on a simple retry. For a large account that timed out, we can raise the per-account time ceiling before retrying.

If a retry keeps failing

If the same account fails repeatedly, the error reason points to the cause. Open a ticket with that reason and we’ll diagnose it directly — often it’s something specific to that one account on the old host.

Why isolated retries are possible

Because each account migrates independently and in sequence, the system tracks the outcome of every account separately. A completed account is finished and recorded; a failed account is flagged with its reason. That per-account record is what lets you re-run a single account without touching the ones that already succeeded.

Reading the failure reason

Every failed account carries a short reason and a per-account log. The log shows which stage failed — connecting, backing up, pulling, or restoring — which usually makes the cause obvious. A failure during the backup stage on a large account points to timing; a failure at connect points to credentials or access.

The retry workflow in practice

1. Open the bulk job and filter to failed accounts
2. Read each one’s reason and log
3. For timing failures on big accounts, ask us to raise the time ceiling first
4. Trigger the retry on that account
5. It re-runs through the full migration independently

When several accounts fail the same way

If a cluster of accounts fail with the same reason, that points to a systemic cause rather than bad luck — perhaps the old host rate-limited backups, or a credential changed mid-job. Address the root cause (wait out a rate limit, re-confirm credentials), then retry the affected accounts together.

Escalating a stubborn account

If one account fails repeatedly despite retries, its log reason is your diagnostic. Open a ticket quoting that reason and the account name; the cause is usually something specific to that account on the old host — an unusual size, a permissions quirk — that we can address directly.

Why per-account retries are possible at all

Because each account migrates independently and in sequence, the system records the outcome of every account separately — completed accounts are finished and logged, failed accounts are flagged with a reason and a log. That per-account bookkeeping is precisely what lets you re-run a single failed account without disturbing the dozens that already succeeded.

Diagnosing from the log

Every failed account carries a short reason plus a per-account log showing which stage failed: connecting, backing up, pulling, or restoring. The stage usually reveals the cause at a glance. A failure during the backup stage on a large account points to timing; a failure at the connect stage points to credentials or access. The log turns a vague ‘it failed’ into a specific, fixable diagnosis.

The retry workflow

1. Open the bulk job and filter to failed accounts
2. Read each account’s reason and per-account log
3. For timing failures on big accounts, ask us to raise the time ceiling first
4. Trigger the retry on the affected account
5. It re-runs through the full migration on its own, untouched by completed accounts

Patterns across multiple failures

If several accounts fail with the same reason, that signals a systemic cause rather than coincidence — perhaps the old host rate-limited backups, or a credential changed mid-job. Address the root cause (wait out a rate limit, re-confirm credentials) and then retry the affected accounts together, rather than retrying each blindly.

When an account resists every retry

If one account keeps failing despite retries and any timing adjustments, its log reason is the key. Open a ticket quoting that reason and the account name; the cause is usually something specific to that account on the old host — an unusual size, a permissions quirk, a corrupt file — that we can investigate and resolve directly rather than by repeated blind retries.

Key takeaways

Because accounts migrate independently, a single failure is isolated and retried on its own without disturbing the completed ones. Read the per-account log to find which stage failed: timing on a large account (raise the ceiling, retry) versus an access error (re-confirm credentials). A cluster of identical failures signals a systemic cause to address before retrying together.

Will retrying a failed account affect the ones that already succeeded?

No. A retry re-runs only the selected failed account; completed accounts are left exactly as they are. The per-account independence that lets failures be isolated is the same property that makes retries safe — nothing else is touched.

What’s next

• “Source Pull Failed” — Causes and Fixes
• Migrating Very Large Accounts
• Why Bulk Migration Runs One Account at a Time

Still stuck? Our team can run or finish the migration for you — open a support ticket and we’ll take it from there.