ECC 移轉至 S/4HANA：路徑、步驟與時程

SAP ECC 的主流維護將於 2027 年 12 月 31 日結束，距今約 15 個月。選購的延伸維護可延到 2030 年底，費用較高（SAP News）。複雜的移轉一旦開始實際測試，輕易就會拖到 18 至 24 個月。如果您還沒選定路徑，要在期限之前上線，已經不太可能。

如果您是做這項決定的 CIO 或專案負責人，您有三條路徑：Greenfield、Brownfield 或選擇性資料轉換。每條路徑背後的工作都遵循同樣的五個步驟。先執行 SAP Readiness Check，再做選擇。

ECC 移轉到 S/4HANA 不是單純的升級。它改變資料的儲存方式、交易的過帳方式，以及使用者的工作方式。在我參與的一個專案裡，團隊把幾十份客製報表照 ECC 的樣子原封不動重建一遍。沒有人問過這些報表是否還需要。後來，其中一半從來沒人用過。技術上，這次移轉很乾淨；價值卻不是。

決定移轉工作量的差異如下：

面向	SAP ECC	SAP S/4HANA
資料庫	任何受支援的資料庫（Oracle、Db2、SQL Server 等）	僅限 SAP HANA
財務資料模型	FI、CO 與獲利能力分析各有獨立資料表，另有合計表	Universal Journal（資料表 ACDOCA）作為單一的明細項目來源
客戶與供應商主檔	客戶與供應商各自獨立的記錄	必須使用業務夥伴 (Business Partner)
使用者介面	SAP GUI	SAP Fiori 應用程式，地端與 Private Edition 仍可使用 SAP GUI
部署方式	地端	地端、Private Edition（RISE with SAP）或 Public Edition（GROW with SAP）
擴充方式	Z 程式與修改	Clean Core：已釋出的 API、On-stack ABAP Cloud，或在 SAP BTP 上的 side-by-side 擴充
維護	EHP 6 至 8 主流維護到 2027 年底，延伸維護到 2030 年底	SAP 承諾維護到 2040 年底

我合作過的一位客戶，在轉換之後一直在問，為什麼他們的客製批次作業不再運作。那些邏輯仰賴的是 ECC 的資料表結構，而 S/4HANA 已經改變了它們。移轉本身已經完成。沒有人問過，這些作業在新的模型裡是否還說得通。

移轉搬的是資料。真正的問題是，您要如何處理承襲下來的設計決策。

Decide

哪一條移轉路徑適合您的情況？

舊系統零散，希望重新設計流程

→Greenfield

流程穩健、ECC 運作穩定、歷史資料必須保留

→Brownfield

多個法人實體，希望部分重用並選擇性轉換資料

→Bluefield

Greenfield：全新起步

這是 S/4HANA 的全新導入。不沿用任何舊有組態，流程依 SAP 標準重新設計，只用 SAP S/4HANA Migration Cockpit 載入您需要的資料。

適用時機： 舊系統太零散，無法乾淨地轉換，或業務端想重新思考流程，而不是照抄。

留意： 變革的負荷。使用者會失去熟悉的工作流程。我見過一些公司後悔沒有事先讓使用者準備好，面對 Greenfield 系統裡那種截然不同的感受。如果採用度的規劃要到訓練階段才開始，就已經太晚了。

Brownfield：系統轉換

您現有的 ECC 系統就地轉換。組態、客製程式碼與歷史資料都會一併帶過去。技術轉換透過 Software Update Manager (SUM) 及其資料庫移轉選項執行。

適用時機： 流程已經成熟、交易歷史資料對法令遵循很重要，而且沒有重大的組織重整正在進行。

留意： 您一併帶過去的技術債。除非在轉換期間刻意清理，否則舊有的複雜度會跟著搬過去。

選擇性資料轉換

有時被包裝成「Bluefield」。您只搬移選定的公司代碼、事業單位或某些時間區段的資料，而不是全部，通常要搭配專用工具，以及熟悉這類做法的夥伴。它適合透過併購或業務分拆形成的集團，或是多年前的歷史資料已不再重要的情況。

適用時機： 您想要 Greenfield 式的流程自由度，同時在關鍵之處保有 Brownfield 式的資料延續性。

董事會通常會問的幾個問題，三者的比較如下：

