文章目錄
「要不要升級」在地端時代是個每隔幾年痛一次的大決策；到了雲端時代，問題反過來變成「升級由不得你，你跟不跟得上」。這兩種模式的版本管理是完全不同的兩門功課，但很多人把它們當同一件事在想，才會兩邊都做不好。這篇分開講，也用一個比喻把它們一次擺對位置。
先破除一個假設：「雲端升級是廠商的事，跟我無關」
我最近陪一家剛上雲的公司開季度檢討，IT 主管一臉困惑地問我：「我們明明什麼都沒改，為什麼這一季使用者一直在問『這個畫面怎麼變了』？報表也有兩張跑不出來。」
答案是：原廠上週剛做了季度更新。他以為雲端升級是「廠商的事，跟我無關」——這正是最貴的一個假設。
原廠確實幫你把系統換新了，但你當年自己加蓋的東西，沒人幫你保固。這就是我今天要用一個比喻，把地端和雲端的版本管理一次講清楚的原因。
用一句話定位這兩種升級：地端升級像搬家（大工程、久久一次、可以挑日子），雲端跟版像房子的定期保養（小事、但停不了、由不得你）。 搞混這兩件事的人，會拿搬家的心態去應付保養（每季都當大專案，累死），或拿保養的心態去應付搬家（隨便升一升，出事）。
地端：升級是一次「搬家」，不是一次更新
地端 ERP 的大版本升級（例如跨版號的升版），正確的心理定價是一次搬家——一個三到六個月的小型專案：環境評估、客製盤點、測試環境升級、回歸測試、正式升級與停機。就像搬家最累的從來不是搬空屋，而是那些年你囤積的家當：最大的工作量幾乎永遠在同一個地方——客製程式的相容與轉換。
當年每一支「貼心的客製」，升級時都要逐支確認在新版本上還能不能跑、要不要改寫；客製上百支的系統，光盤點與測試就是數十人天起跳。這是我們反覆講「客製要節制」的長期帳（短期帳見失敗學的死法五）。
該不該搬（升）？ 地端升級不必追新——穩定運行的版本沒有立即理由動它，就像房子好好的不會沒事搬家。但三種訊號出現就該排進計畫：
- 支援斷崖：現行版本即將離開原廠支援範圍，之後的法規更新與修補拿不到（支援年限與維護費的關係，見我們的維護費專文）。
- 法規強制：稅務或發票新制只在新版本支援。
- 業務需求：要用的新功能或要接的新系統只支援新版。
三種訊號都沒有的話，「別人都升了」不是理由。
搬家（升級專案）的三個要點：先在測試環境完整演練一輪（含全部客製的回歸測試與月結試跑），量出真實的停機窗口；停機排在連假或月初低峰；升級前的完整備份與回退點——和上線切換一樣，沒有回退計畫的升級是在裸奔（切換的作戰方法同樣適用，見上線切換專文）。搬家你會先租倉庫、留退路，升級也是。
雲端：強制跟版之下，你的功課是「定期保養」
雲端 ERP（Fusion、NetSuite、各家雲版）把升級的主導權收走了：原廠按季度或半年度自動更新、強制跟版，不能說不。這就像你住的大樓，管委會排定的公共管線保養，你不能說「這個月不方便」。好處是永遠最新、沒有支援斷崖；代價是節奏由別人定——每季都有一包新功能與異動落到你頭上，接不住的公司會發現使用者每季都在問「這個畫面怎麼變了」。
保養的常態機制（一次建好，每季重複）：
- 讀版本說明：指派專人（系統管理員或超級使用者）在每次更新前讀原廠 release note，篩出「與我們有關的異動」清單——全文照轉發等於沒發。
- 測試窗口：雲端更新多半先進非正式環境給你幾週測試期，把 UAT 留下的核心案例（關鍵流程、月結）挑二十條做成「季度回歸包」，每季在測試環境跑一輪。這是雲端版本管理的主要工作量。
- 異動溝通：影響使用者操作的變更，在生效前用一頁式說明通知到相關角色。
三件事都不大，但每季都要做——雲端省掉的是搬家（升級專案），換來的是永不停歇的定期保養，這正是 TCO 模型裡「雲端大幅降低但不歸零 IT 人力」的具體內容（見我們的 TCO 專文）。
雲端的客製紀律更嚴：強制跟版意味著你的擴充必須用原廠認可的擴充框架做（而不是改核心），否則每季更新都是一次俄羅斯輪盤。就像你在大樓裡自己動手改了公共管線，下次全棟保養時，被壓到的一定是你那段。評估雲端客製需求時，「這個做法升級時會不會死」是第一個問題，不是最後一個。
共通鐵律：版本管理的成本，在客製決策時就決定了
把搬家和保養放在一起看，結論收斂成一句話——這是這篇你唯一要帶走的定律：
你今天的每一支客製，都是未來每一次版本異動的測試負債。
地端付的是升級專案（搬家）裡的轉換費，雲端付的是每季回歸測試（保養）的人力。無論你在哪一種模式，客製都不是一次性的成本，而是每次版本異動都要重付一遍的利息。所以版本管理最有效的動作不在升級當下，在平時：
- 客製清單有人維護（每支客製記錄用途、負責人、對應的標準功能缺口）。
- 每年檢視一次「這支客製還需要嗎」——新版本常常已經內建當年缺的功能，客製能退役就退役。
最好管理的版本，是客製最少的版本。
兩張表帶走：對照表 ＋ 三訊號清單
地端 vs 雲端版本管理對照表
| 維度 | 地端（搬家） | 雲端（定期保養） |
| 主導權 | 在你手上，升不升你決定 | 在原廠手上，強制跟版 |
| 觸發時機 | 三訊號出現才動（久久一次） | 原廠排程，每季／每半年一次 |
| 主要成本 | 升級專案的轉換費＋停機 | 每季回歸測試的內部人力 |
| 核心動作 | 盤點客製、回歸測試、排停機、備妥回退 | 讀 release note、跑季度回歸包、異動溝通 |
| 客製風險 | 升級時逐支確認相容與改寫 | 每季更新可能波及，等於俄羅斯輪盤 |
| 該做的紀律 | 把升級當專案做、留回退點 | 擴充走原廠框架、建季度跟版機制 |
該不該升的三訊號決策清單（地端用，逐格打勾）
| 訊號 | 你的情況 | 打勾？ |
| 支援斷崖：現行版本即將離開原廠支援 | ☐ | |
| 法規強制：稅務／發票新制只在新版本支援 | ☐ | |
| 業務需求：要用的新功能／要接的新系統只支援新版 | ☐ |
三格全空＝先不升，穩定優先於新版；有任一格打勾，就把升級排進計畫。「別人都升了」不是第四個訊號。
常見問題（FAQ）
地端 ERP 多久該升級一次？
沒有固定週期。守住三個訊號：支援斷崖、法規強制、業務需求。都沒有時，穩定優先於新版。但「永遠不升」也不是策略——版本落後太多時，一次跳多版的升級難度是指數成長，等於一次要搬十年的家。
雲端 ERP 的強制更新會不會把系統改壞？
原廠更新本身出大問題的機率低，風險集中在「你的擴充與介接」被異動波及。對策是擴充走原廠框架、每季用回歸測試包驗證核心流程。
升級要花多少錢？
地端大版本升級常見為原導入費的兩到四成（客製多則更高，示意值、依實際範圍），另計停機與內部人力。雲端無升級專案費，但每季回歸測試的內部人力要編入常態維運（約每季數個人天起，示意值）。
【給決策者的備忘錄】
如果你現在最怕動的，是那幾支當年沒人敢刪的客製——那不是你的錯，是版本管理的成本本來就藏在客製決策裡，只是帳單晚了幾年才來。
你要做的其實只有三件事：分清楚自己是在搬家還是在保養（別用錯心態）、把三訊號清單貼在牆上（別為「別人都升了」動手）、每年清一次客製清單（把利息越還越少）。
如果你想知道自家系統該怎麼排升級時點、或怎麼建一套每季不會爆炸的跟版機制，歡迎與我們聯繫。我們不幫你追最新版，我們幫你把版本管到最省心。
本文為版本管理的一般性方法，各系統機制差異大，升級費率與人力為市場常見區間之示意值，請以原廠政策與實際範圍為準。若需要協助評估升級時點或建立季度跟版機制，歡迎與我們聯繫。
