Google Cloud 服務停用後怎麼辦？先看遷移期限

在 Google Cloud Console 看到這種公告時，最先該查的是停用日期和受影響的資源：

⚠️ This product has been deprecated and will be shut down on [某個日期].

「Deprecated」代表服務進入退場流程，和「今天就停止運作」不是同一件事。留給團隊的時間，取決於公告中的限制與最終日期。

前一篇談的是產品改名；停用則要處理更實際的問題：現有系統依賴它到什麼程度、替代方案在哪、資料怎麼搬。

下面分別看已停用與預計停用的服務，最後整理公告後該怎麼安排遷移。

已停用的服務

先看沒有一對一替代品的案例

Cloud IoT Core（2017-2023）

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

Cloud IoT Core 關閉時，使用它接收裝置資料的團隊得重新規劃接入、身分驗證和後續處理流程。Google 沒有推出功能完全對應的自家替代品，因此遷移不只是換一個服務名稱，還涉及既有裝置與資料管線的調整。

這個案例也提醒我們：把關鍵工作負載交給託管服務前，要先想好服務變更或退場時，資料和裝置能怎麼搬。

技術整合型停服

這類停服有個共同點：服務被併進更大的平台，而且有明確的遷移路徑。

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

其他已停服

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

2025–2026 年的服務退場

這段期間有幾項服務結束支援或關閉。若系統仍在使用它們，應逐項確認截止日期與遷移路徑。

2025 年（公告中的限制已生效）

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

MQL 沒有在 2025 年關閉；現有查詢、圖表與告警仍可運作，也能透過 API 建立。限制是 Google Cloud Console 不再支援新建這些 MQL 資產，且相關支援已結束。若系統還依賴它，先清點查詢，再決定何時改用 PromQL。（參考：MQL 淘汰說明）

2026 年

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

BigQuery Legacy SQL 也不是在 2026 年 6 月一律停用；可用功能與 2025 年 11 月至 2026 年 6 月的使用紀錄有關，既有查詢不一定會停止。請依官方功能可用性說明盤點實際查詢。Cloud Composer 1 的日期則已過；若相關環境仍列在資產清單，應依官方版本說明確認遷移與清理狀態。

Deployment Manager 是另一種情況：2026 年 4 月停止支援，並非當天停機；官方預計 2027 年 6 月底關閉服務。既有資源仍需管理的團隊，要按停用說明安排替代工具與切換時間。

2027-2029

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

停用政策能替團隊爭取什麼？

Google 在 2021 年為標示為 Google Enterprise API 的 API 公布穩定性承諾：若不得不做不相容變更，原則上至少提前一年通知，並提供遷移文件或工具。但這項承諾有適用範圍，不能直接推論每個 Google 產品、預覽功能或消費者服務都有相同期限。實際專案仍要核對服務公告與合約條款。（參考：Enterprise API 政策說明、Google Cloud 停用政策適用範圍）

以 Memorystore for Memcached 為例，公告列出三個不同時間點：2026 年 1 月不再列為建議服務、2027 年 2 月起限制新專案建立執行個體、2029 年 1 月底停止服務。團隊不能只記最後一天；新專案能否建立、既有工作負載能否運作，以及何時失去支援，都要分開記。

收到公告後，先判斷要搬什麼

與其猜服務為什麼退場，不如先看公告提供哪一種遷移路徑：

1. 同一產品的新版本：例如舊版 Runtime 或 Composer。先檢查設定、套件和執行環境的相容性；產品名稱沒變，不代表工作負載不用修改。
2. 換到另一項託管服務：例如 Container Registry 轉到 Artifact Registry。除了搬資料，也要檢查權限、路徑、CI/CD 和下游部署設定。
3. 沒有一對一後繼：例如 Cloud IoT Core。這時要重新選服務或調整架構，裝置連線、驗證與資料格式可能都要改。

有些公告只是改名，有些則是功能或 API 真正停止；先把受影響的部分列出來，才能估算時間。

%%{init: {"flowchart": {"curve": "linear", "nodeSpacing": 24, "rankSpacing": 32}}}%%
flowchart TD
  END["收到服務停用或版本退場公告"] --> SCOPE["確認受影響的 API、資料、<br/>專案與截止日期"]
  SCOPE --> PATH{"公告提供哪種替代路徑？"}
  PATH -->|"同產品新版本"| VERSION["測試套件、設定與 Runtime 相容"]
  PATH -->|"另一項託管服務"| SERVICE["核對資料、權限與上下游整合"]
  PATH -->|"沒有一對一後繼"| REPLACE["比較第三方、自建或調整需求"]
  VERSION --> VERIFY["試行、切流、驗證與回復"]
  SERVICE --> VERIFY
  REPLACE --> VERIFY

平時怎麼降低停服風險？

1. 指定公告負責人：追蹤Google Cloud Release Notes與實際使用服務的停用頁面，讓公告有明確接收者。
2. 保留相依清單：記錄哪些專案、API、資料管線與部署流程依賴該服務；收到公告時才不用從零盤點。
3. 預留資料出口：定期確認匯出格式、備份還原與權限設定是否可用。只有在切換成本真的高時，才為服務建立抽象層，避免多做一層卻沒有降低風險。
4. 每次公告都記三個日期：停止新建、停止支援、完全停用可能是不同時間點；按各日期安排驗證與切流。

選型時怎麼留退路？

服務停用不能只靠選「看起來夠主流」的產品來避免。採用前先確認服務的支援階段與停用政策；上線後保留版本、資料匯出方式和替代方案的紀錄，定期檢查官方公告。若某項功能深度綁定單一服務，就把將來搬走需要的時間和成本寫進設計決策。

這份清單會隨產品更新而改變；實際遷移時，仍要以各服務最新的公告和文件為準。