Microsoft 365和 Office 365 电子邮件迁移性能和最佳做法
有许多路径可将本地托管的组织的电子邮件数据迁移到 Microsoft 365 或 Office 365。 规划迁移到 Microsoft 365 或 Office 365 时，清楚地了解数据迁移过程和速度有助于管理员更好地进行规划。
将电子邮件迁移到 Microsoft 365 或 Office 365 的概述
Microsoft 365 或 Office 365 支持多种方法将电子邮件、日历和联系人数据从现有邮件环境迁移到 Microsoft 365 或 Office 365，如 将多个电子邮件帐户迁移到 Microsoft 365 或 Office 365 的方法中所述。
有关 Microsoft 365 或 Office 365 上的网络和性能相关问题，请参阅 Microsoft 365 或 Office 365 的网络规划和性能优化。
常用的迁移方法
| 迁移方法 | 说明 | 资源 |
|---|---|---|
| Internet 消息访问协议 (IMAP) 迁移 | 可以使用 Exchange 管理中心 或 Exchange Online PowerShell 将用户邮箱的内容从 IMAP 邮件系统迁移到其 Microsoft 365 或 Office 365 邮箱。 其中包括从其他托管电子邮件服务（如 Gmail 或 Yahoo Mail）迁移邮箱。 请注意，Exchange Online 现在 在现代 EAC 中提供了高度专业化的过程 ，用于将电子邮件从现有 Gmail/G Suite/Google WorkSpace (GWS) 部署到 Exchange Online。 | 将 IMAP 邮箱迁移到 Microsoft 365 或 Office 365 |
| 直接转换迁移 | 使用直接转换迁移在几天内将所有本地邮箱迁移到 Microsoft 365 或 Office 365。 如果你计划将整个电子邮件组织移动到 Microsoft 365 或 Office 365 并在 Microsoft 365 或 Office 365 中管理用户帐户，请使用直接转换迁移。 使用直接转换迁移，最多可以将 2,000 个邮箱从本地 Exchange 组织迁移到 Microsoft 365 或 Office 365。 但是，建议的邮箱数为 150。 性能可能会下降，其数字高于该数字。 本地 Exchange 组织中的邮件联系人和通讯组也将进行迁移。 | 直接转换到 Microsoft 365 或 Office 365 |
| 暂存迁移 | 如果你计划随着时间的推移最终将组织的所有邮箱迁移到 Microsoft 365 或 Office 365，请使用分阶段迁移。 使用分阶段迁移，可以在几周或几个月内将批量本地邮箱迁移到 Microsoft 365 或 Office 365。 | 需要了解的有关暂存电子邮件迁移到 Microsoft 365 或 Office 365 的信息 |
| 混合部署 | 混合部署使组织能够将现有本地 Exchange 组织的丰富功能体验和管理控制扩展到云。 混合部署提供本地 Exchange 组织与 Microsoft 365 或 Office 365 中的 Exchange Online 之间的无缝外观。 此外，混合部署可以作为完全迁移到 Microsoft 365 或 Office 365 组织的中间步骤。 |
Microsoft 365 和 Office 365 邮件迁移顾问 Exchange Server 混合部署 邮件迁移顾问 Exchange 本地 Exchange 部署助手 2013/2016/2019 Exchange Server 2013 混合部署 最低混合配置 |
| 第三方迁移 | 第三方提供了许多可用的工具。 它们使用独特的协议和方法从 GWS、GoDaddy、Yahoo、IBM Lotus Notes 和 Novell GroupWise 等电子邮件平台进行电子邮件迁移。 | 以下是可协助从第三方平台进行 Exchange 迁移的一些第三方迁移工具与合作伙伴： 二进制树 / 追求 / QuadroTech：Binary Tree 和 QuadroTech 现在是 Quest 的一部分。 Quest 是跨平台消息迁移和共存软件的提供商，提供用于在多个平台之间分析、共存和迁移到 Exchange Online 的产品。 任务解决方案同步邮箱、公用文件夹和日历信息，同时在整个迁移过程中保持共存。 BitTitan：提供从各种平台迁移到 Microsoft 365 或 Office 365 的自动化解决方案。 CodeTwo：Microsoft 365 和 Office 365 迁移解决方案提供商，用于从 Exchange 本地、IMAP 服务器以及 Microsoft 365 租户之间安全且自动地将数据迁移到 Microsoft 365 (Office 365) 。 Transvault：从 Exchange 和 Notes 迁移到 Microsoft 365 的 Cloud Office 迁移解决方案提供商。 Transvault 支持数十个迁移源，并提供提供任何规模的项目、复杂的电子邮件存档迁移和 PST 管理的产品。 企业迁移解决方案安全、合规、高效且以用户为中心，可以在本地和云中运行。 SkyKick：自动迁移解决方案提供商，用于从多个源类型迁移到 Microsoft 365 或 Office 365。 该工具为端到端的迁移工具，可帮助合作伙伴销售、规划、迁移、管理和现场实施迁移项目。 BCC：通过支持其协作迁移策略来帮助公司。 基于 Domino 平台的一流迁移工具供应商，用于迁移到 Microsoft Exchange、Microsoft 365 和 Office 365。 |
迁移方法的性能
以下部分比较了邮箱迁移工作负载以及将邮箱和邮箱数据迁移到 Microsoft 365 或 Office 365 的不同迁移方法的观察性能结果。 这些结果基于内部测试和实际客户迁移到 Microsoft 365 或 Office 365 的结果。
重要
由于执行迁移的方式以及执行迁移的时间不同，实际迁移速度可能会有所不同。
客户迁移工作负载
下表介绍了典型迁移中涉及的不同工作负载，以及每个工作负载的挑战和选项。
| Workload | 注释 |
|---|---|
| 加入 (迁移到 Microsoft 365 或 Office 365) | Microsoft 提供数据迁移功能和工具，供客户通过直接转换/暂/存混合) 或 Gmail/S Suite/GWS（又称 Google 工作区 (）从 Exchange Server 本地 (迁移数据，PowerShell) 或从其他 IMAP 源 (PowerShell、Gmail 通过 IMAP) 或跨租户迁移到 Microsoft 365 或 Office 365 中的 Exchange Online。 |
| 多地理位置 | 在世界各地设有办事处的跨国公司通常需要将其员工静态数据存储在特定区域，以满足其数据驻留要求。 多地理位置使单个 Microsoft 365 或 Office 365 组织能够跨多个 Microsoft 365 或 Office 365 数据中心地理位置， (地理位置) ，从而能够在所选的地理位置中按用户存储 Exchange 静态数据。 有关详细信息，请参阅 使用多地理位置获取企业级全局数据位置控件。 |
| 加密 | 使用客户密钥进行服务加密是一项功能，允许客户预配和管理根密钥，这些密钥用于加密 Microsoft 365 或 Office 365 中应用程序层的静态数据。 对于首次加密的邮箱，需要移动邮箱。 有关详细信息，请参阅 使用 Microsoft Purview 客户密钥进行服务加密。 |
| GoLocal | Microsoft 将继续在新区域或地理位置开设新的数据中心。 现有客户如果符合条件，可以请求将其客户数据从其原始数据中心移动到新的地理位置。 发出此请求的期限通常为一年或两年，具体取决于服务的总体需求。 请注意，一旦数据中心 (DC) 启动新异地 (，此时你大约需要三到六个月的时间请求移动) ，就可以请求移动客户数据的时间会缩短。 有关详细信息，请参阅 将核心数据移动到新的 Microsoft 365 数据中心地理位置。 |
在 Microsoft 365 数据中心内迁移邮箱时，每次移动邮箱或批量移动邮箱都需要一段时间才能完成操作。 有许多因素（例如 Microsoft 365 服务活动）可能会确切地影响多少时间。 该服务旨在限制邮箱移动等任意工作负载，以确保服务以最佳方式为所有用户运行。 但是，仍可以预期邮箱移动得到处理，具体取决于服务的任意资源可用性。 有关资源限制的更多详细信息，请参阅 此博客文章。
Exchange Online 中邮箱迁移的持续时间估计
为了帮助你规划迁移，下表提供了有关何时需要完成批量邮箱迁移或单个迁移的指南。 这些估计基于对以前客户迁移的数据分析。 由于每个环境都是唯一的，因此确切的迁移速度可能会有所不同。
基于邮箱大小配置文件的邮箱迁移持续时间：
GoLocal/多地理位置/Exchange Online 中的加密
Workload 邮箱大小 (GB) P50 (第 50 百分位持续时间) (天) P90 (第 90 百分位持续时间) (天) GoLocal/多地理位置/加密 0 - 10 1 1 GoLocal/多地理位置/加密 10 - 50 2 6 GoLocal/多地理位置/加密 50 - 100 4 11 GoLocal/多地理位置/加密 100 - 200 6 14 GoLocal/多地理位置/加密 > 200 不支持 不支持 从本地 Exchange Server 加入到 Exchange Online (直接转换/分/阶段混合)
Workload 邮箱大小 (GB) P50 (第 50 百分位持续时间) (天) P90 (第 90 百分位持续时间) (天) 从本地载入 0 - 10 1 3 从本地载入 10 - 50 2 6 从本地载入 50 - 100 4 13 从本地载入 100 - 200 10 31 从本地载入 > 200 不支持 不支持 跨租户迁移到 Exchange Online (使用 Microsoft 第一方解决方案 或使用 第三方解决方案) 。
Workload 邮箱大小 (GB) P50 (第 50 百分位持续时间) (天) P90 (第 90 百分位持续时间) (天) 跨租户 0 - 10 1 1 跨租户 10 - 50 1 2 跨租户 50 - 100 2 5 跨租户 100 - 200 3 6 跨租户 > 200 不支持 不支持 从 Gmail/G Suite/GWS (EAC、 PowerShell)
Workload 邮箱大小 (GB) P50 (第 50 百分位持续时间) (天) P90 (第 90 百分位持续时间) (天) 专用 Gmail 载入 0 - 10 1 2 专用 Gmail 载入 10 - 50 1 8 专用 Gmail 载入 50 - 100 3 12 专用 Gmail 载入 100 - 200 5 19 专用 Gmail 载入 > 200 不支持 不支持 通过 IMAP) 从 IMAP 源 (其他 IMAP 源、 PowerShell、 Gmail 载入 Exchange Online
Workload 邮箱大小 (GB) P50 (第 50 百分位持续时间) (天) P90 (第 90 百分位持续时间) (天) 通用 IMAP 载入 0 - 10 1 1 通用 IMAP 载入 10 - 50 1 2 通用 IMAP 载入 50 - 100 1 8 通用 IMAP 载入 100 - 200 3 29 通用 IMAP 载入 > 200 不支持 不支持 -
Workload 邮箱大小 (GB) P50 (第 50 百分位持续时间) (天) P90 (第 90 百分位持续时间) (天) PST 导入 0 - 10 1 1 PST 导入 10 - 50 1 3 PST 导入 50 - 100 2 5 PST 导入 100 - 200 3 6 PST 导入 > 200 不支持 不支持
注意
根据邮箱配置文件，某些离群值邮箱需要更长的时间才能完成。 此外，如果租户平均具有较大的邮箱，这也可能导致迁移持续时间延长。
迁移性能因素
邮箱/电子邮件迁移有几个影响迁移性能的常见因素。
常见迁移性能因素
下表列出了影响迁移性能的常见因素。 每个迁移方法的说明部分中含有更多详细信息。
| 因素 | 说明 | 示例 |
|---|---|---|
| 数据源 | 用于托管要迁移的数据的设备或服务。 由于硬件规格、最终用户工作负载以及后端维护任务的原因，数据源可能会受到很多限制。 | Gmail 限制了特定时间段内可以提取的数据量。 |
| 数据类型和密度 | 由于客户业务的独特性，邮箱内的邮件类型和组合差异很大。 | 如果一个 4 GB 的邮箱中包含 400 封邮件，每封邮件带有 10 兆字节 (MB) 的附件，那么此邮箱的迁移速度会快于包含 100,000 封较小邮件的 4-GB 邮箱。 |
| 迁移服务器 | 许多迁移解决方案都使用"jump box"类型的迁移服务器或工作站来完成迁移。 | 客户通常使用低性能的虚拟机来托管 MRSProxy 服务，以进行混合部署或客户端电脑的非混合迁移。 |
| 迁移引擎 | 如有必要，负责从源服务器拉取数据的数据迁移引擎会转换数据。 然后，引擎通过网络传输数据，并将数据注入 Microsoft 365 或 Office 365 邮箱。 邮箱。 | MRSProxy 服务有其自己的功能和限制。 |
| 本地网络设备 | 从数据源到 Exchange Online 客户端访问服务器的端到端网络性能 () 会影响迁移性能。 | 本地组织的防火墙配置和规格。 |
| Microsoft 365 或 Office 365 服务 | Microsoft 365 和 Office 365 具有用于管理迁移工作负载的内置支持和功能。 | 用户限制策略有默认设置，并且会限制总体的最大数据传输速率。 |
网络性能因素
本节介绍在迁移过程中提高网络性能的最佳做法。 此讨论是常规性讨论，因为迁移过程中对网络性能的最大影响与第三方硬件和 Internet 服务提供商 (ISP) 有关。
使用 Exchange 分析器更深入地了解与 Microsoft 365 或 Office 365 的网络连接。 若要在 Microsoft 支持和恢复助手中运行 Exchange 分析器测试，请转到高级诊断 > Exchange Online > 检查 Exchange Online 网络连接 > 是。 阅读有关 Microsoft 支持和恢复助手的信息，详细了解 Microsoft 支持和恢复助手。
| 因素 | 说明 | 最佳做法 |
|---|---|---|
| 网络容量 | 将邮箱迁移到 Microsoft 365 或 Office 365 所需的时间取决于网络的可用容量和最大容量。 | 确定可用网络容量和最大上传容量。 联系 ISP 以确认分配的带宽，并获得有关限制的详细信息（如在特定时间段内可传输的数据总量）。 使用工具来评估实际网络容量。 务必测试从本地数据源到 Microsoft 数据中心网关服务器的端到端数据流。 识别网络上可能影响网络容量的其他负载（例如备份实用程序和定期维护）。 |
| 网络稳定性 | 网络速度快并不意味着迁移速度就一定快。 如果网络不稳定，那么数据传输可能因错误纠正而需要更长时间。 错误纠正可能会显著影响迁移性能，具体取决于迁移类型。 | 网络硬件和驱动程序问题通常会导致网络稳定性问题。 请与硬件供应商协作以了解网络设备，并应用供应商建议的最新驱动程序和软件更新。 |
| 网络延迟 | 网络防火墙上配置的入侵检测功能通常会导致严重的网络延迟并影响迁移性能。 将数据迁移到 Microsoft 365 或 Office 365 邮箱依赖于 Internet 连接。 Internet 延迟会影响总体迁移性能。 此外，同一公司中的用户可能具有位于不同地理位置的数据中心中的云邮箱。 迁移性能可能有所不同，具体取决于客户的 ISP。 |
评估所有潜在 Microsoft 数据中心的网络延迟，以帮助确保结果一致。 (这也有助于确保最终用户的一致体验。) 与 ISP 合作解决与 Internet 相关的问题。 将 Microsoft 数据中心服务器的 IP 地址添加到允许列表，或绕过来自网络防火墙的所有与迁移相关的流量。 有关 Microsoft 365 或 Office 365 IP 范围的详细信息，请参阅 Microsoft 365 和 Office 365 URL 和 IP 地址范围。 |
有关环境中迁移的更深入分析，请查看 邮箱迁移性能分析。 文章中包含有一个脚本，可帮助分析移动请求。
Microsoft 365 和 Office 365 限制
Microsoft 365 和 Office 365 使用各种限制机制来帮助确保安全性和服务可用性。 以下三种限制类型可能影响迁移性能：
- 用户限制
- 迁移服务限制
- 基于资源运行状况的限制
注意
三种类型的 Microsoft 365 和 Office 365 限制不会影响所有迁移方法。
Microsoft 365 和 Office 365 用户限制
用户限制将影响大多数第三方迁移工具和客户端上传迁移方法。 这些迁移方法使用客户端访问协议（如远程过程调用 (RPC) ）将邮箱数据迁移到 Microsoft 365 或 Office 365 邮箱。 这些工具通常用于从 IBM Lotus Domino 和 Novell GroupWise 等平台迁移数据。
用户限制是 Microsoft 365 和 Office 365 中限制性最高的限制方法。 由于用户限制设置为针对单独的最终用户，因此任何应用程序级使用都很容易超出限制策略，从而导致数据迁移变慢。
Microsoft 365 和 Office 365 迁移服务限制
迁移服务限制会影响所有 Microsoft 365 或 Office 365 迁移工具。 迁移服务限制管理 Microsoft 365 或 Office 365 迁移解决方案的迁移并发和服务资源分配。
迁移服务限制将影响使用以下迁移方法执行的迁移：
- IMAP 迁移
- 直接转换 Exchange 迁移
- 暂存 Exchange 迁移
- 混合迁移（混合环境中基于 MRSProxy 服务的移动）
重要
上述迁移方法不受用户限制的影响。
迁移服务限制的示例之一是控制在简单 Exchange 迁移和 IMAP 迁移期间同时迁移的邮箱数量。 默认值为 20。 这意味着随时迁移所有迁移批处理中的最多 20 个邮箱。 可以在 Exchange 管理中心或 Windows PowerShell 中增加迁移批处理的并发邮箱迁移数。 若要详细了解如何优化此设置，请参阅 在 Microsoft 365 或 Office 365 中管理迁移批处理。
基于 Microsoft 365 或 Office 365 资源运行状况的限制
所有迁移方法都受可用性限制的治理。 但是，Microsoft 365 或 Office 365 服务限制对 Microsoft 365 或 Office 365 迁移的影响不会像前面所述的其他类型的限制那样影响。
基于资源运行状况的限制是最保守的限制方法。 它的实施目的在于预防可能影响最终用户和关键服务操作的服务可用性问题。
在服务性能降级到可能影响最终用户性能的程度之前，混合迁移将会停止，直到性能恢复并且服务返回到低于限制阈值的水平。
下面显示了客户在使用 Get-MoveRequestStatistics - <> -IncludeReport cmdlet 时会看到的有关停止持续时间的内容：
$R.REPORT.TARGETTHROTTLES
NETWORKTHROTTLE : 00:00:00
CPUTHROTTLE : 00:02:07.6222549
REMOTESERVERTHROTTLE : 00:00:00
MDBREPLICATIONTHROTTLE : 00:38:41.7018480
CONTENTINDEXINGTHROTTLE : 00:00:00
BIGFUNNELTHROTTLE : 00:00:00
MDBAVAILABILITYTHROTTLE : 00:26:34.6588104
DISKLATENCYTHROTTLE : 1.15:45:37.7873632
$R.REPORT.SOURCETHROTTLES
NETWORKTHROTTLE : 00:00:00
CPUTHROTTLE : 3.03:21:07.7192848
REMOTESERVERTHROTTLE : 00:00:00
MDBREPLICATIONTHROTTLE : 00:00:00
CONTENTINDEXINGTHROTTLE : 00:00:00
BIGFUNNELTHROTTLE : 00:00:00
MDBAVAILABILITYTHROTTLE : 00:00:00
DISKLATENCYTHROTTLE : 00:20:47.1101552
MDBMAINTENANCETHROTTLE : 00:00:00
解决方案和实践：
如果遇到类似的情况，请等待 Microsoft 365 或 Office 365 资源可用。
非混合部署迁移的性能因素和最佳做法
本部分介绍使用 IMAP、直接转换或暂存迁移方法影响迁移的因素。 它还确定了提高迁移性能的最佳做法。
因素 1：非混合部署迁移的数据源
下表介绍了对由当前电子邮件组织中的源服务器执行迁移的影响以及缓解对迁移的影响的最佳做法。
| 清单 | 说明 | 最佳做法 |
|---|---|---|
| 系统性能 | 数据提取是一项资源密集型任务。 源系统需要有足够的资源（如 CPU 时间和内存）才能提供最佳迁移性能。 迁移过程中，在常规最终用户工作负载方面，源系统通常会接近于最大容量。 如果系统资源不足，那么迁移产生的其他工作负载可能会影响最终用户。 | 在试点迁移测试过程中监视系统性能。 如果系统繁忙，建议不要对特定系统执行很占用资源的迁移计划，因为这可能导致迁移变慢和服务可用性问题。 如果可能，应通过增加硬件资源和减少系统中的负载（通过将任务和用户移至迁移未涉及的其他服务器）来提高源系统性能。 有关详细信息，请参阅：Exchange Server (2007、2010、2013、2016、2019) 注意：不再主动支持 Exchange Server 2007 和 2010。 Exchange 2013 服务器终止支持计划于 2023 年 4 月结束。 Exchange Server 2016 和 2019 支持将延长到 2025 年 10 月。 有关更多详细信息，请参阅 Exchange Server 可支持性矩阵 。 从存在多个邮箱服务器的本地 Exchange 组织进行迁移时，建议创建在多个邮箱服务器中均匀分布的迁移用户列表。 根据各个服务器的性能，可以对该列表进一步微调以达到最大吞吐量。 例如，如果服务器 A 的资源可用性比服务器 B 高 50%，那么在同一个迁移批处理中让服务器 A 中多包含 50 % 的用户较为合理。 类似的做法可应用于其他源系统。 在服务器具有最大资源可用性（如下班后或周末和假日）时执行迁移。 |
| 后端任务 | 迁移期间运行的其他后端任务。 由于在营业时间后执行迁移是最佳做法，因此迁移通常会与在本地服务器上运行的数据备份) 等维护任务发生冲突 (。 | 查看在迁移期间可能会运行的其他系统任务。 建议在没有运行其他资源密集型任务时执行数据迁移。 注意：对于使用本地 Exchange 的客户，常见的后端任务是备份解决方案和 Exchange 存储维护 (2013、2016、2019) 。 |
| 限制策略 | 使用限制策略保护电子邮件系统是一种常见做法，该策略设置特定限制，规定在一定时间内可以从系统中提取数据的速度和数量。 | 验证为电子邮件系统部署的限制策略。 例如，Google Mail 限制在特定时间段内可以提取的数据量。 Exchange 具有限制对本地邮件服务器（用于 IMAP 迁移）进行 IMAP 访问的策略以及限制 RPC over HTTP 协议访问（用于直接转换 Exchange 迁移和暂存 Exchange 迁移）的策略，具体取决于软件版本。 若要检查限制设置，请运行 Get-ThrottlingPolicy cmdlet。 有关限制的详细信息，请参阅： (2007、 2010、 2013、 2016、 2019) 。 有关 IMAP 限制的详细信息，请参阅 将 IMAP 邮箱迁移到 Microsoft 365 或 Office 365。 |
因素 2：非混合部署迁移的迁移服务器
IMAP、直接转换和暂存迁移是云发起的数据拉取迁移方法，因此不需要专用的迁移服务器。 但是，面向 Internet 的协议主机 (IMAP 或 RPC over HTTP 协议) ，充当迁移服务器，用于将邮箱和邮箱数据迁移到 Microsoft 365 或 Office 365。 因此，有关当前电子邮件组织的数据源服务器的上一部分中所述的迁移性能因素和最佳做法也适用于 Internet 边缘服务器。 对于 Exchange 2007、Exchange 2010 和 Exchange 2013 组织，客户端访问服务器将作为迁移服务器。
有关更多信息，请参阅：
因素 3：非混合部署迁移的迁移引擎
IMAP、直接转换和暂存 Exchange 迁移通过使用 Exchange 管理中心中的迁移仪表板来执行。 这受 Microsoft 365 或 Office 365 迁移服务限制的约束。
解决方案和实践：
客户现在可以使用 Windows PowerShell 指定迁移并发（例如要同时迁移的邮箱数）。 默认值为 20 个邮箱。 创建迁移批处理后，可使用以下 Windows PowerShell cmdlet 将此默认值增加到最大值 100。
Set-MigrationEndPoint <Identity> -MaxConcurrentMigrations <value between 1 and 100>
有关详细信息，请参阅 在 Microsoft 365 或 Office 365 中管理迁移批处理。
注意
如果数据源没有足够的资源来管理所有连接，我们建议避免高并发性。 应该先使用较低的并发值，例如 10。 然后在监视数据源性能期间增加此值，以避免最终用户访问问题。
因素 4：非混合部署迁移的网络
验证测试：
根据迁移方法，可以尝试以下验证测试：
IMAP 迁移：使用示例数据预填充源邮箱。 然后，从 Internet (本地网络) 外部，使用标准 IMAP 电子邮件客户端（如 Microsoft Outlook）连接到源邮箱，然后通过确定从源邮箱下载所有数据所需的时间来衡量网络性能。 鉴于没有其他限制，吞吐量应类似于客户使用 Microsoft 365 或 Office 365 中的 IMAP 迁移工具可以获得的吞吐量。
直接转换和暂存 Exchange 迁移：使用示例数据预填充源邮箱。 然后，从本地网络) 外部的 Internet (，使用 RPC over HTTP 协议通过 Outlook 连接到源邮箱。 请确保使用 缓存模式进行连接。 Measure network performance by checking how long it takes to synchronize all data from the source mailbox. 鉴于没有其他限制，吞吐量应类似于客户使用 Microsoft 365 或 Office 365 中的简单 Exchange 迁移工具可以获得的吞吐量。
在实际的 IMAP、直接转换或暂存 Exchange 迁移过程中可能存在一定开销。 但实际的吞吐量应近似于这些验证测试的结果。
因素 5：用于非混合部署迁移的 Microsoft 365 和 Office 365 服务
基于 Microsoft 365 或 Office 365 资源运行状况的限制会影响使用本机 Microsoft 365 或 Office 365 简单迁移工具的迁移。 请参阅 基于 Microsoft 365 或 Office 365 资源运行状况的限制 部分。
在 Microsoft 365 或 Office 365 中移动请求
有关获取移动请求的状态信息的常规信息，请参阅查看移动请求属性：
[Get-MoveRequestStatistics]] (/powershell/module/exchange/get-moverequeststatistics)
在 Microsoft 365 或 Office 365 服务中，迁移队列和为迁移分配的服务资源在租户之间共享，并影响如何在移动过程的每个阶段管理移动请求。
Microsoft 365 和 Office 365 中有两种类型的移动请求：
载入“移动”请求：新客户迁移被视为载入移动请求。 这些请求的优先级一般。
数据中心内部“移动”请求：这些是数据中心运营团队发起的邮箱移动请求。 这些请求的优先级较低，因为移动请求延迟时，最终用户体验不会受到影响。
对状态为“已排队”和“正在进行”的移动请求的可能影响和延迟
已排队的移动请求：此状态指定移动已排队，并正在等待 Exchange 邮箱复制服务进行接听。 对于 Exchange 2003 移动请求，用户仍可在此阶段访问其邮箱。
以下两个因素将影响邮箱复制服务对请求的选取：
优先级：优先级较高的排队移动请求在优先级较低的移动请求之前被选取。 这有助于确保客户迁移移动请求总是先于数据中心内部移动请求得到处理。
队列中的位置：如果移动请求具有相同的优先级，则请求进入队列越早，邮箱复制服务会越早地选取该请求。 由于同时可能有多个客户执行邮箱迁移，因此新移动请求在处理前留在队列中的情况很常见。
通常，迁移规划过程中不会考虑邮箱请求在处理前在队列中等待的时间。 这将导致客户分配不到足够时间来完成所有计划的迁移。
- 正在进行的移动请求：此状态指定移动仍在进行中。 如果是联机邮箱移动，用户仍可访问邮箱。
邮箱移动请求进入"正在进行"状态后，优先级不再重要，在现有的"正在进行"移动请求完成之前，将不会处理新移动请求，即使新移动请求具有较高的优先级也是如此。
最佳做法
规划：如前所述，由于 Exchange 2003 用户在混合迁移期间失去访问权限，因此 Exchange 2003 客户通常更关心何时计划迁移以及需要多长时间。
计划要在特定时间段内进行迁移的邮箱数时，请考虑以下几点：
请包括移动请求在队列中等待的时间。 使用以下公式进行计算：
(要迁移的邮箱总数) = ( (总时间) - (平均队列时间) ) * (迁移吞吐量)
其中，迁移吞吐量等于每小时可迁移的邮箱总数。
例如，假设有 6 小时来迁移邮箱。 如果平均队列时间为 1 小时，并且迁移吞吐量为每小时 100 个邮箱，则可以在 6 小时的时间内迁移 500 个邮箱：500 = (6 - 1) * 100。
- 比最初计划更早地启动迁移以减少排队时间。 邮箱排队时，Exchange 2003 用户仍可访问其邮箱。
确定队列时间：由于 Microsoft 不管理客户的迁移计划，因此队列时间始终发生变化。
若要确定可能的排队时间，客户可尝试在实际迁移开始之前的数小时安排一次测试移动。 然后，根据观察到的请求排队时间，客户可以更准确地估计开始迁移的时间以及在指定时间段内可移动的邮箱数。
例如，假设测试迁移已在计划迁移开始之前 4 小时完成。 客户确定测试迁移的排队时间约为 1 小时。 然后，客户应考虑在最初计划时间的 1 小时前开始迁移，以确保有足够的时间完成所有迁移。
Microsoft 365 或 Office 365 迁移的第三方工具
第三方工具主要用于不涉及 Exchange 的迁移方案，例如来自 Gmail/G Suite/GWS (Google Workspace) 、IBM Lotus、Domino 和 Novell GroupWise 的工具。 本部分将重点介绍第三方迁移工具使用的迁移协议，而不是实际产品和迁移工具。 下表提供了适用于 Microsoft 365 或 Office 365 迁移方案的第三方工具的因素列表。
重要
如果使用第三方工具执行迁移后出现数据一致性或完整性问题，请联系提供该工具的供应商以获取支持。
因素 1：第三方工具迁移的数据源
| 清单 | 说明 | 最佳做法 |
|---|---|---|
| 系统性能 | 数据提取是一项资源密集型任务。 源系统必须有足够的资源（如 CPU 时间和内存）才能提供最佳迁移性能。 迁移过程中，在常规最终用户工作负载方面，源系统通常会接近于最大容量。 如果系统资源不足，那么迁移产生的其他工作负载可能会影响最终用户。 | 在试点迁移测试过程中监视系统性能。 如果系统繁忙，建议不要对特定系统执行很占用资源的迁移计划，因为这可能导致迁移变慢和服务可用性问题。 如果可能，应通过增加硬件资源和减少系统中的负载（通过将任务和用户移至迁移未涉及的其他服务器）来提高源系统性能。 有关详细信息，请参阅：Exchange Server (2007、2010、2013、2016、2019) 的服务器运行状况和性能。 注意：不再主动支持 Exchange Server 2007 和 2010。 Exchange 2013 服务器终止支持计划于 2023 年 4 月结束。 Exchange Server 2016 和 2019 支持将延长到 2025 年 10 月。 有关更多详细信息，请参阅 Exchange Server 可支持性矩阵 。 从存在多个邮箱服务器的本地 Exchange 组织进行迁移时，建议创建在多个邮箱服务器中均匀分布的迁移用户列表。 根据各个服务器的性能，可以对该列表进一步微调以达到最大吞吐量。 例如，如果服务器 A 的资源可用性比服务器 B 高 50%，那么在同一个迁移批处理中让服务器 A 中多包含 50 % 的用户较为合理。 类似的做法可应用于其他源系统。 在服务器具有最大资源可用性（如下班后或周末和假日）时执行迁移。 |
| 后端任务 | 通常在迁移期间运行的其他后端任务。 最佳做法是在下班之后执行迁移，因此经常会遇到迁移与您的内部部署服务器上运行的其他维护任务（如数据备份）相冲突的情况。 | 查看在迁移期间可能会运行的其他系统任务。 建议在没有运行其他资源密集型任务时执行数据迁移。 注意：对于使用本地 Exchange 的客户，常见的后端任务是备份解决方案和 Exchange 存储维护 (2013、2016、2019) 。 |
| 限制策略 | 使用限制策略保护电子邮件系统是一种常用做法，该策略使用特定迁移方法设置在一定时间内从系统提取数据的速度和数量方面的特定限制。 | 验证为电子邮件系统部署的限制策略。 例如，Google Mail 限制在特定时间段内可以提取的数据量。 Exchange 具有限制对本地邮件服务器（用于 IMAP 迁移）进行 IMAP 访问的策略以及限制 RPC over HTTP 协议访问（用于直接转换 Exchange 迁移和暂存 Exchange 迁移）的策略，具体取决于软件版本。 若要检查限制设置，请运行 Get-ThrottlingPolicy cmdlet。 有关限制的详细信息，请参阅： (2007、 2010、 2013、 2016、 2019) 。 有关 IMAP 限制的详细信息，请参阅 将 IMAP 邮箱迁移到 Microsoft 365 或 Office 365。 |
因素 2：用于第三方工具迁移的迁移服务器
大多数用于 Microsoft 365 或 Office 365 迁移的第三方工具都是客户端启动的，并将数据推送到 Microsoft 365 或 Office 365。 通常，这些工具需要迁移服务器。 源服务器的系统性能、后端任务和限制策略等因素均适用于这些迁移服务器。
注意
某些第三方迁移解决方案作为基于云的服务托管在 Internet 上，不需要本地迁移服务器。
解决方案和实践：
若要在使用迁移服务器时提高迁移性能，请应用与 因素 1：第三方工具迁移数据源 部分中所述的相同最佳做法。
因素 3：用于第三方工具迁移的迁移引擎
对于第三方迁移工具，最常用的协议是 Exchange Web 服务和 RPC over HTTP 协议。
Exchange Web 服务：
建议使用 Exchange Web 服务协议迁移到 Microsoft 365 或 Office 365，因为它支持大型数据批处理，并且具有更好的面向服务的限制。 在 Microsoft 365 或 Office 365 中，在模拟模式下使用时，使用 Exchange Web Services 的迁移不会消耗用户的预算 Microsoft 365 或 Office 365 Exchange Web Services 资源，而是使用预算资源的副本：
同一管理员帐户发出的所有 Exchange Web 服务模拟呼叫都独立于对此管理员帐户使用的预算而进行计算。
对于每个模拟会话，都创建了实际用户的预算卷影副本。 此特定会话的所有迁移都将占用此卷影副本。
模拟下的限制独立于每个用户迁移会话。
可以在租户 (中暂时更改 Exchange Web 服务限制策略，持续时间为 30、60 或 90 天，) 允许迁移完成。 可以从 Microsoft 365 管理中心的“帮助”部分请求此项。
最佳做法：
使用采用 EWA 模拟的第三方迁移工具的客户的迁移性能与基于 Exchange Web 服务的迁移和其他租户的服务资源使用量相当。 因此，迁移性能将会不同。
如有可能，客户应使用采用 Exchange Web 服务模拟的第三方迁移工具，因为这样通常比使用客户端协议（如 RPC over HTTP 协议）速度更快、效率更高。
RPC over HTTP Protocol：
传统的迁移解决方案使用 RPC over HTTP 协议。 此方法完全基于客户端访问模型（如 Outlook），并且可伸缩性和性能受到限制，因为 Microsoft 365 或 Office 365 服务限制访问，前提是使用情况由用户而不是应用程序使用。
最佳做法：
对于通过 HTTP 协议使用 RPC 的迁移工具，通常的做法是通过添加更多迁移服务器并使用多个 Microsoft 365 或 Office 365 管理用户帐户来增加迁移吞吐量。 这种做法可以获得数据注入并行度，并实现更高的数据吞吐量，因为每个管理用户都受 Microsoft 365 和 Office 365 用户限制的约束。 我们收到了一些报告，其中显示很多企业客户都必须安装 40 个以上的迁移服务器才能获得每小时 20-30 GB 的迁移吞吐量。
在迁移工具开发阶段，考虑迁移邮件所需的 RPC 操作的数量非常重要。 为了说明这一点，我们收集了 Microsoft 365 或 Office 365 服务为两个第三方迁移解决方案捕获的日志， (由第三方公司开发，) 客户用来将邮箱迁移到 Microsoft 365 或 Office 365。 我们比较了第三方公司开发的这两个迁移解决方案。 我们比较了在每个迁移解决方案下两个邮箱的迁移情况，并且还通过在 Outlook 中上传一个 .pst 文件进行了比较。 下面是比较的结果。
| 方法 | 邮箱大小 | 项目数 | 迁移时间 | RPC 事务总数 | 平均客户端延迟（毫秒） | AvgCasRPCProcessingTime（毫秒） |
|---|---|---|---|---|---|---|
| 解决方案 A（邮箱 1） | 376.9 MB | 4,115 | 4:24:33 | 132,040 | 48.4395 | 18.0807 |
| 解决方案 A（邮箱 2） | 249.3 MB | 12,779 | 10:50:50 | 423,188 | 44.1678 | 4.8444 |
| 解决方案 B（邮箱 1） | 618.1 MB | 4,322 | 1:54:58 | 12,196 | 37.2931 | 8.3441 |
| 解决方案 B（邮箱 2） | 56.7 MB | 2,748 | 0:47:08 | 5,806 | 42.1930 | 7.4439 |
| Outlook | 201.9MB | 3,297 | 0:29:47 | 15,775 | 36.9987 | 5.6447 |
注意
客户端和服务处理时间类似，但解决方案 A 需要执行更多的 RPC 操作来迁移数据。 由于每个操作都会消耗客户端延迟时间和服务器进程时间，因此与解决方案 B 和 Outlook 相比，解决方案 A 迁移相同数据量的速度要慢得多。
因素 4：用于第三方工具迁移的网络
最佳做法：
对于使用 RPC over HTTP 协议的第三方迁移解决方案，下面提供一个评测潜在迁移性能的好方法：
从迁移服务器，使用 RPC over HTTP 协议通过 Outlook 连接到 Microsoft 365 或 Office 365 邮箱。 请确保未使用 缓存模式进行连接。
将包含示例数据的大型 .pst 文件导入 Microsoft 365 或 Office 365 邮箱。
通过计算上传 .pst 文件所需的时间来评测迁移性能。 在没有其他限制的情况下，迁移吞吐量应近似于客户从使用 RPC over HTTP 协议的第三方迁移工具获得的吞吐量。 在实际迁移过程中存在其他开销，因此吞吐量可能稍有差异。
因素 5：Microsoft 365 和 Office 365 服务
Microsoft 365 和 Office 365 基于资源运行状况的限制会影响使用第三方迁移工具的迁移。 有关更多详细信息，请参阅 Microsoft 365 和 Office 365 资源运行状况限制 。