ECC 移轉至 S/4HANA 指南：路徑、步驟與 SAP ECC 期限

ECC 移轉至 S/4HANA，是把您的 SAP ERP 系統從 SAP ECC 6.0 移到 SAP S/4HANA，同時換上新的資料庫、財務資料模型與使用者介面。您要做的決定是走哪一條路徑，以及能否在 ECC 主流維護於 2027 年 12 月 31 日結束前上線。

簡短的答案：從其他系統移轉過來或需要新流程，選 Greenfield；流程已定義且運作良好，選 Brownfield；只有部分領域需要重新設計，選選擇性資料轉換。依我的經驗，Brownfield 需要 12 至 18 個月，Greenfield 需要 18 至 24 個月，選擇性資料轉換需要 12 至 18 個月。在確定任何一條路徑之前，先執行 SAP Readiness Check。

ECC 移轉至 S/4HANA 不是單純的升級。資料的儲存方式、交易的過帳方式，以及使用者的工作方式都會改變。

在我參與的一個專案中，團隊把數十份客製報表照著 ECC 裡的原樣重建了一遍。沒有人問過它們是否還需要。後來，其中一半從未被使用。

移轉在技術上很乾淨。價值卻沒有出現。

SAP ECC 是 SAP ERP Central Component 的縮寫。它是 SAP ERP 6.0 的核心，也是 SAP Business Suite 7 的核心應用之一。大家說「SAP ECC」時，幾乎都是指 ECC 6.0。它在 SAP 支援的任何資料庫上執行財務、管理會計、採購、銷售與生產，從 Oracle 到 SQL Server 與 Db2 都可以。

移轉的第一個理由是維護。對於強化套件 6 至 8 的 SAP ERP 6.0，主流維護於 2027 年 12 月 31 日結束。強化套件 5 以下的系統已在 2025 年底結束主流維護（SAP）。

SAP S/4HANA 是它的後繼產品，SAP 已承諾維護到 2040 年底。

第二個理由是時間。如果您今天，也就是 2026 年 10 月，開始 Brownfield 轉換，上線會落在 2027 年底到 2028 年春之間。如果今天開始 Greenfield，您會在 2028 年上線。

所以對大多數 ECC 客戶來說，問題已經不是要不要移轉。問題是走哪一條路徑，以及移轉期間要為延伸維護編列多少預算。

我也在自己的 YouTube 頻道上用一支影片（英文）講解了這個主題。

決定大部分移轉工作量的，是以下這些差異：

領域	SAP ECC	SAP S/4HANA
資料庫	任何受支援的資料庫（Oracle、Db2、SQL Server 等）	僅 SAP HANA
財務資料模型	FI、CO 與獲利能力表各自獨立，並有彙總表	通用日記帳（表格 ACDOCA）作為唯一的明細項目來源
客戶與供應商主檔資料	客戶與供應商記錄分開	業務夥伴為必要項目
物料號碼	18 碼	啟用延伸長度後最多 40 碼
信用管理	SD 信用管理	SAP Credit Management（FIN-FSCM）
使用者介面	SAP GUI	SAP Fiori 應用程式，地端與 Private Edition 仍可使用 SAP GUI
部署方式	地端	地端、Private Edition（RISE with SAP）或 Public Edition（GROW with SAP）
擴充	Z 程式與修改	Clean Core：已發布的 API、堆疊內的 ABAP Cloud，或在 SAP BTP 上的並行擴充
維護	EHP 6 至 8 主流維護到 2027 年底，延伸維護到 2030 年底	承諾維護到 2040 年底

SAP 把每一項差異都記錄為一個簡化項目，並在每個 S/4HANA 版本的簡化清單中公布。有些對每位客戶都是必要的，例如業務夥伴。其他則只有在您使用該功能時才有影響，而 SAP Readiness Check 會告訴您哪些適用於您的系統。

2023 年我合作過的一家歐洲製造業客戶，一直問為什麼轉換後他們的客製批次作業不再運作。那些邏輯依賴 ECC 的表格結構，而 S/4HANA 已經改變了這些結構。沒有人問過這些作業在新模型中是否仍有意義。

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

我的選擇原則很簡短。從其他系統移轉過來，或需要定義新流程時，選 Greenfield。流程已定義且運作良好時選 Brownfield，部分領域的流程需要重新定義時選選擇性資料轉換。

Decide

