公司由 Microsoft 365 轉去 Google Workspace、合併兩個租戶，或者整理收購後的 IT 環境，最容易被低估的往往唔係檔案有冇搬到，而係檔案入面原本指向其他文件的連結，會唔會仍然留喺舊環境。對香港企業嚟講，呢啲細節可能影響同事日常搵合約、報價表、共享資料夾同項目文件，亦會令遷移後的支援工作拖長。
CloudM Migrate 的 5.2 版本資料把 Link Remediation（連結修復）列為新功能之一。以下由 IT 團隊角度，拆解呢類功能可以處理甚麼、部署時要預備甚麼，以及正式關閉舊租戶前應該點驗收。
檔案搬咗，連結未必跟住搬
想像一份 Excel 報價表入面有連結，指向舊租戶的共享資料夾；或者一份內部流程文件連到另一份 Google 文件。檔案本身即使已經成功搬到新平台，內部連結仍有機會指返舊位置。等到舊租戶停用，使用者先發現連結失效，IT 就要逐份文件追查。
問題唔只係普通超連結。文件亦可能包含純文字 URL、試算表公式、註解、簡報備註，甚至由 SharePoint 或 OneDrive 分享功能產生的連結。因此，遷移驗收唔應該只睇「成功搬移幾多個檔案」，仲要驗證使用者打開文件後，能否繼續到達正確的目的地。
CloudM Migrate 的 Link Remediation 可以處理甚麼？
CloudM 官方 5.2 更新資料指出，Link Remediation 會根據遷移時建立的文件對應資料，找出已搬移文件內的連結，再改寫為目的地副本的位置。官方列出的遷移方向包括 Google to Google，以及 Microsoft 365 to Google；實際項目仍應先核對來源、目的地及文件格式是否在支援範圍內。
官方資料列出的處理範圍包括 Google Docs、Sheets、Slides，以及保留原始格式的 Word、Excel、PowerPoint 檔案。連結類型可包括超連結、純文字網址、部分試算表公式、註解和簡報內的備註或版面元素；SharePoint／OneDrive 分享連結亦有列明相關處理方式。重點係唔好單憑功能名稱就假設所有系統、所有連結類型都會自動修好，最好用自己環境的樣本做測試。
另一個值得留意的地方：連結修復係獨立的項目類型。一般做法係先完成文件遷移，再以同一批次執行一次只包含 Link Remediation 的第二輪處理，唔可以同其他項目類型放喺同一列一齊跑。完成後，報告會列出掃描、對應、替換及已替換的連結數量，亦會提供文件對應 CSV，方便團隊抽查。
香港 IT 團隊部署前，建議做足 5 件事
- 先盤點高風險文件。揀出合約、財務表、客戶交付文件、部門共用表格同管理層簡報，列出它們依賴的共享資料夾及跨文件連結。
- 做一次來源環境掃描。確認遷移範圍、資料量、權限和主要依賴，避免到 cutover 前先發現有大量舊連結需要處理。
- 用代表性樣本試跑。唔好只用幾份簡單 Word 檔測試；應包括大型試算表、公式、註解、簡報，以及不同分享權限的文件。
- 預留第二輪修復時間。把 Link Remediation 當成遷移計劃的一個正式步驟，並安排負責人檢查報告和 CSV，而唔係假設第一輪搬檔已經完成所有工作。
- 舊租戶先唔好急住關。由業務代表抽查關鍵工作流程，確認連結、權限和使用者操作都正常，再按內部變更程序決定何時停用來源環境。
升級與權限設定都要列入計劃
CloudM 的更新說明提醒，使用 Link Remediation 前，需要為服務帳戶加入指定 scopes，並在 Google Cloud 專案啟用相關 API。升級方面，官方列明需要先處於 4.7.6 或更新版本，並建議升級前使用安裝程式的資料庫備份選項。呢啲係正式排期前要確認的技術前置條件，唔應留到遷移當日先處理。
另外，請把實際支援路徑、權限需求、資料處理方式及錯誤回復程序，寫入變更計劃。若企業有多個來源平台、特殊文件格式或跨部門權限，應先向供應商確認，而唔好將某一條成功的測試路徑直接套用到所有工作負載。
點樣判斷遷移真正完成？
可以用三個問題做最後驗收：第一，重要文件的連結係咪指向新環境，而唔係舊租戶？第二，相關使用者仍然有正確的存取權限，唔會因為連結修復而意外擴大或縮窄權限？第三，IT 團隊有冇保留報告、抽查紀錄和例外清單，方便日後追查？
對香港企業而言，雲端遷移唔應該只係一次性的資料搬運，而係要令同事喺新環境繼續完成工作。把連結修復、權限驗收和來源環境退役安排一齊規劃，通常比事後逐張工單救火更穩陣。