Managing mailboxes effectively is a crucial part of being a Microsoft Exchange administrator. Whether you’re overseeing an on-premises Exchange environment or a hybrid deployment, you’ll likely need to move mailboxes from one database to another due to maintenance, balancing storage, or performance optimization. The New-MoveRequest cmdlet in Exchange is your go-to tool for smoothly handling this task.
In this article, we’ll dive deep into how to use the New-MoveRequest cmdlet, covering its syntax, common examples, and best practices you should follow. Along the way, we’ll make this powerful command-line tool more accessible—even if you’re not a PowerShell pro.
Table of Contents
What Is the New-MoveRequest Cmdlet?
The New-MoveRequest cmdlet is part of the Exchange Management Shell, or can be run from PowerShell if the Exchange Online module is loaded. Its primary purpose is to initiate a mailbox move request from one mailbox database to another in Exchange Server or from on-premises to Exchange Online in a hybrid setup.
This cmdlet creates what’s called a “move request,” which is then processed in the background by the Mailbox Replication Service (MRS).
Typical scenarios for using the New-MoveRequest include:
- Moving mailboxes between Exchange databases for load balancing
- Migrating mailboxes to Exchange Online during hybrid deployments
- Consolidating databases for simplification or maintenance
Basic Syntax and Parameters
Here’s a basic example of the syntax for this cmdlet:
New-MoveRequest -Identity user@domain.com -TargetDatabase "Mailbox Database 1"
That alone can initiate a move, but let’s break down some of the commonly used parameters:
- Identity: Specifies the user mailbox you want to move. This can be the email address, GUID, or user name.
- TargetDatabase: The name of the mailbox database where the mailbox should be moved.
- TargetArchiveDatabase: If the user has an archive mailbox, you can specify a different database for the archive.
- BadItemLimit: How many corrupted items you’re willing to skip during the move. If exceeded, the move fails unless -AcceptLargeDataLoss is specified.
- BatchName: Useful for assigning a name to a group of move requests, which helps in managing dozens or hundreds of migrations.

Common Use Case Examples
1. Move a Single Mailbox
New-MoveRequest -Identity "alice@company.com" -TargetDatabase "MailboxDB02"
This command moves Alice’s mailbox to MailboxDB02. It’s the most basic and common way to issue a move request.
2. Move Multiple Mailboxes from a CSV
Import-Csv "C:\UsersList.csv" | ForEach-Object {
New-MoveRequest -Identity $_.UserPrincipalName -TargetDatabase "MailboxDB03"
}
This setup reads from a CSV, where each line contains user mailboxes you want to move. It sends all those users to the specified target database.
3. Move Mailboxes While Accepting Some Data Loss
New-MoveRequest -Identity "john.doe@company.com" -TargetDatabase "MailboxDB01" -BadItemLimit 10 -AcceptLargeDataLoss
If performance or corruption issues arise, this command permits up to 10 bad items and still completes the mailbox move.
4. Move an Archive Mailbox Separately
New-MoveRequest -Identity "sarah@company.com" -TargetArchiveDatabase "ArchiveDB01"
Sometimes, especially in large organizations, you may want to move just the archive mailbox. This is useful for optimizing archiving infrastructure separately.
Monitoring and Managing Move Requests
Once requests are initiated, you can check their status using:
Get-MoveRequest
You might want to see detailed information about a move process by using:
Get-MoveRequestStatistics -Identity "jane@company.com"
And, once a move is completed successfully, don’t forget to clean it up:
Remove-MoveRequest -Identity "jane@company.com"
Neglecting to remove completed move requests can clutter the environment and lead to errors when attempting further moves involving the same mailboxes.
Advanced Tips and Best Practices
Moving mailboxes sounds simple, but doing it poorly can have major impacts. Here’s how to do it right:
- Plan ahead: Consider when system load is lowest; mailbox moves require resources and can impact performance.
- Use batch requests: Especially useful during migrations. Give them custom batch names and monitor them accordingly.
- Monitor MRS logs: For deeper diagnostics, check logs under C:\Program Files\Microsoft\Exchange Server\V15\Logging\Migration.
- Verify mailbox limits: Avoid excessive data loss by using BadItemLimit carefully.
- Script your operations: PowerShell allows automation for repetitive tasks. Scripts can help manage batch mailbox moves for thousands of users.
New-MoveRequest in Hybrid Environments
If your organization uses a hybrid Exchange deployment, the New-MoveRequest cmdlet takes on new responsibilities—it facilitates mailbox migrations from on-premises Exchange servers to Exchange Online.
For hybrid scenarios, you’ll also need to ensure:
- You’re running PowerShell with correct modules for Exchange Online.
- The user has appropriate licenses assigned in Microsoft 365.
- Hybrid configuration is properly set up with appropriate migration endpoints.
Here’s an example of initiating a remote move to Exchange Online:
New-MoveRequest -Identity user@legacydomain.com -Remote -TargetDeliveryDomain "company.mail.onmicrosoft.com"

Troubleshooting Common Issues
Like any powerful tool, New-MoveRequest can occasionally throw errors. Some of the most common problems include:
- Error: MoveRequest already exists – use Remove-MoveRequest before reattempting.
- Error: Database is offline or dismounted – ensure the destination mailbox database is mounted.
- Error: Insufficient permissions – verify the user running the command has appropriate roles (like Mailbox Import Export).
- Performance issues: Moves are slow – check server CPU and disk I/O, or schedule moves during off-hours.
Keep a script handy to retry failed requests:
Get-MoveRequest | where {$_.Status -eq "Failed"} | Resume-MoveRequest
Conclusion
The New-MoveRequest cmdlet is more than just a command; it’s a cornerstone of effective Exchange environment management. Whether you’re tackling a huge migration project or just cleaning up storage, deploying this cmdlet with confidence can save you massive amounts of time and stress.
By understanding its syntax, learning key examples, and following best practices, you’ll be prepared to move mailboxes around your Exchange ecosystem like a pro. And with automation and scripting, your processes can scale easily—from a handful of users to an enterprise-wide migration.
So next time you’re about to open the Exchange Admin Center and click your way through a mailbox task—consider reaching for PowerShell and the New-MoveRequest cmdlet. You might just find it’s the smarter and faster way to go.