I learned this the hard way. A few years back, I was managing an Exchange setup where every mailbox—user, shared, system—was dumped into the default database. It worked fine until it didn’t. One morning, the database hit its size limit and threw the whole org into chaos. Mail flow stalled, Outlook clients froze, and I spent the next six hours rebuilding from backups. Not fun.
Since then, I’ve made it a habit to distribute mailboxes across multiple databases. It’s not just about performance—it’s about resilience. If one database goes down, the rest stay up. That’s the kind of insurance you want when you’re managing live infrastructure.
How I Move Mailboxes (Without Breaking Stuff)
I usually start with Exchange Admin Center (EAC) for small batches—say, moving a few shared mailboxes to a lighter database. But when I’m dealing with dozens or hundreds, PowerShell is my go-to. Here’s how I typically approach it:
Using EAC (for quick moves)
- Head to Recipients > Migration.
- Hit the + and choose Move to a different database.
- Select the mailboxes, pick the target DB, tweak the bad item limit, and fire off the move.
It’s straightforward, but not ideal for bulk operations.
Using Exchange Management Shell (for real control)
Get-Mailbox -Database "DB01" | New-MoveRequest -TargetDatabase "DB02"
Then I monitor the progress:
Get-MoveRequest | Get-MoveRequestStatistics
Once the move completes, I double-check mail flow and client access. Not gonna lie, I’ve missed that step before—and paid for it with a flood of helpdesk tickets.
The Gotchas That Still Trip Me Up
- Corrupt mailboxes: Even one bad item can stall the whole batch. I usually set
-BadItemLimit 10just to be safe. - Storage miscalculations: I once moved 80 mailboxes to a DB that had 10GB free. Rookie mistake. Always check free space before you start.
- Permissions: If you’re running hybrid or have RBAC in play, make sure your account has the right roles. I’ve had move requests silently fail because of that.
My Favorite Workaround: Random Distribution Script
When I need to balance mailboxes across multiple databases, I use a PowerShell script that randomly assigns mailboxes to available DBs. It’s not perfect, but it saves me from manually mapping each one.
Final Thoughts
Mailbox migration isn’t glamorous, but it’s one of those tasks that can make or break your Exchange environment. I’ve learned to treat it like a surgical procedure—plan it, test it, monitor it, and always have a rollback ready. These days, I run Exchange on a VM cluster with SSD-backed storage and keep databases under 100GB each. It’s not bulletproof, but it’s saved me from a few disasters.
Ever tried moving mailboxes during peak hours and regretted it instantly? Or hit a weird bug mid-migration that made you question your life choices? Drop your war stories below—I’d love to hear how others handle this.
