自建主機搬上雲端怎麼做？盤點、試跑、切換與回退的完整步驟與費用評估
說明把公司自建主機或舊託管主機搬到雲端的流程，從資源盤點、成本比較、試跑與資料同步，到切換日與回退計畫，並提醒搬遷常被低估的人力與流量成本。
把自建主機搬上雲端，最重要的不是技術工具，而是「先盤點、再試跑、最後才切換」的順序，並且在切換前準備好可以回退的計畫。成本方面，不能只比較硬體與雲端月費，還要算進搬遷人力、雙軌並行期間的重複費用、資料傳輸，以及搬遷後的維運變化。本文提供一套實務步驟。
一、搬遷前先盤點
盤點要回答「現在有什麼、誰在用、彼此怎麼連」：
| 盤點項目 | 要記錄的內容 |
|---|---|
| 主機與虛擬機 | 用途、作業系統、CPU、記憶體、磁碟、實際使用率 |
| 應用程式 | 版本、相依套件、設定檔、排程工作 |
| 資料庫 | 種類、大小、成長速度、備份方式 |
| 網路 | 對外網址、防火牆規則、VPN、固定 IP、DNS |
| 授權 | 商用軟體授權是否可用於雲端 |
| 相依關係 | 哪些系統互相呼叫，哪些依賴內部網路 |
| 使用者 | 使用時段、人數、可以接受的停機時間 |
盤點時最容易漏掉的是排程工作、寫死的 IP 位址、內部才能存取的服務，以及由某個人記在腦中的手動作業。建議製作一張相依關係圖，標明搬遷順序。
二、選擇搬遷策略
- 直接搬遷：把虛擬機原樣搬到雲端，速度快，但無法享受雲端的彈性，也可能浪費資源。
- 調整後搬遷：搬遷時順便調整，例如使用託管資料庫、更新作業系統，成本與時間較高，長期效益較好。
- 重新設計：拆成容器或無伺服器架構，投入最大，適合長期演進的系統。
- 暫不搬遷：有些系統因授權、延遲或合規原因，保留在現有環境，採用混合模式。
小型團隊通常先直接搬遷或做少量調整，穩定後再逐步改造，避免一次改太多。
三、成本比較要算什麼
現況（自建）：硬體折舊、機櫃與電力、網路頻寬、維運人力、備援設備、軟體授權、故障與停機損失。 雲端：運算、儲存、流量、授權、備份、監控、營業稅與外幣手續費，以及搬遷後仍需要的人力。
示意計算（數字純屬舉例）：自建硬體 20 萬元，攤提 5 年，每年約 4 萬元；機櫃與頻寬每月 6,000 元，每年 7.2 萬元；合計每年約 11.2 萬元，尚未包含人力。雲端方案若每月 8,000 元，每年 9.6 萬元，看起來略低，但還要加上流量、備份與稅費，也要考慮人力是否減少。結論要依完整項目重新計算，不能只看表面單價。可以用雲端主機每月費用試算與預留承諾方案回收期試算輔助。
四、試跑與資料同步
- 在雲端建立與正式環境相近的測試環境。
- 用資料備份還原測試，檢查資料完整性與應用程式功能。
- 執行壓力測試，確認效能不低於現況。
- 設定持續同步，例如資料庫複寫，讓雲端資料庫與現有資料庫保持接近同步，縮短切換時的停機。
- 檢查所有外部連線，例如金流、簡訊、第三方 API 是否有 IP 白名單需要更新。
試跑時間要足夠，至少涵蓋一個完整的業務週期，例如月結或活動期間，才能發現週期性的問題。
五、切換日的作業
- 公告：事先通知使用者與相關部門，說明時間與影響。
- 降低 DNS TTL：提前幾天把網域的 TTL 調低，讓切換後更快生效。
- 凍結變更：切換前停止對現有系統的更新。
- 最後一次同步：停止寫入，完成最後的資料同步與驗證。
- 切換流量：調整 DNS 或負載平衡器，指向雲端環境。
- 驗證：由業務與技術人員確認核心功能，檢查日誌與監控。
- 保留舊環境：切換後至少保留舊環境數日到數週，作為回退用途。
六、回退計畫
回退計畫要事先寫好：判斷失敗的標準是什麼、誰有權決定回退、回退的具體步驟與所需時間，以及回退期間資料如何處理。如果切換後雲端已有新資料，回退時要考慮如何把新資料同步回舊系統。沒有回退計畫的搬遷，風險等同賭博。
七、搬遷後的優化與常見遺漏
- 規格調整：依監控數據調整，避免沿用過大的規格。
- 預算與警示：搬遷完成後立即設定，詳見預算警示與帳單監控。
- 備份與還原演練：確認雲端備份有效。
- 舊設備處理：硬碟資料要確實清除，處理舊設備與合約，避免持續付費。
- 文件更新：更新網路圖、維運手冊與緊急聯絡方式。
- 資安：重新檢查防火牆、權限與日誌，詳見資安設定錯誤如何造成費用暴增。
八、搬遷時程與分工範例
搬遷最怕「全部一起來」。下表是一個虛構的示意時程，適用於有三到五個系統的小型公司，實際週數要依規模與人力調整。
| 階段 | 週次 | 主要工作 | 負責人 |
|---|---|---|---|
| 盤點與規劃 | 第 1 到 2 週 | 資源清單、相依關係圖、成本比較、風險清單 | 技術負責人與管理者 |
| 環境建立 | 第 3 週 | 帳號、網路、權限、預算警示、監控 | 技術負責人 |
| 試跑一個低風險系統 | 第 4 到 5 週 | 搬遷內部系統，累積經驗與調整流程 | 技術團隊 |
| 搬遷主要系統 | 第 6 到 8 週 | 資料同步、驗證、壓力測試、切換 | 技術團隊與業務代表 |
| 穩定期與優化 | 第 9 到 12 週 | 規格調整、成本檢討、舊環境下線 | 技術負責人與財務 |
先搬低風險系統是個好策略，因為第一次搬遷一定會遇到沒想到的問題，用不重要的系統來學習，代價最低。每個階段結束時做一次簡短檢討，把學到的調整寫進下一階段的計畫。
九、人力與隱性成本
搬遷的成本不只是雲端月費。常被低估的項目包括：盤點與文件整理的人力、學習新平台的時間、雙軌並行期間同時支付舊環境與新環境、搬遷期間的加班與外部顧問費用、測試與驗證的時間，以及搬遷後調整規格的反覆過程。保守的做法是在預算中加上相當比例的緩衝，並明確區分「一次性搬遷成本」與「搬遷後每月成本」，後者才是和現況做長期比較的基礎。如果公司沒有足夠的人力，可以考慮請有經驗的顧問協助第一次搬遷，但要求他們留下完整的文件與交接，避免日後無人能維護。
十、搬遷風險清單
| 風險 | 可能後果 | 降低風險的方法 |
|---|---|---|
| 資料在同步或切換時遺失 | 業務資料不完整 | 切換前後核對筆數與關鍵資料，保留舊環境 |
| 相依服務被遺漏 | 切換後某些功能失效 | 製作相依圖，逐一測試外部連線 |
| 效能不如預期 | 使用者體驗下降 | 先壓力測試，保留擴充空間 |
| 授權不允許 | 違反授權條款 | 搬遷前向廠商確認 |
| 成本超出預期 | 預算失控 | 搬遷後立即設定預算警示並每週檢視 |
| 人員不熟悉 | 維運出錯 | 安排訓練與演練，留下文件 |
| 停機時間過長 | 業務中斷 | 使用資料同步、挑選離峰時段、準備回退 |
| 資安設定疏漏 | 資料外洩或費用暴增 | 搬遷後做資安檢查，參考資安設定錯誤如何造成費用暴增 |
十一、搬遷完成後的驗收
搬遷不是切換完成就結束，建議訂出明確的驗收標準，並在穩定運行一到兩個月後正式結案：功能面（核心流程都能正常運作、整合與排程無誤）、效能面（回應時間與尖峰表現不低於搬遷前）、成本面（實際費用與預估相比，差異在可接受範圍）、安全面（權限、日誌、備份都已設定並測試）、文件面（網路圖、操作手冊與緊急聯絡資訊都已更新）。驗收結果和遇到的問題整理成簡短報告，作為下一個系統搬遷的參考。若發現實際費用高於預估，就用成本分析逐項檢視，找出調整空間，而不是直接認定雲端不划算。
常見問題
搬遷需要停機多久？
取決於資料量與同步方式。使用持續同步的方式，停機可縮短到數分鐘到數小時；沒有同步的話，要預留完整資料搬移的時間。
搬到雲端一定會比較便宜嗎？
不一定。雲端的優勢在彈性與維運簡化，若負載長期穩定且已有閒置機房資源，自建不一定比較貴。要用完整成本比較。
舊的授權可以直接用在雲端嗎？
視授權條款而定，有些商用軟體對雲端使用有特殊規定。請向軟體廠商或代理商確認。
參考來源
- 數位發展部 — 政府雲端與資安相關政策資訊
- Amazon Web Services — 遷移與現代化相關文件
- Google Cloud — 遷移指南
- Microsoft Azure — 遷移與雲端採用框架