哪一條 ECC 移轉至 S/4HANA 的路徑適合您的情況

→Greenfield

從其他系統移轉過來，或需要定義新流程

→Brownfield

流程已定義且運作良好

→選擇性資料轉換

只有部分領域需要重新定義流程

Greenfield：全新導入

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

如果您目前有一部分業務在非 SAP 系統上運作，這是自然的選擇。我看過一些公司後悔沒有讓使用者事先準備好面對 Greenfield 系統帶來的巨大差異。如果使用者採用的規劃要到教育訓練階段才開始，那就已經太晚了。

Brownfield：系統轉換

Brownfield 就是系統轉換。您現有的 ECC 系統就地轉換，設定、客製程式碼與歷史資料都會跟著過去。技術轉換透過 Software Update Manager（SUM）及其資料庫移轉選項完成。

SAP 針對每個版本發布 SAP S/4HANA Conversion Guide，內容包含前提條件與技術步驟的順序。在規劃日期之前，先讀目標版本的那一份。風險在於帶過去的技術債，因為除非您刻意清理，舊有的複雜度也會一起移過去。

選擇性資料轉換

選擇性資料轉換只移轉選定的公司代碼、事業單位或特定期間的資料，而不是全部。它需要專門的工具，以及在這方面有經驗的合作夥伴。有些廠商以「Bluefield」的名稱銷售。

它適合這樣的集團：財務運作良好，但採購需要重新設計；或者併購與分拆讓差異很大的流程並存。您可以重新設計需要改的領域，並在重要的地方保留歷史資料。

以下依董事會通常會問的問題，比較三條路徑：

路徑	何時選擇	典型時程	主要風險
Greenfield	從其他系統移轉過來，或需要定義新流程	18 至 24 個月	使用者承受的變革負擔，以及留在舊系統的歷史資料
Brownfield	流程已定義且運作良好	12 至 18 個月	技術債與未使用的客製程式碼被帶過去
選擇性資料轉換	部分領域的流程需要重新定義	12 至 18 個月	依賴專門工具與合作夥伴，資料範圍界定複雜

路徑不同，細節會變，但順序不變。以下是我會規劃的五個步驟，依序排列。

移轉順序

1. 01

   Readiness Check

   執行 SAP Readiness Check，確認技術前提條件。

2. 02

   選擇路徑並規劃

   選擇路徑、確定範圍，在開始建置之前規劃整個計畫。

3. 03

   客製程式碼

   找出使用中的部分，淘汰其餘部分，調整保留下來的部分。

4. 04

   資料

   在移轉任何東西之前，先分類、清理與歸檔。

5. 05

   測試與切換

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

1. 執行 Readiness Check

從這裡開始。每一次都是。SAP Readiness Check 會分析您的 ECC 系統，並報告簡化項目、附加元件相容性、客製程式碼、資料量與容量規劃。

意外通常出在附加元件與客製程式碼。我合作過的一些客戶，範圍內有數百個客製物件。在第二週發現，總比在第十二個月發現好。

如果是 Brownfield 轉換，請同時檢查以下前提條件：

1. 版本：任何強化套件的 SAP ERP 6.0 都可以進行轉換。
2. Unicode：系統必須是 Unicode，否則就要規劃兩階段轉換。
3. 雙堆疊：雙堆疊系統需要先拆分。
4. 業務夥伴：客戶與供應商主檔資料必須在轉換前轉為業務夥伴。被這一項卡住的團隊，比其他任何一項都多。

2. 選擇路徑並規劃計畫

用 Readiness Check 的結果與我上面的原則選擇路徑。接著在任何人開始建置之前，規劃整個計畫，包括資料、測試與切換。

在我主導或救回的 21 個 SAP 計畫中，我看到最大的移轉錯誤，是在導入一開始沒有好好規劃移轉。在最初幾週就決定誰負責資料清理、淘汰哪些客製程式碼、何時進行切換演練。這些決定拖得越晚，代價越高。

3. 調整客製程式碼

在 ABAP Test Cockpit 中執行 S/4HANA 檢查，把您的程式碼與 SAP 的簡化項目做比對。Custom Code Migration 應用程式會把同樣的結果連同使用資料一起呈現，讓您在修改任何東西之前，就能看到哪些程式碼實際在用。

目標是更少的 Z 程式碼，而不只是能運作的 Z 程式碼。在一個計畫中，透過 smartShift 的分析，我們把客製物件從 18,000 個減少到 3,200 個。

