「18 個月後機房租約到期，所以把 500 台 VM 搬上雲。」
這是一個截止日期，不是遷移計畫。
真正的計畫要回答：哪些系統互相依賴、先搬誰、資料怎麼同步、切換失敗怎麼回去，以及搬完後誰負責營運。
圖解：先盤點相依關係並建立安全的 Landing Zone，再按波次遷移；每一波都要有驗證門檻與回退路徑，混合連線則保留到切換結果真正被證明。
Google Cloud 的四階段遷移路徑
官方遷移指南把旅程分成四個階段：
- Assess：盤點環境、依賴、效能、風險與 TCO。
- Plan：建立雲端基礎、排列優先順序、設計批次和責任。
- Deploy：實際遷移、測試、同步、切換與退役。
- Optimize：根據雲端用量改善可靠性、效能、成本與操作方式。
四個階段會重疊。第一個遷移波次的結果，通常會回頭修正評估資料與後續計畫。
Assess：先弄清楚現在有什麼
至少要盤點：
- 伺服器、資料庫、儲存與網路設備
- 應用程式擁有者和業務關鍵性
- 連線、批次、檔案交換與身分依賴
- CPU、記憶體、磁碟、流量和尖峰基準
- 作業系統、資料庫和商業軟體授權
- 備份、RTO/RPO 與維護窗口
- 合規、資料位置和稽核要求
- 現有成本與合約結束日期
資產清單不等於相依關係圖。一台 CPU 很低的舊 VM，可能是所有訂單都要經過的授權伺服器；若只依資源利用率排優先順序，很容易搬錯。
Migration Center 的角色
Migration Center 能匯入或探索基礎設施資料，協助：
- 建立資產清單
- 收集效能資料
- 產生合適規格與費用估算
- 比較偏好的遷移目標
- 支援 TCO 與商業案例分析
實際能取得哪些依賴與屬性，取決於資料來源、Discovery Client、匯入方式和權限。不能假設接上工具後，所有應用依賴和業務關係都會自動正確。
工具輸出也要由應用擁有者確認。掃描不到的排程、人工檔案交換和外部合作夥伴，常比伺服器本身更容易在切換時出問題。
Plan：替每個工作負載決定處置方式
常見的 6R 可以當成討論詞彙：
| 處置 | 代表意思 | 何時可能合理 | 主要風險 |
|---|---|---|---|
| Rehost | 先搬到相似 VM 環境 | 截止日期緊、應用穩定 | 技術債和高成本一起搬過去 |
| Replatform | 小幅改用代管平台 | 能換資料庫或執行平台，但不大改功能 | 相容性與效能要重測 |
| Refactor / Rearchitect | 改變應用與資料架構 | 現況無法達到長期目標 | 時程、範圍和雙跑複雜 |
| Repurchase | 用 SaaS 或其他產品取代 | 非差異化能力、現有產品維護成本高 | 流程改變、資料移轉與退出條款 |
| Retire | 關閉 | 無擁有者、重複或不再產生價值 | 隱藏依賴尚未被發現 |
| Retain | 暫時保留 | 法規、硬體、合約或風險尚未解決 | 混合環境成本和過渡期拉長 |
這不是一題一個 R 的分類遊戲。同一套系統可能先 Rehost 達成機房退出，再把高價值模組逐步 Replatform 或 Refactor。
建立 Landing Zone
搬第一個正式工作負載前，要先準備：
- Organization、Folder、Project 和 Billing 結構
- Cloud Identity、IAM、群組與緊急存取
- Organization Policy 和安全基準
- Shared VPC、DNS、IP 規劃與混合連線
- Logging、Monitoring、Audit 與安全事件匯集
- KMS、Secret、資料分類與備份政策
- IaC、CI/CD 和變更流程
- 成本標籤、預算與責任歸屬
如果每個遷移團隊都自行建立一套網路和 IAM，速度可能在第一週看起來很快，後面卻會花更多時間整併。
用 Wave 管理相依關係
一個 Wave 應包含可以一起測試與切換的工作負載，而不是隨機湊出固定數量的 VM。
可以這樣分：
- Pilot：低風險但具代表性，用來驗證基礎與流程。
- 早期 Wave：相依關係清楚、擁有者投入、回退容易。
- 主要 Wave：使用前面量到的速度與問題調整節奏。
- 高風險 Wave：核心系統、複雜資料或短停機窗口。
- Retire / Retain：持續追蹤未搬項目，不讓它們消失在報表外。
每個 Wave 都要有進入條件、測試計畫、切換 Runbook、回退門檻和完成定義。
遷移工具要按對象選
VM
Migrate to Virtual Machines 可把支援來源的 VM 複寫到 Compute Engine，先測試 Clone，再安排 Cutover。是否能達到停機目標，仍取決於資料變更量、網路、應用和切換步驟。
VMware
Google Cloud VMware Engine 保留 VMware SDDC 操作模型，適合需要快速退出資料中心、又暫時不想改變大量 VM 的情況。
應用程式不用立刻重寫，但授權、容量、網路、備份和長期費用都要重新確認。不要把「VMware 相容」寫成「不需要處理授權」。
資料庫
Database Migration Service 支援多種同質與異質遷移到 Cloud SQL 或 AlloyDB。Continuous Migration 會先做初始載入，再持續同步變更，能把最終切換的停機壓低。
「Minimal downtime」不等於零停機。正式切換仍要：
- 停止或控制來源寫入
- 等待 Replication Lag 歸零
- 驗證資料和序列
- 切換連線
- 觀察錯誤
- 決定回退時資料如何處理
支援的來源、目的地、版本、物件和轉換能力會更新，必須查目前的遷移情境清單。
物件與檔案
- Storage Transfer Service：線上來源、其他雲端和支援的地端檔案系統。
- Transfer Appliance：網路窗口不足、適合離線搬運的大型資料集。
- BigQuery Data Transfer Service：把特定 SaaS 或支援來源資料排程匯入 BigQuery，不是一般檔案遷移的萬用工具。
選線上或離線傳輸前，先估：
理想傳輸時間 = 資料量 ÷ 可用吞吐量再加上協定開銷、業務流量、重傳、校驗和增量同步。只看線路標稱頻寬通常太樂觀。
混合環境不是失敗，有時是長期設計
保留地端或其他雲端可能有合理理由：
- 工廠控制需要本地低延遲
- 硬體或授權無法移動
- 資料或系統有明確位置要求
- 併購後暫時需要整合多個環境
- 正在進行分波遷移
- 某個 SaaS 或雲端服務具有必要能力
但每多一個環境，就多一份網路、身分、觀測、事件處理和技能成本。架構文件應寫出保留原因與重新檢視日期，避免「暫時」變成沒有擁有者的永久狀態。
選 HA VPN 還是 Cloud Interconnect？
HA VPN
- 使用 IPsec 加密
- 經過公用網際網路
- 建置通常較快
- 每個 Tunnel 有封包速率上限；實際 Gbps 取決於封包大小
- 適合較低或中等流量、快速建立與備援
要取得 HA VPN SLA，必須使用符合要求的冗餘拓撲，不是建立一條 Tunnel 就自動得到。
Cloud Interconnect
- 流量不走公用網際網路
- 提供 Dedicated、Partner 等連線方式
- 容量、交付時間與責任邊界依類型而異
- 適合穩定高流量、延遲較可預期的連線需求
- 預設不提供端到端 IPsec 加密
若要求 IP 層加密，可以部署 HA VPN over Cloud Interconnect；支援的 MACsec 也有特定範圍。連線設計要分開確認容量、加密和 SLA，不能用單一產品名稱一次代表三件事。
正式環境常會組合多條連線、不同 Edge Availability Domain 和備援設備。Interconnect 當主要路徑、HA VPN 當備援是否足夠，要看兩者是否真的沒有共用故障點。
GKE Enterprise 適合什麼情況？
GKE Enterprise 提供 Fleet、Policy、Config Management、Service Mesh 等能力，協助一致管理多個 Kubernetes 叢集與環境。
它比較適合：
- 組織已有多個 GKE 或 Kubernetes 叢集
- 需要跨叢集身分、政策與設定標準
- 有平台團隊負責治理
- 一致性管理帶來的價值高於額外成本與複雜度
只有一兩個簡單應用，不代表一定要導入整套多叢集平台。也不要反過來假設「只在 Google Cloud 就永遠不需要 Fleet」；要看治理規模和功能需求。
Strangler Fig：逐步替換，不是無限期雙軌
漸進式現代化可以這樣做：
- 選出邊界清楚、風險可控的功能。
- 在舊系統前建立可觀察的路由或介面。
- 實作新服務並做資料一致性設計。
- 先導入一小部分流量。
- 比較功能、延遲、錯誤和成本。
- 完全切換後，真正移除舊功能。
最大的陷阱是新舊兩套長期並存。每個被替換功能都要有退役條件、擁有者和日期。
一份可執行的 Cutover Runbook
至少包含：
- 變更前備份與還原驗證
- DNS、TTL、憑證和連線準備
- 凍結或雙寫策略
- 最終同步與資料校驗
- Smoke Test 與業務驗收
- 指標、Log 和觀察窗口
- Go / No-Go 決策者
- 明確回退條件
- 回退後新增資料的處理
- 對使用者、客服和利害關係人的通知
「切回舊系統」若沒有處理切換後的新資料，就不是真正的回退方案。
情境練習：18 個月退出資料中心
先不要替 500 台 VM 全選 Rehost。
可以分成：
- 無擁有者且沒有流量證據：先確認能否 Retire。
- 標準商業軟體：比較 Compute Engine、VMware Engine 或 SaaS。
- 自建 PostgreSQL：評估 Cloud SQL、AlloyDB 與 DMS 支援情況。
- 高耦合核心系統：先畫依賴與 Cutover，再決定 Rehost 或 Replatform。
- 大量歷史檔案：用真實可用吞吐量比較線上傳輸與 Transfer Appliance。
- 地端控制系統：若必須保留，明確設計長期混合連線與營運責任。
Pilot 的目的不是挑最簡單的一台 VM證明「搬得動」，而是驗證身分、網路、觀測、備份、切換和支援流程能否一起運作。
課後檢查
你應該能回答：
- Assess 階段為什麼不能只有資產清單？
- 6R 是工作負載處置語言，為什麼不是一次性的終局？
- Minimal downtime 和 zero downtime 差在哪裡？
- Interconnect 的容量、加密與 SLA 為什麼要分開設計？
- 一份可回退的 Cutover Runbook 必須處理哪些資料問題？
下一課會深入 VPC、Shared VPC、負載平衡和私有服務存取，補齊遷移計畫裡最容易成為關鍵路徑的網路基礎。
