Planning for Large Mailboxes in MigrationWiz and the Item Count Variable That Shows Up Too Late

Are you planning migration throughput as if a 40GB high-item-count mailbox behaves the same as a 40GB mailbox made up mostly of large attachments?

With MigrationWiz, large mailboxes require more than just adding more time. A 40GB mailbox holding 200,000 small items behaves very differently from a 40GB mailbox with 5,000 large attachments. Even though the size is identical, the expected duration and throttling pattern are not.

Item count drives EWS API call volume. Each item in the source mailbox typically requires at least one Exchange Web Services operation to read, process, and write to the destination. That means a mailbox with 200,000 items at roughly 200KB average size can drive 200,000 individual EWS operations. Microsoft throttles via service protection policies at the operation-count level, not just by bytes transferred. High item count mailboxes hit throttling thresholds sooner per GB than low-item-count, large-attachment mailboxes.

To avoid getting caught late, pull mailbox statistics from the source tenant using Get-EXOMailboxStatistics with ItemCount and TotalItemSize output. Then sort by ItemCount separately from TotalItemSize. The accounts with the highest ItemCount are often not the ones with the largest TotalItemSize, and both sets need to be represented in your scheduling model.

When testing, include at least one high item count mailbox in the test pass. Track throughput in items per hour, not only GB per hour, and use that measured rate to build a realistic schedule for your item-count outliers.

Are you separating high item count mailboxes from large size mailboxes in your MigrationWiz planning?

#BitTitan #MigrationWiz

Leave a Reply

Your email address will not be published. Required fields are marked *