比較項目	Greenfield	Brownfield	選擇性
流程重新設計	完整，依 SAP 標準	大致保留	依各單位選定
歷史資料	不帶過去（或只帶未結項目與餘額）	全數帶過去	選定的範圍
上線所需時間	較長	較短	視範圍而定
技術債	清除	沿用	已移轉範圍的技術債減少
變革衝擊	高	較低	中等
最適合	舊系統零散、需大幅重新設計	運作穩定、維護良好的 ECC	併購、業務分拆、分階段推行

移轉步驟

1. 01

   評估

   執行 SAP Readiness Check。盤點客製程式碼、附加元件與介面。

2. 02

   資料分類

   將資料分成熱、溫、冷。冷資料不必搬移。

3. 03

   資料清理

   解決重複、不一致與欄位缺漏的問題。耗時總是比計畫的長。

4. 04

   調整程式碼

   執行 ABAP Test Cockpit 檢查。減少 Z 程式碼，而不只是照搬。

5. 05

   測試與切換

   多輪測試，加上至少一次完整的切換演練。

1. 評估與就緒度

從這裡開始。永遠如此。SAP Readiness Check 會分析您的 ECC 系統，並回報簡化項目、附加元件相容性、客製程式碼、資料量與規模評估。

意外通常出在附加元件與客製程式碼。我合作過的一些客戶，範圍內有數百個客製物件，而且大多數人都對冒出這麼多未使用的程式碼感到意外。在第二週發現，總比在第十二個月才發現好。

同時檢查技術前提條件。轉換可以從任何增強包 (enhancement package) 的 SAP ERP 6.0 開始。系統必須是 Unicode，否則就要規劃兩步驟轉換。雙堆疊 (dual-stack) 系統必須先拆分。客戶與供應商主檔必須在轉換之前先轉成業務夥伴。最後這一項讓最多團隊栽跟斗。

2. 資料分析與分類

搬移資料之前，先衡量它，並加以分類：

1. 熱資料： 經常使用，即時處理所需。
2. 溫資料： 偶爾存取，有關聯但不是每天都用。
3. 冷資料： 歷史資料或已不使用，僅為稽核保留。

冷資料不需要進入 S/4HANA。把它封存。略過這個步驟的團隊，會把雜物帶進新系統，既拖慢移轉，也拖慢效能。

3. 資料清理與封存

這個步驟花的時間，總是比每一份計畫預留的都長。重複的供應商記錄。不一致的計量單位。填到一半的客戶主檔。每個 ECC 系統裡都有這些問題，如果沒人先修正，它們就會原封不動進到 S/4HANA。

我合作過的一位客戶，光是資料清理與封存就花了五個月。略過清理的團隊，會在切換期間才發現問題，那時已經沒有時間好好修正。我那篇談 SAP 資料移轉為何失敗的文章，對這個步驟有更深入的說明。

4. 客製程式碼調整

執行 ABAP Test Cockpit (ATC) 的 S/4HANA 就緒度檢查，它會把您的程式碼與 SAP 的簡化項目做比對。輸出結果會顯示哪些需要修正語法、哪些需要功能替換，以及哪些應該淘汰。

目標是更少的 Z 程式碼，而不只是能運作的 Z 程式碼。您每多帶過去一個客製物件，未來每次升級的成本就多一分。我的 Clean Core 指南說明了如何對留下來的部分分類。

5. 測試、訓練與切換

測試要分輪進行：單元測試、整合測試、使用者驗收測試 (UAT)，然後至少一次完整的切換演練。UAT 要同時納入重度使用者與偶爾使用者，他們會找出不同的問題。

演練不是可有可無。它會揭露時程缺口、遺漏的驗證，以及整個流程跑起來才會出現的介面失敗。略過演練的團隊，會在上線的週末撞上這些問題。

任何移轉計畫裡，我都預期會看到這些 SAP 工具：

工具	用途	使用時機
SAP Readiness Check	簡化項目、附加元件、客製程式碼、規模評估	選擇路徑之前
ABAP Test Cockpit (ATC)	找出會出問題的客製程式碼	客製程式碼調整時
SAP Signavio	呈現流程實際如何運作，而不是文件上怎麼寫	設計凍結之前
SAP LeanIX	描繪應用程式與介面	整合設計時
Software Update Manager (SUM)	執行技術轉換	Brownfield 轉換時
SAP S/4HANA Migration Cockpit	載入主檔與交易資料	Greenfield 資料移轉時

