企業在進行由 Microsoft 365 轉換至 Google Workspace、合併兩個雲端租戶（Tenants），或整理企業收購後的 IT 環境時，最容易被低估的環節往往並非「檔案是否成功搬移」，而是「檔案內指向其他文件的連結，會否仍然殘留於舊有環境」。對於香港企業而言，這些細微末節極可能直接影響員工日常查閱合約、報價單、共用資料夾與專案文件的效率，甚至大幅拖長遷移完成後的技術支援與除錯時間。

檔案已成功搬移，但連結未必能自動更新

試想像以下情境：一份 Excel 報價單內包含一個超連結，該連結原本指向舊租戶中的某個共用資料夾；或者，一份內部標準作業程序（SOP）文件連結至另一份 Google 檔案。即便這兩份檔案本身皆已成功搬移至新平台，但其內部連結仍有極大可能指向舊有的儲存位置。一旦舊租戶正式停用，使用者才會驚覺連結失效，屆時 IT 團隊便必須耗費大量心力，逐份文件進行人工追查與手動修正。

問題的複雜度不僅限於普通的超連結。文件內可能還包含純文字網址（Plain Text URLs）、試算表公式、協作註解、簡報備忘稿，甚至是透過 SharePoint 或 OneDrive 分享功能所自動生成的連結。因此，遷移專案的驗收標準絕不應僅停留在「成功搬移了多少檔案」，更須確保使用者開啟文件後，仍能透過內部連結順利存取正確的目的地資料。

CloudM Migrate 的連結修復功能可處理哪些範圍？

根據 CloudM 官方發布的 5.2 版本更新資料指出，Link Remediation 功能會依據遷移過程中所建立的「文件對應資料庫」，主動找出已搬移文件內的內部連結，並將其自動改寫為指向目的地副本的正確位置。官方列明的支援遷移方向涵蓋 Google to Google，以及 Microsoft 365 to Google；然而，在實際專案執行前，IT 團隊仍應優先核對來源端、目的地端及文件格式是否確實隸屬於官方的支援範圍內。

官方資料顯示，其處理範圍涵蓋了 Google Docs、Sheets、Slides，以及保留原始格式的 Word、Excel 與 PowerPoint 檔案。可修復的連結類型不僅包含標準超連結，亦支援純文字網址、部分試算表公式、註解內容，以及簡報內的備忘稿與特定版面元素；同時，針對 SharePoint 及 OneDrive 的分享連結，官方亦有列明具體的處理對策。關鍵在於：企業切勿單憑「連結修復」的功能名稱，便天真地假設所有系統平台與所有連結類型皆能被自動完美修正，強烈建議必須使用企業內部真實的檔案樣本進行概念驗證（PoC）。

另一個必須特別留意的重點：連結修復是一項獨立執行的項目類型。標準的操作實務為：先完整執行第一輪的文件搬移作業，隨後再以同一批次，執行一次「僅包含 Link Remediation」的第二輪處理程序；此修復程序不可與其他遷移項目類型合併於同一佇列中同時執行。處理完成後，系統報表將詳細列出已掃描、成功對應、需替換及已替換的連結數量，並提供文件對應的 CSV 檔案，以利 IT 團隊進行後續的抽查與核對。

將系統升級與權限設定納入事前規劃

CloudM 的更新說明特別提醒，在啟用 Link Remediation 功能前，管理員必須為系統服務帳戶（Service Accounts）加入指定的授權範圍（Scopes），並於 Google Cloud 專案中提前啟用相關的 API。在版本升級方面，官方明訂系統必須先處於 4.7.6 或更新版本，並強烈建議在執行升級前，務必使用安裝程式內建的資料庫備份功能。這些技術前置作業必須在正式排定遷移日程前全數確認完畢，絕不應拖延至遷移當日才倉促處理。

此外，請務必將實際支援的遷移路徑、API 權限需求、資料處理機制及錯誤復原程序，詳盡寫入正式的變更計畫（Change Plan）中。若企業環境涉及多個來源平台、特殊的專屬文件格式或複雜的跨部門權限架構，應優先向軟體供應商進行技術確認，切勿將某一條順利通過測試的簡單路徑，直接套用至所有複雜的工作負載上。

如何精確判定遷移已真正完成？

IT 團隊可透過以下三個核心問題作為最終的驗收基準：

• 第一，關鍵文件的內部連結是否已全數指向新環境，而非殘留於舊租戶？
• 第二，相關使用者是否仍維持正確的存取權限，不會因執行連結修復而導致權限意外擴張或非預期縮減？
• 第三，IT 團隊是否已妥善歸檔修復報告、抽查紀錄與例外清單，以備日後稽核或追查之需？

對於香港企業而言，雲端遷移絕不應僅被視為一次性的資料搬運工程，其最終目標是確保員工能在新環境中無縫接軌，順暢地完成日常工作。將連結修復、權限嚴格驗收及來源環境退役計畫整合至整體規劃中，通常會比事後依賴 IT 人員逐張處理求救工單來得更加穩健且具備成本效益。