An HTTP 429 throttling error clears itself. An HTTP 403 permission error repeats on every retry until someone fixes the underlying RBAC assignment. Telling them apart takes someone reading the item-level log during the job.

The common mistake shows up on projects of every size. Someone configures BitTitan MigrationWiz, starts the pre-stage pass, and expects the tool to flag anything important when the job finishes. It surfaces that information in the item-level log while the job runs, and nobody is watching.

Monitoring a large MigrationWiz migration is the job. It means:

• Reading item-level errors, not just summary counts
• Tracking items per hour, so you can tell EWS service protection throttling from normal variation when throughput drops
• Spotting patterns in failed items that point to a configuration problem affecting a small subset, before it reaches the whole batch

Authentication errors and permission mismatches show up mid-migration. An engineer who can diagnose those signals quickly runs a different project from one who checks the dashboard after the job ends.

The Office 365 issues a large client base hits after migration are almost always ones that were already in the MigrationWiz logs. MigrationWiz surfaces most problems in your source and destination environments. The only variable is whether your engineer finds them during the migration or your users find them afterward.

Who is reading the MigrationWiz item-level log on your current project while the job runs?

#BitTitan #MigrationWiz #M365Migration