Overview
To help you plan your migration, the following tables present guidelines about when to expect bulk mailbox migrations or individual migrations to complete. These estimates are based on data analysis of previous customer migrations. Because every environment is unique, your exact migration velocity may vary.
Mailbox migration duration based on mailbox size profiles
Onboarding / PSTImport
| Mailbox size (GB) | 50th percentile duration (days) | 90th percentile duration (days) |
|---|---|---|
| < 1 | 1 | 7 |
| 1 - 10 | 1 | 7 |
| 10 - 50 | 3 | 14 |
| 50 - 100 | 3 | 30 |
| 100 - 200 | 8 | 45 |
| > 200 | Not supported | Not supported |
Multi-Geo / GoLocal / Encryption
| Mailbox size (GB) | 50th percentile duration (days) | 90th percentile duration (days) |
|---|---|---|
| < 1 | 1 | 7 |
| 1 - 10 | 1 | 10 |
| 10 - 50 | 3 | 30 |
| 50 - 100 | 15 | 45 |
| 100 - 200 | 30 | 60 |
| > 200 | Not supported | Not supported |
Migration Performance factors
Email migration has several common factors that can affect migration performance.
Common migration performance factors
The following table provides a list of common factors that affect migration performance.
| Factor | Description | Example |
|---|---|---|
| Data source | The device or service that hosts the data to be migrated. Many limitations might apply to the data source because of hardware specifications, end-user workload, and back-end maintenance tasks. | Gmail limits how much data can be extracted during a specific period of time. |
| Data type and density | Because of the unique nature of a customer's business, the type and mix of mail items within mailboxes vary greatly. | One 4-GB mailbox with 400 items, each with 10 megabytes (MB) of attachments, will migrate faster than one 4-GB mailbox with 100,000 smaller items. |
| On-premises network appliances | The end-to-end network performance (from the data source to Exchange Online client access servers) affects migration performance. | Firewall configuration and specifications on the on-premises organization. |
| Microsoft 365 or Office 365 service | Microsoft 365 and Office 365 have built-in support and features to manage the migration workload. | The user-throttling policy has default settings and limits the overall maximum data transfer rate. |
Network performance factor
This section describes best practices for improving network performance during migration. The discussion is general because the biggest impact on network performance during migration is related to third-party hardware and Internet service providers (ISPs).
To run the Exchange Analyzer tests in Support and Recovery Assistant,
Go to Advanced Diagnostics > Exchange Online > Check Exchange Online network connectivity > Yes.
Read About the Microsoft Support and Recovery Assistant to learn more about Support and Recovery Assistant.
| Factor | Description | Example |
|---|---|---|
| Network capacity | The amount of time it takes to migrate mailboxes to Microsoft 365 or Office 365 is determined by the available and maximum capacity of your network. | Identify your available network capacity and determine the maximum upload capacity. Contact your ISP to confirm your allocated bandwidth and to get details about restrictions, such as the total amount of data that can be transferred in a specific period of time. Use tools to evaluate your actual network capacity. Make sure you test the end-to-end flow of data from your on-premises data source to the Microsoft datacenter gateway servers. Identify other loads on your network (for example, backup utilities and scheduled maintenance) that can affect your network capacity. |
| Network stability | A fast network doesn't always result in fast migrations. If the network isn't stable, data transfer takes longer because of error correction. Depending on the migration type, error correction can significantly affect migration performance. | Network hardware and driver issues often cause network stability problems. Work with your hardware vendors to understand your network devices and apply the vendor's latest recommended drivers and software updates. |
| Network delays | Intrusion detection functionality configured on a network firewall often causes significant network delays and affects migration performance. Migrating data to Microsoft 365 or Office 365 mailboxes relies on your internet connection. Internet delays affect overall migration performance. Also, users in the same company might have cloud mailboxes that reside in data centers in different geographical locations. Depending on the customer's ISP, migration performance may vary. | Evaluate network delays to all potential Microsoft datacenters to help ensure that the result is consistent. (This also helps ensure a consistent experience for end-users.) Work with your ISP to address internet-related issues. Add IP addresses for Microsoft datacenter servers to your allow list, or bypass all migration-related traffic from your network firewall. For more information about the Microsoft 365 or Office 365 IP ranges, see Microsoft 365 and Office 365 URLs and IP address ranges. |
- add region <<??>>
Microsoft 365 and Office 365 throttling
Microsoft 365 and Office 365 use various throttling mechanisms to help ensure security and service availability. The following types of throttling can affect migration performance:
Microsoft 365 and Office 365 user throttling
User throttling affects most third-party migration tools and the client-uploading migration method. These migration methods use client access protocols, such as the Remote Procedure Call (RPC) over HTTP Protocol, to migrate mailbox data to Microsoft 365 or Office 365 mailboxes. These tools are used to migrate data from platforms such as IBM Lotus Domino and Novell GroupWise.
User throttling is the most restrictive throttling method in Microsoft 365 and Office 365. Because user throttling is set up to work against an individual end-user, any application-level usage will easily exceed the throttling policy and result in slower data migration.
Microsoft 365 or Office 365 resource health-based throttling
All migration methods are subject to the governance of availability throttling. Microsoft 365 or Office 365 service throttling, however, doesn't affect Microsoft 365 or Office 365 migrations as much as the other types of throttling described previously.
Resource health-based throttling is the least aggressive throttling method. It occurs to prevent a service availability issue that could affect end users and critical service operations.
Before the performance of the service degrades to the point where end-user performance could be impacted, hybrid migrations will be stalled until performance is recovered and the service returns to a level below the throttling threshold.
The following are examples from an Exchange migration statistics report. They show the entries logged when the service-throttling threshold is exceeded.
Dos
1/25/2018 12:56:01 AM [BL2PRD0410CA012] Copy progress: 723/1456 messages, 225.8 MB (236,732,045 bytes)/416.5 MB (436,712,733 bytes). 1/25/2018 12:57:53 AM [BL2PRD0410CA012] Move for mailbox '/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx' is stalled because DataMoveReplicationConstraint is not satisfied for the database 'NAMPRD04DG031-db081' (agent MailboxDatabaseReplication). Failure Reason: Database edbf0766-1f2a-4552-9115-bb3a53a8380b doesn't satisfy constraint SecondDatacenter. There are no available healthy database copies. Will wait until 1/25/2018 1:27:53 AM. 1/25/2018 12:58:24 AM [BL2PRD0410CA012] Request is no longer stalled and will continue. 6/30/2017 00:03:58 [CY4PR19MB0056] Relinquishing job because of large delays due to unfavorable server health or budget limitations with a request throttling state 'StalledDueToTarget_DiskLatency'.
Solution and practice:
If you experience a similar situation, wait for the Microsoft 365 or Office 365 resources to become available.
Performance factors and best practices
This section describes factors that affect migrations using the IMAP, cutover, or staged migration methods. It also identifies best practices to improve migration performance.
Factor 1: Data source
| Checklist | Description | Best practices |
|---|---|---|
| System performance | Data extraction is an intensive task. The source system needs to have sufficient resources, such as CPU time and memory, to provide optimal migration performance. During migration, the source system is often close to full capacity in terms of the regular end-user workload. If system resources are inadequate, the additional workload that results from migration can affect end users. | Monitor system performance during a pilot migration test. If the system is busy, we recommend avoiding an aggressive migration schedule for the specific system because of potential migration slowness and service availability issues. If possible, enhance the source system performance by adding hardware resources and reduce the load on the system by moving tasks and users to other servers that aren't involved in the migration. For more information, see: When migrating from an on-premises Exchange organization where there are multiple mailbox servers, we recommend that you create a migration-user list that is evenly distributed across multiple mailbox servers. Based on individual server performance, the list can be further fine-tuned to maximize throughput. For example, if server A has 50 percent more resource availability than server B, it's reasonable to have 50 percent more users from server A in the same migration batch. Similar practices can be applied to other source systems. Perform migrations when servers have maximum resource availability such as after hours or on weekends and holidays. |
| Back-end tasks | Other back-end tasks that are running during migration time. Because it's a best practice to perform migration after business hours, it's common that migrations conflict with maintenance tasks (such as data backup) running on your on-premises servers. | Review other system tasks that might be running during migration. We recommend that you perform data migration when no other resource-intensive tasks are running. Note: For customers using on-premises Exchange, the common back-end tasks are backup solutions and Exchange store maintenance. |
| Throttling policy | It's a common practice to protect email systems with a throttling policy that sets a specific limit on how fast and how much data can be extracted from the system during a certain amount of time. | Verify what throttling policy is deployed for your email system. For example, Google Mail limits how much data can be extracted in a certain time period. Depending on the version, Exchange has policies that restrict IMAP access to the on-premises mail server (used by IMAP migrations) and RPC over HTTP Protocol access (used by cutover Exchange migrations and staged Exchange migrations). To check the throttling settings in an Exchange 2013 organization, run the Get-ThrottlingPolicy cmdlet. For more information, see Exchange Workload Management. For more information about IMAP throttling, see Migrate your IMAP mailboxes to Microsoft 365 or Office 365 For more information about RPC over HTTP Protocol throttling, see: |
Factor 2: Network
Verification tests: Depending on the migration method, you can try the following verification tests:
IMAP migrations: Pre-populate a source mailbox with sample data. Then from the internet (outside your on-premises network), connect to the source mailbox by using a standard IMAP email client such as Microsoft Outlook, and then measure network performance by determining how long it takes to download all the data from the source mailbox. The throughput should be similar to what customers can get by using the IMAP migration tool in Microsoft 365 or Office 365, given that there are no other constraints.
Factor 3: Microsoft 365 and Office 365 service
Microsoft 365 or Office 365 resource health-based throttling affects migrations using the native Microsoft 365 or Office 365 simple migration tools. See the Microsoft 365 or Office 365 resource health-based throttling section.