Do you start a MigrationWiz Migration Pass and check back when it is finished, or do you watch what it says while it is running?

This mistake can be found in projects of all sizes. Someone configures BitTitan MigrationWiz and starts the pre-stage, thinking that the tool will highlight any important information when the job is complete. The tool surfaces all important information in the item-level log while the job runs, but nobody is watching it.

Monitoring is essential during a large MigrationWiz Migration. It is the job.

Monitoring is not only about the summary counts, but also the item-level errors. It means separating HTTP 429 throttling error that will self-resolve from HTTP 403 permission error that will repeat every time a retry is made until the underlying RBAC assignments are fixed. It means monitoring items per hour to determine when a drop indicates EWS service protection throttling instead of normal variation. It means identifying patterns of failed items that indicate configuration problems affecting a small subset before the problem affects the entire batch.

Authentication errors and permission mismatches are all discovered mid-migration. An engineer who is familiar with BitTitan MigrationWiz and can diagnose these signals quickly will run a different project from one who checks the dashboard after job completion.

The Office 365 issues that arise after migration and are experienced by a large client base are almost always the same problems that were visible on the MigrationWiz logs. The question is if anyone read those logs in a context that allowed them to be acted upon before the users did.

MigrationWiz will eventually find every problem in either your source or destination environments. The only variable is if your engineer finds it during the migration period or if your users find it.

What is your active monitoring between MigrationWiz and your current project?

#BitTitan #MigrationWiz #M365Migration