One of the issues when migrating your on-premise email into O365 has been the speed at which the O365 platform can accept the data. Microsoft has always had a data ingress throttling policy but that could always be switched off on a per tenant basis for a period of time during the on-boarding process. Thus temporarily by-passing the throttling restrictions enabled the migration into the O365 platform to proceed at an acceptable rate.
This by-pass facility had significant but positive implications for the on-boarding of large amounts of email data in terms of overall project time.
Unannounced Change
Without warning, migration service providers were reporting expected project times tripling or even quadrupling due to a dramatic reduction in the speed of data ingress. This created a big headache, frustration and in some instances, real embarrassment for the migration service providers with their clients.
Migration engineers initially thought that the system must have been misconfigured, however reconfiguring kept reporting the same message: “ Server busy. Try again later” It appeared that this was a global problem covering all projects and all regions. Had Microsoft introduced a bug into their system somewhere?
Support tickets were opened with Microsoft who initially denied that anything had changed, only confirming that “your tenant is already unthrottled”.
However, it eventually became clear that Microsoft had indeed implemented a new and permanent O365 system-wide protection layer called “Service Protection Throttling” which was completely independent of the familiar per tenant throttling layer.
Microsoft implemented this Service Protection Throttling layer to protect the service across the board. Prior to this, Microsoft had experienced issues where a tenant had caused an entire mailbox Database Availability Group – Microsoft Exchange (DAG) to be taken down which had impacted all users on that specific DAG. The main issue was that the store was unable to keep up with the amount of data being written to the database and the backup nodes could not keep up with the changes. The upshot of this situation was that when the DAG failed, data was lost.
So in response to this, understandably Microsoft implemented Service Protection Throttling that limits ingress of data to 150Mb per five minutes per mailbox so that the performance of one tenant does effect the performance of any other tenant in the shared environment.
They have also confirmed that in order maintain the integrity of the service as a whole this will not be removed under any circumstances and regardless of where the request comes from.
In a later development, Microsoft implemented a new Service Protection Throttling limit of 3600 emails into a single mailbox per hour (equivalent to 1 email per second)
The solution
It is worth noting that all third-party tools have exactly the same Microsoft imposed parameters to work under. Migration engineers will confirm there is no fancy cloud-based component or a hidden Microsoft back door that will allow the throttling protection layer to be by-passed – these imaginary features only exist in the minds of the copy-writers and marketeers.
UM through their innovative thinking and the application of their huge experience in managing some of the most complex email migration projects for the world’s biggest companies, continue to be able to achieve acceptable data ingress rates without circumventing valid throttling settings.
Next Steps
If you are about to undertake an email migration project into O365 whether from a legacy on-premise archive or from an alternative cloud-based archive, contact us to discuss your project and how we might help. We would be very happy to give you a demonstration of our unique software so you can see for yourself how easy it is to use.