Are you stopping and restarting MigrationWiz jobs that would have recovered on their own if you had simply left them running?

MigrationWiz includes built-in retry logic for EWS and Graph API throttling responses. When a job receives a 429 throttling response, MigrationWiz reads the retry-after header, waits for the specified back-off duration, and then automatically resubmits the failed request. A throttled job typically does not need manual intervention. It will continue once the back-off period expires.

In fact, manually stopping and restarting a throttled job can slow things down. Restarting resets the job place in the MigrationWiz queue, and under high concurrency that often increases the time before it resumes processing.

There are scenarios MigrationWiz will not auto-retry: HTTP 401 authentication failures, HTTP 403 permission failures, and any job that has been manually stopped. If a job is in an error state because of a 403, restarting it without fixing the underlying RBAC or impersonation configuration will just produce the same permission error again immediately.

A practical decision rule helps: if a job shows slow progress and 429 errors in the activity log, it is throttled, so leave it running. If it stopped completely and the error log shows a 401 or 403, fix credentials or permissions first and only then restart. Treating a permission error like throttling wastes valuable time in a maintenance window.

Do you have clear criteria for when to intervene on a MigrationWiz job versus letting the built-in retry logic handle recovery?

#BitTitan #MigrationWiz