When you try to migrate multiple mailboxes from one Exchange Server to another, to create database passive copies or server upgrade, Exchange Server uses several services or checks, such as Data Guarantee API. These services monitor the migration process, and in case of any issue, such as inconsistent logs, database copy not in sync, etc., it stalls the migration. A common stall status you get is the StalledDuetotarget_Mdbreplication.
This doesn’t mean the migration has failed; it tells the admin something is wrong, and the migration must be paused until the problem is fixed. In most cases, Exchange Server automatically resolves the issues and restarts the migration. In case that is not happening, there are a few methods you can try to fix StalledDuetotarget_Mdbreplication error in Exchange Server quickly. Moving further, this blog will help you understand the issue better and provide reliable troubleshoots to fix it.
What is StalledDuetotarget_Mdbreplication Issue in Exchange Server?
This condition usually surfaces when you try to copy/migrate a database that is a member of Database Availability Group (DAG) using the New-MoveRequest or run a migration batch (moving more than 10 mailboxes simultaneously). If any passive copy of the database fails to keep up with the data copy speed, or the server has to complete a high-value task, the migration will be stalled.
Don’t think of it as an error; it’s just a built-in mechanism that Exchange uses to make sure that the migration is proceeding as it should be and helps to make sure every database copy is up to date without any error.
Why you get the StalledDuetotarget_Mdbreplication in Exchange Server?
As I said above, it only happens with a DAG member database, and you will not get this issue with a standalone server migration. The most common reason for this event is:
- Network Latency: The data is moved through the internet. If your network bandwidth is not sufficient to move large sizes of data at a consistent speed to all the database copies, you will see the StalledDuetotarget_Mdbreplication as the status.
- Low Disk Storage Speed: Even if the network is fine, but your storage disk input/output speed is slow, the destination database and the passive copies will not be able to keep up with the migration speed. When that happens, the Exchange Server will stall the move/migration until every database is in proper synchronization.
- Insufficient Resources or a Deadlock: If you are migrating during the peak office hours or running a database backup simultaneously during the migration, the server resources will be divided. This will slow down the migration process. Moreover, a resource deadlock can also stall the database from moving.
- Issue with Replication Service: The Mailbox Replication Service in Exchange is the entity behind data copy. Any glitch or bug during it’s working can raise false alarms in the Exchange Server. Although it is very rare, it could happen and make the server think that something is wrong. This will turn the migration state to StalledDuetotarget_Mdbreplication
- Exchange Workload Management Throttling: This Exchange service manages the workload and makes sure the top priority (email send/receive, user interaction) work continues without any lag due to less priority tasks (database backup or migration). If you are moving more than 10 mailboxes at a time, the WLM will only allow 10 mailboxes to move and will automatically stall the remaining ones.
How to Resolve StalledDuetotarget_Mdbreplication Error in Exchange Server?
If the mailbox is in a stalled state for hours and you see no change, try the following methods to make it move again. Also, for your own benefit, make sure you have a healthy Exchange Server backup.
Method 1: Check for Slow Internet or Disk I/O Speed
Verify if the internet bandwidth is adequate to support the migration across all the database copies and increase it if necessary. Furthermore, check the destination server’s disk speed and upgrade it to faster NVMe SSDs to prevent any disk latency issues.
Method 2: Restart Replication Service Again
If network and storage are fine, try to restart the service. It’s a very common fix that generally works. To restart the migration, follow these steps:
- Login into Exchange Server as Admin. Make sure it is the same server from which you created the migration job.
- Open the Exchange Management Shell and run this command:
Restart-Service MSExchangeMailboxReplication
Note: The StalledDuetotarget_Mdbreplication error, may not be resolved instantly, wait for 10 to 15 minutes.
Method 3: Disable Data Guarantee Check
Data Guarantee feature of Exchange Server is also one of the reasons why you see the StalledDuetotarget_Mdbreplication status of the mailbox copy. If you disable this service, the Exchange Server will not know if there is any issue during the migration and will not be able to stall the mailbox transfer.
However, do it only when there is no other solution or if you are just doing a test migration. Disabling this service can have severe data integrity issues. You must have admin-level authorization to stop this service. Also, depending upon your Exchange Server, you may not find the dedicated option to disable it. Look for such services that are monitoring and initiating stalls, then turn them off.
Note: Enable all the services again as soon as the work is done.
Method 4: Increase Throttling Capacity
You can also try to modify the Workload Management service and increase the throttling capacity. By default, it is set to only allow 10 mailbox migrations at a given time. Increase this capacity to 20 or 30. After doing that, restart the replication service, and your migration status will turn from StalledDuetotarget_Mdbreplication to CopyingMessages. To increase the limit, do this:
- Go to the source Exchange Server, open Exchange Management Shell and run the following command:
- Then, run this command:
- Finally, resume the migration with this command:
- Identify the database copies and remove them all.
- Verify the “Standalone” status of the server.
- Restart the Migration Replication Service.
$limit = 30New-SettingOverride -Name “Migration-Concurrency-Increase” -Component WorkloadManagement -Section MdbReplication,MdbAvailability,DiskLatency,CiAgeOfLastNotification -Parameters @(“MaxConcurrency=$limit”) -Reason “Bulk migration “
Restart-Service MSExchangeDagMgmt
Resume-MigrationBatch “BatchNameOfYourMigration”
Method 5: Check the Server for Updates and Log Files
Check if any of the copy databases are outdated or have any technical issues. Make sure all the servers (passive and active) are using the same Exchange Server version as the source server. If necessary, install the latest Cumulative Updates (CUs) & Security Updates (SUs) on all servers.
Moreover, check for any old logs, clear them, and then restart the migration. Pending logs can prevent new logs from playing and cause the StalledDuetotarget_Mdbreplication issue in Exchange Server.
Method 6: Make the Server as Standalone
As previously mentioned, a primary reason you get this error is when the one or many passive database copies are not keeping up with the migration. If you isolate the active copy from all other databases, the data will only be transferred to a single destination. This will fix StalledDuetotarget_Mdbreplication issue in Exchange Server. You can do it like this:
Conclusion
Several events can lead to StalledDuetotarget_Mdbreplication error in Exchange Server. Check Event Viewer, log files, etc., tools analyze and find the real problem. Then use the appropriate method from the list above to resume the mailbox migration. Furthermore, if no solution works for you, then I recommend checking for database issues like corruption. Use the Exchange health check script to pinpoint an issue.
If corruption is the issue, then you must use a professional tool to safely repair and restore the database back to its normal state. One popular tool trusted by Exchange admins is Kernel for Exchange Server. This Exchange recovery tool scans your EDB files for any damage and resolves it without data loss.
![Fix Exchange Error 1018 [100% Working Methods]](https://www.nucleustechnologies.com/blog/wp-content/uploads/2025/09/exchange-error-1018.png)