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 的網路規劃和效能微調。
常用的移轉方法
| 移轉方法 | 描述 | 資源 |
|---|---|---|
| 網際網路訊息存取通訊協定 (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 之間單一 Exchange 組織的流暢外觀和風格。 此外，混合式部署可作為完全移至 Microsoft 365 或 Office 365 組織的中繼步驟。 |
Microsoft 365 和 Office 365 郵件移轉顧問 Exchange Server 混合式部署 郵件移轉建議程式 Exchange 內部部署 2013/2016/2019 的 Exchange 部署小幫手 Exchange Server 2013 混合式部署 完整或最小混合式設定 |
| 協力廠商移轉 | 協力廠商提供許多可供使用的工具。 他們使用獨特的通訊協定和方法，從 GWS、GoDaddy、Yahoo、IBM Lotus Notes 和 Novell GroupWise 等電子郵件平臺進行電子郵件移轉。 | 以下列出一些協力廠商移轉工具和合作夥伴，可協助從協力廠商平台進行 Exchange 移轉： 二進位樹狀結構 / 追求 / QuadroTech：二進位樹狀結構和 QuadroTech 現在是 Quest 的一部分。 Quest 是跨平臺傳訊移轉和共存軟體的提供者，其產品可在多個平台之間進行分析、共存和移轉至 Exchange Online。 Quest 解決方案會同步處理信箱、公用資料夾和行事曆資訊，同時在整個移轉期間維持共存。 BitTitan：提供從各種平臺移轉至 Microsoft 365 或 Office 365 的自動化解決方案。 CodeTwo：Microsoft 365 和 Office 365 移轉解決方案的提供者，可從 Exchange 內部部署、IMAP 伺服器，以及 Microsoft 365 租用戶之間，將安全且自動化的數據移轉至 Microsoft 365 (Office 365) 。 Transvault：從 Exchange 和 Notes 將雲端 Office 移轉解決方案提供者移轉至 Microsoft 365。 Transvault 支援數十個移轉來源，並提供可提供任何專案大小、複雜電子郵件封存移轉和 PST 管理的產品。 企業移轉解決方案是安全、相容、有效率且以用戶為焦點，而且可以在內部部署和雲端中執行。 SkyKick：自動化移轉解決方案的提供者，可從多個來源類型移至 Microsoft 365 或 Office 365。 端對端移轉工具可協助合作夥伴進行移轉專案的銷售、規劃、移轉、管理和現場階段。 BCC：協助公司支援其共同作業移轉策略。 在移轉至 Microsoft Exchange、Microsoft 365 和 Office 365 時，以 Domino 平臺為基礎的移轉工具類別供應商中最佳。 |
移轉方法的效能
下列各節會比較信箱移轉工作負載，以及將信箱和信箱數據遷移至 Microsoft 365 或 Office 365 的不同移轉方法所觀察到的效能結果。 這些結果是以內部測試和實際客戶移轉至 Microsoft 365 或 Office 365 為基礎。
重要事項
由於執行移轉的方式和執行時的差異，您的實際移轉速度可能會有所不同。
客戶移轉工作負載
下表描述一般移轉所涉及的不同工作負載，以及每個工作負載的挑戰和選項。
| 工作負載 | 附註 |
|---|---|
| 上線 (移轉至 Microsoft 365 或 Office 365) | Microsoft 提供數據遷移功能和工具，讓客戶透過分段混合//式) 或透過 EAC、PowerShell () 或從其他 IMAP (來源透過 EAC、PowerShell) 或從其他 IMAP 來源，透過 Microsoft 365 或 Office 365 的跨租使用者移轉，從 Exchange Server 內部部署) ( 移轉其數據，或從 Gmail/S Suite/GWS 移轉至 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 中的加密
工作負載 信箱大小 (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 (完全移轉/分段/混合式)
工作負載 信箱大小 (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 第一方解決方案 ，或使用 第三方解決方案) 。
工作負載 信箱大小 (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) 特製化上線至 Exchange Online
工作負載 信箱大小 (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 來源、 PowerShell、 Gmail 透過 IMAP 登入 Exchange Online)
工作負載 信箱大小 (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 不支援 不支援 -
工作負載 信箱大小 (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 會限制一段特定時間內可擷取的資料量。 |
| 資料類型和密度 | 由於客戶業務的獨特性質，信箱內的郵件項目類型和組合會有很大的差異。 | 一個具有 400 個項目的 4 GB 信箱 (每個項目各有 10 MB 的附件)，會比一個具有 100,000 個較小項目的 4 GB 信箱移轉得更快。 |
| 移轉伺服器 | 許多移轉解決方案會使用 "Jump Box" 類型的移轉伺服器或工作站來完成移轉。 | 客戶通常會使用低效能的虛擬機器來託管 MRSProxy 服務，以進行混合式部署或用戶端電腦非混合式移轉。 |
| 移轉引擎 | 必要時，負責從來源伺服器提取數據的數據遷移引擎會轉換數據。 引擎接著會透過網路傳輸數據，並將數據插入 Microsoft 365 或 Office 365 信箱。 郵箱。 | MRSProxy 服務有自己的功能和限制。 |
| 內部部署網路設備 | 從數據源到 Exchange Online 用戶端存取伺服器的端對端網路效能 () 會影響移轉效能。 | 內部部署組織上的防火牆設定和規格。 |
| Microsoft 365 或 Office 365 服務 | Microsoft 365 和 Office 365 具有管理移轉工作負載的內建支援和功能。 | 使用者節流原則有預設的設定，而且會限制整體資料傳送速率的上限。 |
網路效能因素
本節說明在移轉期間提升網路效能的最佳作法。 此為一般性討論，因為對移轉期間網路效能的最大影響是與協力廠商硬體和網際網路服務提供者 (ISP) 有關。
使用 Exchange Analyzer 來深入瞭解您與 Microsoft 365 或 Office 365 的網路連線能力。 若要在 Microsoft 支援服務和修復小幫手中執行 Exchange Analyzer 測試，請移至進階診斷 > Exchange Online > 檢查 Exchange Online 網路連線能力 > 是的。 若要深入瞭解 Microsoft 支援服務和修復小幫手，請參閱 Microsoft 支援及修復小幫手。
| 因素 | 描述 | 最佳作法 |
|---|---|---|
| 網路容量 | 將信箱移轉至 Microsoft 365 或 Office 365 所需的時間，取決於您網路的可用和最大容量。 | 找出您可用的網路容量，並決定上傳容量上限。 請連絡您的 ISP 以確認您的配置頻寬並取得相關限制的詳細資料，例如在一段特定時間內可傳送的總資料量。 使用工具來評估您的實際網路容量。 請務必從您的內部部署資料來源到 Microsoft 資料中心閘道伺服器，進行端對端資料流程的測試。 找出您的網路上會影響網路容量的其他負載 (例如，備份公用程式和排程維護)。 |
| 網路穩定性 | 快速網路未必能夠快速移轉。 如果網路不穩定，資料傳送則會因為錯誤修正而需要更久的時間。 視移轉類型而定，錯誤修正可能會大幅影響移轉效能。 | 網路硬體和驅動程式問題通常會導致網路穩定性問題。 請與您的硬體廠商合作，了解您的網路裝置並根據廠商建議使用最新驅動程式並進行軟體更新。 |
| 網路延遲 | 網路防火牆上所設定的入侵偵測功能通常會導致嚴重的網路延遲，而且會影響移轉效能。 將數據遷移至 Microsoft 365 或 Office 365 信箱，需仰賴因特網連線。 網際網路延遲會影響整體的移轉效能。 此外，同一間公司的使用者可能會有位於不同地理位置之資料中心的雲端信箱。 移轉效能可能會視客戶的 ISP 而有所不同。 |
評估所有 Microsoft 資料中心潛在的網路延遲，以協助確保結果一致 (這也有助於確保使用者的體驗一致)。 (這也有助於確保用戶的體驗一致。) 與您的 ISP 合作來解決因特網相關問題。 將 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 用戶節流
使用者節流會影響大部分的協力廠商移轉工具，以及用戶端上傳移轉方法。 這些移轉方法會使用用戶端存取通訊協定，例如透過 HTTP 通訊協定 (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 Server 終止支援已排定在 2023 年 4 月。 在 2025 年 10 月之前，Exchange Server 2016 和 2019 提供外延支援。 如需詳細資訊，請參閱 Exchange Server 支援性矩陣 。 從有多個信箱伺服器的內部部署 Exchange 組織進行移轉時，建議您建立平均散佈於多個信箱伺服器的移轉使用者清單。 根據個別伺服器效能而定，可進一步微調清單以達到最大的輸送量。 例如，如果伺服器 A 的資源可用性比伺服器 B 多出 50%，則在同一個移轉批次中伺服器 A 多出 50% 的使用者是合理的。 可將類似做法套用到其他來源系統。 請在伺服器有最大資源可用性時執行移轉，例如在數小時之後或在週末和假日時。 |
| 後端工作 | 其他後端工作會在移轉期間執行。 因為最好是在上班時間後執行移轉，所以移轉通常會與維護工作發生衝突， (例如數據備份) 在內部部署伺服器上執行。 | 檢閱可能會在移轉期間執行的其他系統工作。 建議您在未執行其他耗用大量資源的工作時執行資料移轉。 注意：針對使用內部部署 Exchange 的客戶，常見的後端工作是備份解決方案和 Exchange 存放區維護 (2013 年 2016 年 2019 年) 。 |
| 節流原則 | 使用節流原則來保護電子郵件系統是常見的做法，該原則會針對在一定時間內從系統擷取數據的速度和可擷取數據量設定特定限制。 | 確認為您的電子郵件系統部署的節流原則。 例如，Google Mail 會限制在特定期間內可擷取的數據量。 視版本而定，Exchange 具有會限制網際網路訊息存取通訊協定 (IMAP) 內部部署郵件服器 (網際網路訊息存取通訊協定 (IMAP) 移轉時使用) 和經由 HTTP 通訊協定存取的 RPC (Exchange 完全移轉和 Exchange 分段移轉時使用) 存取的原則。 若要檢查節流設定，請執行 Get-ThrottlingPolicy Cmdlet。 如需節流的詳細資訊，請參閱： (2007、 2010、 2013、 2016、 2019) 。 如需IMAP節流的詳細資訊，請參閱 將IMAP信箱移轉至 Microsoft 365 或 Office 365。 |
因素 2：非混合式部署移轉的移轉伺服器
網際網路訊息存取通訊協定 (IMAP)、完全移轉和分段移轉是由雲端發起的資料提取移轉方法，因此不需要專用移轉伺服器。 不過，因特網對向通訊協議會裝載 (IMAP 或 RPC over HTTP 通訊協定) ，可作為將信箱和信箱數據移轉至 Microsoft 365 或 Office 365 的移轉伺服器。 因此，您目前電子郵件組織的數據源伺服器上一節所述的移轉效能因素和最佳做法也適用於因特網邊緣伺服器。 針對 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 移轉：使用範例數據預先填入來源信箱。 然後從內部部署網路) 外部的因特網 (，使用 Microsoft Outlook 等標準 IMAP 電子郵件用戶端連線到來源信箱，然後判斷從來源信箱下載所有數據所需的時間來測量網路效能。 輸送量應該類似於客戶在 Microsoft 365 或 Office 365 中使用 IMAP 移轉工具可取得的輸送量，因為沒有其他條件約束。
完全移轉和分段 Exchange 移轉：使用範例數據預先填入來源信箱。 然後，從內部部署網路) 外部的因特網 (，透過 HTTP 通訊協定使用 RPC 連線到來源信箱與 Outlook。 請確定您使用 快取模式進行連線。 檢查從來源信箱同步處理所有資料需要多久時間，以測量網路效能。 輸送量應該類似於客戶可以使用 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 客戶通常會更擔心何時要排程移轉，以及需要多久時間。
當您規劃要在一段特定時間內移轉的信箱數量時，請考量下列事項：
包含移動要求在佇列中等候的時間。 使用下列公式進行計算：
(要移轉的信箱總數) = ( (總時間) - (平均佇列時間) ) * (移轉輸送量)
其中移轉輸送量等於每個小時可移轉的信箱總數量。
例如，假設您有六小時的空檔可以移轉信箱。 如果平均佇列時間是一小時，而且您每小時有 100 個信箱的移轉輸送量，則可以在六小時的時間範圍中移轉 500 個信箱：500 = (6 - 1) * 100。
- 比一開始的規劃更早開始進行移轉，以降低佇列中的時間。 當信箱進入佇列時，Exchange 2003 使用者仍可存取其信箱。
判斷佇列時間：佇列時間一律會變更，因為 Microsoft 不會管理客戶的移轉排程。
若要判定可能的佇列時間，客戶可以嘗試將測試移轉排定在實際移轉開始的數小時之前。 然後，根據觀察到要求處於佇列中的時間，客戶可以更完善地估算要在何時開始進行移轉，以及在一段特定時間內可移轉的信箱數量。
例如，如果測試移轉已在規劃的移轉開始前四小時完成。 客戶會判定測試移轉的佇列時間為大約一小時。 然後，客戶應考慮比原本規劃的早一小時開始進行移轉，以確保有足夠的時間可以完成所有移轉。
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 Server 終止支援已排定在 2023 年 4 月。 在 2025 年 10 月之前，Exchange Server 2016 和 2019 提供外延支援。 如需詳細資訊，請參閱 Exchange Server 支援性矩陣 。 從有多個信箱伺服器的內部部署 Exchange 組織進行移轉時，建議您建立平均散佈於多個信箱伺服器的移轉使用者清單。 根據個別伺服器效能而定，可進一步微調清單以達到最大的輸送量。 例如，如果伺服器 A 的資源可用性比伺服器 B 多出 50%，則在同一個移轉批次中伺服器 A 多出 50% 的使用者是合理的。 可將類似做法套用到其他來源系統。 請在伺服器有最大資源可用性時執行移轉，例如在數小時之後或在週末和假日時。 |
| 後端工作 | 其他後端工作通常會在移轉期間執行。 因為最佳做法是在營業時間之後執行移轉，所以移轉很常與其他在內部部署伺服器上執行的維護工作產生衝突，例如資料備份。 | 請檢閱移轉期間可能執行的其他系統工作。 建議您在未執行其他耗用大量資源的工作時執行資料移轉。 注意：針對使用內部部署 Exchange 的客戶，常見的後端工作是備份解決方案和 Exchange 存放區維護 (2013 年 2016 年 2019 年) 。 |
| 節流原則 | 使用節流原則保護電子郵件系統是很常見的做法，它會設定一段特定時間內可從系統擷取資料量之速度的特定限制，並且使用特定移轉方法。 | 確認為您的電子郵件系統部署的節流原則。 例如，Google Mail 會限制在特定期間內可擷取的數據量。 視版本而定，Exchange 具有會限制網際網路訊息存取通訊協定 (IMAP) 內部部署郵件服器 (網際網路訊息存取通訊協定 (IMAP) 移轉時使用) 和經由 HTTP 通訊協定存取的 RPC (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。 這些工具通常會需要移轉伺服器。 來源伺服器的系統效能、後端工作和節流原則等因素適用於這些移轉伺服器。
注意事項
某些第三方移轉解決方案會裝載在因特網上作為雲端式服務，而且不需要內部部署移轉伺服器。
解決方案和做法：
若要改善使用移轉伺服器時的移轉效能，請套用與 因素 1：第三方工具移 轉的數據源一節中所述的最佳做法。
因素 3：第三方工具移轉的移轉引擎
針對協力廠商移轉工具，最常見的通訊協定為 Exchange Web 服務和經由 HTTP 通訊協定的 RPC。
Exchange Web 服務：
Exchange Web Services 是建議用於移轉至 Microsoft 365 或 Office 365 的通訊協議，因為它支援大型數據批次，而且具有更好的服務導向節流。 在 Microsoft 365 或 Office 365 中，在模擬模式中使用時，使用 Exchange Web 服務的移轉不會取用用戶預算的 Microsoft 365 或 Office 365 Exchange Web 服務資源量，而是取用預算資源的複本：
同一個系統管理員帳戶執行的所有 Exchange Web 服務模擬呼叫都會與適用於此系統管理員帳戶的預算分開計算。
針對每個模擬工作階段，會建立實際使用者預算的陰影複製。 此特定工作階段的所有移轉都會耗用此陰影複製。
模擬下的節流會隔離到每個使用者移轉工作階段。
您可以在租使用者 (中暫時變更 Exchange Web 服務節流原則，持續時間為 30、60 或 90 天，) 允許移轉完成。 您可以從 Microsoft 365 系統管理中心的 [說明] 區段提出要求。
最佳做法：
使用 EWA 模擬的協力廠商移轉工具之客戶的移轉效能，會與其他租用戶之基於 Exchange Web 服務的移轉和服務資源使用量相互競爭。 因此，移轉效能會有所差異。
客戶應盡可能使用 Exchange Web 服務模擬的協力廠商移轉工具，因為它通常比較快，而且比使用經由 HTTP 通訊協定的 RPC 等用戶端通訊協定更有效率。
RPC over HTTP 通訊協定：
傳統的移轉解決方案會使用 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：第三方工具移轉的網路
最佳做法：
針對使用經由 HTTP 通訊協定的 RPC 之協力廠商移轉解決方案，有個好方法可以測量可能的移轉效能：
從移轉伺服器，透過 HTTP 通訊協定使用 RPC 連線到 Microsoft 365 或 Office 365 信箱與 Outlook。 請確定您不是使用 快取模式進行連線。
將具有範例數據的大型 .pst 檔案匯入至 Microsoft 365 或 Office 365 信箱。
計算上傳 .pst 檔案需要多久時間以測量移轉效能。 假設沒有其他限制，移轉輸送量應與客戶從經由 HTTP 通訊協定的 RPC 協力廠商移轉工具取得的類似。 在實際移轉期間有額外負荷，因此輸送量可能會稍微不同。
因素 5：Microsoft 365 和 Office 365 服務
Microsoft 365 和 Office 365 資源健康情況型節流會影響使用第三方移轉工具的移轉。 如需詳細資訊，請參閱 Microsoft 365 和 Office 365 資源健康情況型節流 。