您帶過去的每一個客製物件，都會增加日後每一次升級的成本。我看過企業運用 Clean Core 原則把升級時程縮短 40%，我的 SAP Clean Core 指南說明如何為保留下來的部分分類。

4. 準備並移轉資料

在移轉任何東西之前，先分類、清理與歸檔。這一步花的時間總是超過每一份計畫的預期，所以下面另闢一節說明。

5. 測試、教育訓練與切換

分輪進行測試：單元測試、整合測試與使用者驗收測試（UAT），然後至少做一次完整的切換演練。讓關鍵使用者與偶爾使用的使用者都參加 UAT，因為他們會發現不同的問題。

演練不是選項。它會揭露只有整個流程完整跑一遍時才會出現的時間落差、遺漏的驗證與介面故障。跳過演練的團隊，會在上線那個週末遇到這些問題。

依我的經驗，資料移轉占導入工作量的 30% 至 40%。它也是時程延誤最常見的原因。

資料怎麼移轉取決於路徑。在 Brownfield 中，SUM 就地轉換資料。在 Greenfield 中，您用 SAP S/4HANA Migration Cockpit 載入主檔資料與未結項目；在選擇性資料轉換中，則由專門工具移轉您選定的範圍。

無論哪一條路徑，移轉之前都要先為資料分類：

1. 熱資料：經常使用，日常作業需要。
2. 溫資料：偶爾存取，相關但不是每天使用。
3. 冷資料：歷史資料或未使用的資料，只為稽核保留。

冷資料不需要進入 S/4HANA。把它歸檔。重複的供應商記錄、不一致的計量單位與只填了一半的客戶主檔，每個 ECC 系統裡都有，如果沒有人先修正，它們會原封不動地進入 S/4HANA。

我合作過的一位客戶，光是資料清理與歸檔就花了五個月。我的文章為什麼 SAP 資料移轉會失敗對這一步有更深入的說明。

以下是我在 ECC 移轉至 S/4HANA 計畫中用過的五個工具。兩個是 SAP 自家的，三個來自專業廠商：

工具	提供者	功能	適用階段
SAP Readiness Check for SAP S/4HANA	SAP	報告簡化項目、附加元件相容性、客製程式碼影響、資料量與容量規劃	選擇路徑之前
Custom Code Migration 應用程式	SAP	執行 S/4HANA ABAP Test Cockpit 檢查，並利用使用資料找出未使用程式碼的 SAP Fiori 應用程式；可在 S/4HANA 或 SAP BTP ABAP 環境中執行	客製程式碼範圍界定與調整
smartShift	smartShift Technologies	針對 S/4HANA 的 ABAP 客製程式碼自動分析與轉換	客製程式碼分析與修正
SNP（Kyano 平台）	SNP Group	用於選擇性資料轉換的資料轉換軟體，以 SNP 的「Bluefield」方法銷售	選擇性資料轉換、併購與分拆
Natuvion	Natuvion Group	用於 S/4HANA 轉換的資料轉換軟體與切換工具	選擇性資料轉換與切換

SNP 與 Natuvion 都是 SAP Selective Data Transition Engagement 社群的創始成員。您還會遇到的其他 SAP 工具，是用於 Brownfield 轉換的 SUM，以及用於 Greenfield 資料載入的 Migration Cockpit。

工具取代不了決策。您這一方仍然需要有人來確定要淘汰什麼。

對於強化套件 6 至 8 的 SAP ERP 6.0，主流維護於 2027 年 12 月 31 日結束。選購的延伸維護從 2028 年到 2030 年 12 月 31 日，在您現有的維護基數上加收兩個百分點（SAP News）。

2030 年之後只有一條狹窄的路，也就是 SAP ERP, private edition 過渡選項。它為在 RISE with SAP 下，把 ECC 系統以 SAP HANA 上的 SAP ERP, private edition 形式移入 SAP 私有雲的客戶，提供 2031 至 2033 年的維護。系統必須在 2030 年 12 月 31 日前移轉，規模至少 2 TB，並需要 SAP 的 max success plan。

所以 2033 年不是普遍適用的期限。它適用於已經把 ECC 移入 SAP 雲端的大型系統。對其他所有人來說，在自有基礎架構上的 ECC，2027 年是主流維護期限，2030 年是延伸維護的終點。

