先說清楚，為什麼現在要換
假設一家公司準備更新郵件平台：財務希望降低維運負擔，業務期待跨據點存取更方便，IT 則想整理長期累積的帳號。三方都支持遷移，卻可能在談三個不同的專案。這是假設情境，不是客戶案例。若直接從信箱數量與搬移日期開始討論，完成後仍可能有人認為原本的問題沒有解決。
先把目的寫成可觀察的工作結果，例如新同仁能依流程取得正確信箱、交接人能找到指定往來、異常時知道誰處理。再區分本次必須達成、可以稍後改善與不在範圍內的事項。平台名稱不是驗收標準，資料搬完也不代表管理責任已經整理好。
把郵件依賴的工作一起盤點
一個信箱可能同時被個人、共用窗口與其他系統使用。應請各部門指出對外公開地址、代理收發、會議安排及系統通知等情境，記錄用途、負責人和失敗時的影響。不要只盤點仍有員工登入的帳號；少有人登入的地址，也可能承接重要客戶訊息。
清單還要分開記錄郵件、聯絡人、行事曆、權限與收發設定。Microsoft 的官方說明指出，IMAP 遷移處理郵件，不包含聯絡人、行事曆與工作項目。因此不能用「信箱已搬」概括全部工作資料；採用何種方法，仍要依來源、目的平台與實際範圍確認。
用代表性工作選試點，不只選最簡單信箱
試點可以納入一般同仁、共用窗口管理者與跨據點使用者，讓不同工作方式都有機會被檢查。先約定要執行的動作，例如尋找指定歷史往來、回覆外部郵件、使用代理權限，以及確認相關通知能到達。測試資料和授權範圍應由負責人確認。
若只挑資料最少、沒有特殊流程的帳號，可能得到很漂亮的搬移結果，卻看不到正式切換的主要障礙。試點發現的差異應形成待辦，標示哪些必須先解決、哪些需要教學，以及哪些確實不在本次服務範圍。不要把所有差異都當成使用者不熟悉。
切換前先決定誰有權暫停
切換安排要包含業務尖峰、不同據點時段、使用者通知與問題回報窗口。由誰確認可以開始，遇到哪類異常需要暫停，以及延後會影響哪些工作，都應事前說明。若涉及寄信來源或網域設定，也要安排有權限的人員配合。
回復不是一句「切回去就好」。切換後可能已有新的郵件與操作，應先釐清如何處理這段期間的差異，以及回復是否符合原環境條件。能否回復、需要哪些準備，須依選用方法驗證；不宜在未演練前承諾零中斷或立即復原。
驗收要同時看資料與工作
資料核對可以記錄範圍、失敗項目與處置方式，但還要讓業務代表完成日常任務。使用者是否知道新的登入與支援方式、重要窗口是否能接續對外回覆，往往比單一完成百分比更接近轉換目的。未解決的問題應有負責人與下一次確認時間。
舊環境何時停止使用也需要明確條件。先確認資料核對、業務驗收與必要保存安排，再評估停用；不要因合約到期壓力就默認所有資料都已不再需要。對沒有納入搬移的資料，應保留清楚說明及後續處理責任。
先開一場有輸出的需求會議
可請 IT、業務與管理窗口各帶一個最重要的工作情境，整理成一頁：轉換目的、資料範圍、相依服務、試點對象、停止條件及驗收人。若仍無法回答其中幾項，先完成釐清，再決定時程與工具，通常更容易把討論落到可執行的範圍。
需要評估信箱遷移時，可再與 ACMI 討論服務範圍與 MigrateSuite 的適用情境。先提供來源與目的環境、關鍵工作及可接受的切換安排，比只詢問每個信箱的價格，更能形成有依據的規劃。
