當發票、警報和掃描文件停止到達時，雲端郵箱遷移可以成功完成。這些工作流程可以透過郵箱租戶外部的裝置、應用程式或第三方提供者發送。圍繞業務郵件路徑建立遷移清單，而不僅僅是要移動的使用者帳戶清單。
映射租戶清單錯過的系統
詢問每個業務和基礎設施團隊哪些系統發送訊息。包括客戶通訊、計費、身分工作流程、事件警報、印表機、網站表單、計畫報告和 SaaS 活動。記錄上次端到端測試的目的、所有者、重要性、發送方法、網路依賴性和證據。
對於每條路徑，區分可見的From， 信封寄件人, DKIM 簽章域、目標範圍和退回處理。記錄服務是否直接與外部提供者、本地中繼或租戶端點對話。 Microsoft 明確記錄了幾種具有不同先決條件和限制的應用程式郵件方法。直接傳送僅限於組織內的收件者； SMTP中繼和經過驗證的提交有不同的設定要求。 微軟指導。驗證實際提供者目前支援的方法，而不是複製另一個平台的設定。
將傳輸連接到身份驗證
更改郵箱平台不會自動更新應用程式的寄件者配置或DNS 。確定誰對每個串流進行簽名，其中包含身份 SPF 評估對齊的標識符與可見的 From 域的關係。 RFC 9989。在刪除舊記錄之前清點DKIM選擇器和第三方相依性。
還可以識別基於 IP 的中繼限制、憑證、防火牆規則、連接器依賴性和憑證引用，而無需匯出機密。記錄哪個團隊擁有每個依賴項。 MX變更主要會變更入站路由；它不是出站應用程式郵件的完整遷移計劃。
讓接收者範圍成為遷移門
假設客戶收據使用 SaaS 簽章路由，印表機使用內部中繼，並且事件應用程式透過舊平台提交。接收路由可能仍處於郵箱切換之外，但仍取決於其DNS和提供者帳戶。印表機和事件應用程式需要它們自己的目的地、網路和提交檢查；遷移員工帳戶並不能解決這些依賴性。
如果事件應用程式必須通知外部待命位址，則 Microsoft Direct Send 不是該所需外部傳遞的適當途徑。請使用實際帳戶和網路先決條件驗證支援的方法。此假設範圍決策不會配置租戶或測試提供者的資格。保留保留，直到所選路線獲得授權的端到端證據。
刻意規劃共存
對於每個服務，指定舊路徑、新路徑、切換所有者、測試案例、故障訊號和回滾操作。僅保留核准的共存期間所需的平行授權。重複發送是一個單獨的風險：遷移應用程式作業並使其舊的排程器保持活動狀態可能會發送相同的通知兩次，即使這兩個訊息都經過身份驗證。
根據業務需要行使內部和外部目的地。測試退回郵件處理、重試行為和監控警報以及收到一條成功訊息。保留受領者簽名的證據並 結盟 結果。僅SMTP接受回應並不能證明目標郵箱顯示了郵件或應用程式正確處理了故障。
為舊平台設定退出條件
不要停用舊中繼，因為所有使用者信箱都已移動。透過觀察到的成功、批准的例外或明確的退休決定來關閉每個依賴行。包括在切換視窗期間未運行的計劃流。在舊平台的存取權限到期之前導出未來故障排除所需的證據。
撤銷權限時，在正常審核下使用精確的記錄變更和服務配置變更。僅在相應服務遷移或停用後才刪除舊憑證和授權。說明遷移決定中仍存在的未知因素，因此不完整的證據不會被誤認為是完整的。