1. 2027ECC 主流維護結束12 月 31 日，適用於 SAP ERP 6.0 EHP 6 至 8
2. 2028現在開始的話，可能的上線時間Brownfield 12 至 18 個月，Greenfield 18 至 24 個月
3. 2030延伸維護結束選購，加收兩個百分點
4. 2033過渡選項結束僅限 SAP ERP, private edition，2 TB 以上的系統

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

這筆帳很簡單。至少為一段時間的延伸維護編列預算，並利用這段時間清理資料、淘汰客製程式碼，而不是乾等。

成本和時程由相同的因素決定：路徑、客製程式碼的數量、資料的狀態，以及有多少個實體上線。光是資料就占工作量的 30% 至 40%，這就是為什麼一份乾淨的資料計畫，比任何費率談判都更省錢。我的 S/4HANA 移轉成本指南說明哪些因素決定移轉預算，我的 SAP 導入成本指南依公司規模拆解預算。

想看一個計畫實際如何進行，請閱讀我的 ECC 移轉至 S/4HANA 案例研究。想檢驗您自己的選項，可以試試 Greenfield 與 Brownfield 移轉評估。

本文是總覽。以下每一篇指南完整回答一個問題。

1. S/4HANA 移轉時程與專案計畫：依階段、依路徑說明，包含模擬轉換與切換。
2. S/4HANA 移轉成本：系統轉換、全新導入或選擇性轉換的預算由哪些因素決定。
3. SAP Readiness Check 與移轉評估：這項檢查能告訴您什麼，又會遺漏什麼。
4. SAP S/4HANA Migration Cockpit 逐步說明：透過暫存表或直接傳輸載入資料。
5. RISE with SAP：公有雲與私有雲：哪一個版本適合您的流程。
6. RISE with SAP 合約與定價：訂閱涵蓋哪些內容，以及要談判什麼。
7. 如何選擇 S/4HANA 移轉合作夥伴：該問的問題與警訊。
8. SAP 專案救援：如何救回偏離軌道的移轉。

有兩個工具可以協助計算數字：SAP 導入成本計算器與資料移轉估算工具。

什麼是 SAP ECC？

SAP ECC（SAP ERP Central Component）是 SAP ERP 6.0 的核心，屬於 SAP Business Suite 7。它涵蓋財務、管理會計、物流與其他核心流程，可在多種資料庫上執行。SAP S/4HANA 是它的後繼產品，只在 SAP HANA 上執行。

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

依我的經驗，Brownfield 轉換需要 12 至 18 個月，Greenfield 導入需要 18 至 24 個月，選擇性資料轉換需要 12 至 18 個月。資料清理是時程延誤最常見的原因，因為資料移轉占導入工作量的 30% 至 40%。

2027 年之後 SAP ECC 會怎樣？

對於強化套件 6 至 8 的 SAP ERP 6.0，主流維護於 2027 年 12 月 31 日結束。您可以額外支付兩個百分點，選購到 2030 年 12 月 31 日的延伸維護。2031 至 2033 年的維護只能透過 SAP ERP, private edition 過渡選項取得，適用於 2030 年底前移入 SAP 私有雲的大型系統。

Brownfield 與 Greenfield：哪一個比較好？

一般而言，兩者沒有優劣之分。從其他系統移轉過來或需要定義新流程時，選 Greenfield；流程已定義且運作良好時，選 Brownfield。如果只有部分領域需要重新設計，可以考慮選擇性資料轉換。

SAP 的選擇性資料轉換是什麼？

選擇性資料轉換把選定的公司代碼、事業單位或特定期間的資料移入 S/4HANA，而不是全部轉換或從零開始。它讓您可以重新設計部分領域，同時在其他領域保留歷史資料。它需要專門的工具，例如 SNP 或 Natuvion 的工具，以及有經驗的合作夥伴。

將 ECC 6.0 轉換為 S/4HANA 有哪些前提條件？

任何強化套件的 SAP ERP 6.0 都可以進行轉換。系統必須是 Unicode，否則就採用兩階段方式；雙堆疊系統必須先拆分。客戶與供應商主檔資料必須在轉換前轉為業務夥伴。

SAP Readiness Check 能告訴您什麼？

它分析您的 ECC 系統，報告影響您的簡化項目、附加元件相容性、客製程式碼影響、資料量與 HANA 容量規劃。請及早執行，因為團隊經常發現一些自己都不知道在依賴的附加元件與客製程式碼。

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

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