Has Microsoft service protection throttling ever brought your entire MigrationWiz program to a halt just hours before a committed cutover window?

In Exchange Online, Microsoft applies two separate throttling layers. Standard EWS throttling reduces migration throughput by shrinking the resource budget available to the migration service account. Service protection throttling is different: once cumulative load crosses Microsoft tenant-level protection threshold, it can suspend migration activity completely and keep it suspended for hours.

Service protection is triggered when overall migration activity against a tenant exceeds that threshold. The most common cause is running multiple large MigrationWiz pre-stage passes at the same time into a single destination tenant during peak hours. It can also be triggered by a single high-speed project driving maximum EWS throughput while the tenant is already under heavy production mail flow.

If service protection hits, recovery depends on doing less, not more. Stop all MigrationWiz jobs for the affected tenant right away and do not try to restart them. Wait out the full retry-after period returned in the service protection response before starting anything again. When you resume, restart with reduced concurrency, watch items per hour during the first hour, and only then consider increasing concurrency.

Prevention is easier than recovery. Stagger project start times so multiple large batches do not collide at peak throughput against the same destination tenant.

Have you added service protection throttling recovery steps to your MigrationWiz cutover runbook, including the wait period and a reduced-concurrency restart procedure?

#BitTitan #MigrationWiz