Oracle EBS 還能撐多久？2037 支援年限下的留守與遷移決策框架（2026）

39

台灣還有一批 Oracle EBS 的深度用戶——電信、金融、大型製造，當年投入數千萬客製，系統穩定得像廠房的一部分。每年預算會議都有人問同一題：「要不要搬？」而每年的答案都是「再看看」。這篇給你一個比「再看看」更好的決策方法。

先把最關鍵的事實放前面：EBS 沒有近在眼前的死線。 Oracle 對 EBS 12.2 採 Continuous Innovation 模式，Premier Support 依官方支援政策已延展至 2037 年，且每年滾動延展。所以 EBS 的問題從來不是「Oracle 要斷你」，而是三個慢性病。

---

留守的三個慢性病

人才凋零。 EBS 的技術棧（Forms、PL/SQL 客製體系）不再有新血投入，會的人逐年退休或轉行。今天找一個資深 EBS 技術顧問已經比五年前難，十年後這條曲線只會更陡。留守的真實風險不是系統壞掉，是壞掉時找不到人修。

周邊在跑、核心在原地。 電商、AI 應用、新的分析工具，全部長在雲端生態；EBS core 越穩定，它和周邊系統的落差就越大，中間的介接層越疊越厚。而且 2026 年起的原廠 AI 戰略很明確——新的 AI 能力壓在雲端產品上，地端存量客戶拿不到。

年度成本不會變小。 約授權金額 22%/年的支援費照付、自建機房與 IT 人力照養、大版本升級照樣是獨立專案。留守不是免費選項，它是一個每年千萬級的持續決策。

遷移的三條路徑

路徑一：Oracle Fusion。 原廠指定的接班路線，資料模型與 EBS 不同、客製全部重寫——本質是重新導入，不是升級。適合仍認同 Oracle 生態、且組織已準備好雲端強制跟版節奏的企業。

路徑二：換廠牌。 既然橫豎都是重新導入，S/4HANA、甚至依規模降階到其他方案都回到選型原點。這條路的思考方式見我們的 ERP 選型指南。

路徑三：混合過渡。 核心財務留 EBS，先把周邊（採購、費用、分析）搬上雲端模組，用幾年時間分段遷移。優點是風險分散，缺點是雙棧並行的介接與維運成本，且過渡期常常一過就是十年——「暫時」是 IT 界最長的時間單位。

決策框架：把「再看看」換成一張多年期的帳

方法與我們的 TCO 模型同構，多加三個 EBS 特有的變數：

一、留守成本要算全：年度支援費＋機房與人力＋下一次升級專案＋「關鍵人員離職」的風險準備（這條最難量化，也最真實——幫你維護客製的那位工程師幾歲了？）。

二、遷移成本要算真：Fusion 級的重新導入以千萬計、時程以年計，深度客製的轉換另計。用樂觀數字騙自己，只是把痛延後。

三、時間窗要主動選。最糟的遷移是被迫的遷移——關鍵人員突然離職、硬體壽終、或業務出現 EBS 撐不住的新需求時倉促啟動。健康的做法是每年更新這張帳、訂一個觸發條件（例如「維護客製的人力只剩一人」或「介接層成本超過核心維護費」），條件到了就啟動，不到就安心留守——留守是一個決策，不是一個拖延。

台灣視角的兩個提醒

在地化包袱要單獨評估：EBS 上多年累積的統一發票、營業稅客製，搬到任何新平台都要重做，這塊常被遷移報價低估。另外，這個決策結構和鼎新 TIPTOP 老客戶面對 T100 的處境完全同構——如果你集團裡兩種系統都有，可以用同一套框架一起評。

---

常見問題（FAQ）

Oracle EBS 支援到什麼時候？ 依 Oracle 官方支援政策，EBS 12.2 的 Premier Support 已延展至 2037 年，並採每年滾動延展模式，沒有固定的版本終止日。例行更新含在年度支援費內。

EBS 一定要搬去 Fusion 嗎？ 不一定。Fusion 是原廠接班路線，但因為遷移本質是重新導入，換廠牌或混合過渡都是合理選項，應回到選型與 TCO 邏輯評估。

什麼時候該啟動遷移？ 建議設定明確觸發條件（關鍵維護人力、介接成本、業務新需求），每年檢視留守與遷移的多年期成本比較，主動選擇時間窗，避免被迫倉促遷移。

---

本文支援政策與成本結構以 Oracle 公開資訊與市場常見實務為據，實際以貴公司合約與原廠最新公告為準。若需要協助建立 EBS 去留的評估模型，歡迎與我們聯繫。