對於增強包 6 至 8 的 SAP ERP 6.0，主流維護於 2027 年 12 月 31 日結束。選購的延伸維護可延到 2030 年 12 月 31 日，需在維護費基數上加收兩個百分點。更早的增強包已在 2025 年底結束主流維護。

2030 年之後只有一條狹窄的路。SAP 的 SAP ERP, private edition, transition option 涵蓋 2031 至 2033 年。它只適用於在 2030 年底之前、已移到 SAP HANA 上 SAP ERP, private edition 的大型系統，而且必須搭配 SAP 的 max success plan。把它當成例外，不要當成計畫。

至於時間長度，複雜系統的完整移轉一旦開始實際測試，可能拖到 18 至 24 個月甚至更久。對中大型企業來說，準備充分的轉換，12 至 18 個月以上是務實的預期。跨多個法人實體的大型 Greenfield 專案，則可能需要 24 至 36 個月。

1. 2027ECC 主流維護結束12 月 31 日，適用於 SAP ERP 6.0 EHP 6 至 8
2. 2028現在開始的話，可能的上線時間開始實際測試後需 18 至 24 個月
3. 2030延伸維護結束選購，需加收兩個百分點
4. 2033過渡選項結束僅限 Private Edition 的大型系統

來源: SAP News，2020 年 2 月與 2025 年 8 月

所以算術很簡單。如果您今天才開始複雜的評估，上線會落在 2028 年。請為延伸維護編列預算，並把這段時間用來清理資料、淘汰客製程式碼，而不是乾等。想測試您有哪些選擇，可以試試我的移轉評估工具。

ECC 移轉至 S/4HANA 的 Greenfield 與 Brownfield 有什麼差別？

Greenfield 是全新導入：不沿用舊有組態或客製程式碼，流程依 SAP 標準設計，只載入您需要的資料。Brownfield 則是轉換您現有的 ECC 系統，保留組態、客製程式碼與歷史資料。它比較快、干擾較小，但技術債也會一併帶過去。選擇性資料轉換介於兩者之間。

SAP ECC 移轉至 S/4HANA 的期限是什麼時候？

對於增強包 6 至 8 的 SAP ERP 6.0，主流維護於 2027 年 12 月 31 日結束。選購的延伸維護可延到 2030 年 12 月 31 日，需在維護費基數上加收兩個百分點。2031 至 2033 年的過渡選項，只適用於在 2030 年底之前已移到 SAP HANA 上 SAP ERP, private edition 的大型系統。

SAP Readiness Check 會告訴您什麼？

它會分析您的 ECC 系統，並回報會影響您組態的簡化項目、附加元件相容性、客製程式碼的影響、資料量與 HANA 規模評估。及早執行，會改變範疇的討論，因為團隊常常發現自己根本不知道有依賴的附加元件與客製程式碼。

ECC 移轉至 S/4HANA 需要多久？

對中大型企業來說，準備充分的轉換，常需要 12 至 18 個月以上。複雜的多法人實體專案，一旦開始實際測試，可能拖到 18 至 24 個月；大型 Greenfield 專案則是 24 至 36 個月。資料清理是時程延誤最常見的原因。

Universal Journal (ACDOCA) 是什麼？為什麼對移轉很重要？

Universal Journal 是單一的明細項目資料表 ACDOCA，把 ECC 原本放在不同資料表裡的財務會計、管理會計與獲利能力分析資料整合在一起。讀取舊結構（例如 COEP 或獲利能力分析資料表）的客製程式碼與報表，都需要檢視。有些只需小幅調整，有些則需要重新設計。

把 ECC 轉換為 S/4HANA 有哪些技術前提條件？

轉換可以從任何增強包的 SAP ERP 6.0 開始。系統必須是 Unicode，否則要採用兩步驟做法。雙堆疊系統必須先拆分。客戶與供應商主檔必須轉成業務夥伴。在您確定日期之前，先執行 SAP Readiness Check 與 ATC 客製程式碼檢查。

ECC 移轉該選 RISE with SAP 還是 GROW with SAP？

大多數客製程式碼龐大、流程複雜的 ECC 客戶，會選擇 RISE with SAP 下的 S/4HANA Cloud Private Edition，它支援轉換現有系統。GROW with SAP 採用 Public Edition，那是全新導入，只有標準流程與已釋出 API 的擴充。它適合願意採用 SAP 標準的公司。