Summary: While migrating from on-premises Exchange Server to another server or Exchange Online (Office 365), you might face issues with slowness of the seeding of the data or synchronization which would delay the final cutover. In this article, we will be discussing some possible solutions to resolve the issue. We’ll be also exploring an EDB converter application that can easily and directly migrate data to a live Exchange Server or Office 365.
While migrating from on-premises Exchange Server to a newer version of Exchange Server or Exchange Online, there could be a lot of factors that could affect the migration of data. One of the most important factors is the bandwidth. If you are migrating Exchange on-premises to Exchange Online, a good bandwidth will ensure quick passage of data. But sometimes, although you have a good connection, you still see low throughput in your migration. This could happen if your network team or Office 365 is throttling the connectivity to other services. This is used to protect the destination from the flood of the network and from your internal team so that the bandwidth is not hogged.
In the case of the local network team, you could transfer data during specific times and increase the limit during those times. There could be even cases where traffic to Exchange Online can be prioritized or passed through another connection. If the throttling is done by Microsoft, there isn’t much you can do. However, you can open a case with Microsoft or your local CSP to be exempted during the migration process.
Common on-premises and Exchange Online errors show the message StalledDueToSource_Reason on the source or destination. Some other errors when migrating from a local server to Exchange Online include.
- StalledDueToTarget_MdbAvailability
- StalledDueToTarget_MdbReplication
- StalledDueToTarget_DiskLatency
- StalledDueToTarget_Processor
- StalledDueToTarget_BigFunnel
Diagnosing Slow Migrations
The Diagnostic Info parameter is useful when troubleshooting migration stalls. This will give more information on where the stall is and how much time is being consumed by the stall. For this, you need to use the PowerShell command Get-MoveRequestStatistics in the Exchange Online PowerShell as given below.
$stats = Get-MoveRequestStatistics -identity -DiagnosticInfo "verbose,showtimeslots,showtimeline"This will get all the information needed and store it in the $stats object. You can then output to file and analyze the XML tags to get the information needed.
The best thing is to export the output to a file and analyze the file using an XML viewer like Notepad++ and open it as XML language. So, it would be easier to navigate, collapse, and expand the elements.
To dig deeper, you can use the Get-MoveRequestStatistics command to get the total of the stalls, which will show where the migration is stuck or where the delay is happening.
Get-MoveRequestStatistics -Identity '<user email address>' -DiagnosticInfo 'verbose,showtimeslots' | export-clixml <xml path ex. C:\temp\export.xml>Apart from the move statistics, this will show all the stalls’ duration so that you can see where the time is being consumed.
An important thing to check is the StatusDetail. This will show the root cause of your issue.
To start with, check your source server. Your source server should not have any issues with the setup and configuration and have all the requirements for the migration. You can check the databases and their state. For this, you can use the Get-MailboxDatabaseCopyStatus PowerShell command and confirm that all databases are healthy and mounted.
Hybrid Performance Factors
As seen above, you need to look into the following five performance factors:
- Data Source (Exchange Server): You need to ensure that your server is up to speed with updates, hardware resources, and the performance of the storage. You also need to ensure that the operating system and the Exchange Server are working perfectly and do not have any issues with any components. Along with this, you should also make sure that there are no background tasks affecting the performance or throughput.
- Migration Server: If you are using a push/pull migration having a hybrid server, you need to make sure that the server has good specifications.
- Migration Engine: You need to choose the right migration method – cutover, staged, hybrid, or third-party application. Choosing the wrong method could lead to delays and possible data integrity issues.
- Network: Network including local infrastructure, perimeter network, and internet connectivity, must be set not to throttle the Exchange Server services, along with the right bandwidth assigned to the service.
- Office 365 Service: Although you might have the above at the recommended levels, you need to ensure that you have the right policies, subscriptions, and settings in place for the hybrid deployment to be optimal. Office 365 has its own health-based throttling effects which to an extent, are not controlled by you.
Alternative Method
For migration, you can use applications such as Stellar Converter for EDB. Using this application, you can easily open any EDB file from any version of Exchange Server without having an active Exchange Server. You can explore through the mailbox database and granularly convert EDB to PST and other formats. You can also export directly to an Office 365 tenant or a live Exchange Server. In addition to mailboxes, you can export archive mailboxes, shared mailboxes, disabled mailboxes, and even Public Folders with ease.
Conclusion
When migrating, it is important to check the performance of the network and the server you are exporting from. You need to also make sure that your hardware and storage is capable to support the load you will be passing. You need to consider the effort and administrative burden when making such migrations and make sure that the right migration tool is used as it will make your life easier.
