How to move on-premise mailbox using Exchange Administration Console

In Microsoft Exchange, Mailboxes are stored within Databases which are .edb files. There may come a time where you will be required to do an Exchange Mailbox move to relocate a mailbox from one Even in a cloud-first world, on-premises Microsoft Exchange remains business-critical for many organisations due to compliance, data sovereignty, legacy integrations, or hybrid designs. One of the most common operational tasks Exchange administrators face is moving mailboxes between databases.

Mailbox moves are required more often than people expect:

• Databases grow unevenly over time
• Disk performance becomes constrained
• Backup or restore windows increase
• Storage tiers change
• DAG rebalancing is required
• Legacy databases need to be retired

Although Microsoft has significantly improved mailbox move reliability since Exchange 2010, poor planning can still cause user disruption, performance issues, or prolonged move times.

This guide walks through:

• How Exchange mailbox moves actually work
• When to use EAC vs PowerShell
• Real-world performance expectations
• Common mistakes admins make
• Best practices I’ve learned managing production Exchange environments

How Exchange Stores and Moves Mailboxes

In on-prem Exchange (2010 through 2019), mailboxes are stored inside Exchange databases, which are backed by .edb files.

When you move a mailbox:

• Exchange performs an online mailbox move
• Data is copied from the source database to the target database
• The mailbox remains usable for most of the process
• A brief finalisation phase locks the mailbox momentarily

This is not a file-level move. Exchange rehydrates mailbox content item-by-item, which means:

• Performance depends heavily on disk I/O
• Network latency matters (especially across sites)
• Large or heavily fragmented mailboxes take longer

Before You Begin: Critical Planning Considerations

Mailbox moves are forgiving, but not foolproof. Before starting, consider the following.

Permissions Required

You must be a member of:

• Organization Management
• Or Recipient Management (with move permissions)

Lack of permissions will cause silent failures or stalled requests.

User Impact and Timing

While mailbox moves are online, users will notice:

• Outlook reconnect prompts
• Temporary performance degradation
• Brief disconnections during finalisation

Real-world rule of thumb:
A 3–5 GB mailbox typically takes 30–90 minutes, depending on disk speed and load. Very large mailboxes (>20 GB) can take several hours.

For executive or shared mailboxes, after-hours moves are still best practice.

Disk and Database Health

Before moving mailboxes:

• Ensure the target database has sufficient free disk space
• Check database copy health (especially in DAGs)
• Verify backup status

Moving mailboxes into a stressed or unhealthy database just shifts the problem.

Moving a Mailbox Using the Exchange Admin Center (EAC)

The Exchange Admin Center (EAC) is suitable for:

• Junior admin operations
• Small numbers of mailboxes
• One-off administrative tasks

In the EAC, go to Recipients -> Migration-> Click ADD + and then select Move to a different database

Search for the user you wish to move. You can select multiple users.

Give your Move a name so you can distinguish which mailboxes are being moved. Then select the destination database that you will move the mailbox to.

Last step is to select the user you wish to notify when the move completes.

Why Naming Move Requests Matters

In real environments, you may have:

• Multiple moves running simultaneously
• Scheduled migrations
• Troubleshooting scenarios

Naming move requests logically (e.g. Finance_DB_Rebalance_March) makes troubleshooting far easier later.

Monitoring Mailbox Moves in EAC

From the Migration view you can:

• Track percentage complete
• View errors or warnings
• Suspend or remove move requests

If a move stalls, don’t panic. Exchange retries automatically. Persistent stalls usually indicate:

• Disk I/O contention
• Antivirus scanning the database volume
• Network bottlenecks

Moving Mailboxes with Exchange PowerShell (Recommended)

For experienced administrators, PowerShell is the preferred and more powerful option.

PowerShell allows:

• Bulk mailbox moves
• Filtering by database, OU, or mailbox size
• Better reporting and automation
• Safer rollback control

Basic Mailbox Move Using PowerShell

New-MoveRequest -Identity "[email protected]" -TargetDatabase "DB02"

Sample output:

DisplayName StatusDetail        TotalMailboxSize               PercentComplete
----------- ------------        ----------------               ----------------
Doe John    WaitingForJobPickup 4.891 GB (5,251,716,383 bytes)  0

You can also specify the user by display name:

New-MoveRequest -Identity "Doe John" -TargetDatabase "DB02"

Advanced PowerShell Scenarios (Real-World Use)

Move All Mailboxes from One Database to Another

Get-Mailbox -Database "DB01" | New-MoveRequest -TargetDatabase "DB02"

Commonly used during:

• Database retirement
• Storage migrations
• DAG rebalancing

Monitor Move Progress

Get-MoveRequest | Get-MoveRequestStatistics

Clean Up Completed Move Requests

Mailbox move requests do not remove themselves automatically.

Get-MoveRequest -MoveStatus Completed | Remove-MoveRequest

Leaving completed requests behind clutters reporting and can confuse junior admins.

Performance Tuning and Best Practices (Experience-Based)

Throttle Large Moves

Avoid moving:

• Too many large mailboxes at once
• During business hours
• While backups are running

Exchange shares resources aggressively. Poor scheduling can impact every mailbox on the server.

Antivirus Exclusions Matter

Ensure real-time AV excludes:

• Exchange database paths
• Log directories

Failure to do this is one of the top causes of slow or failed mailbox moves.

DAG Considerations

In DAG environments:

• Moves occur against the active database copy
• Replication health matters more than server load

Always verify copy status before bulk moves.

Common Mistakes to Avoid

• Moving mailboxes to a database with insufficient free space
• Running large migrations during peak hours
• Forgetting to clean up completed move requests
• Ignoring move request warnings
• Treating mailbox size as the only performance factor

Mailbox item count and folder structure often matter more than raw size.

EAC vs PowerShell: Which Should You Use?

In production environments, PowerShell should be your default.

Conclusion: Mailbox Moves Are Safe—If You Treat Them Seriously

Moving mailboxes between databases is a routine but foundational Exchange administration task. While Microsoft has made the process reliable, the outcome still depends heavily on:

• Planning
• Disk performance
• Proper scheduling
• Administrative discipline

Handled correctly, mailbox moves are low-risk and transparent to users. Handled casually, they become the source of performance issues, angry executives, and long nights.

If you manage on-prem Exchange today, mastering mailbox moves isn’t optional—it’s a core skill.

Daniel Lutton

From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.