ECCからS/4HANAへの移行：アプローチ、手順、スケジュール

SAP ECCのメインストリームメンテナンスは2027年12月31日に終了します。今からおよそ15か月後です。追加料金を払えば、任意の延長メンテナンスを2030年末まで利用できます（SAP News）。複雑な移行は、本格的なテストが始まると18〜24か月に及ぶことが珍しくありません。まだアプローチを決めていない場合、期限までの本稼働はすでに難しい状況です。

この判断を担うCIOやプログラムリーダーの方には、選択肢が3つあります。グリーンフィールド、ブラウンフィールド、選択的データ移行です。どの選択肢でも、背後の作業は同じ5つのステップで進みます。まずSAP Readiness Checkを実行し、それから選んでください。

ECCからS/4HANAへの移行は、単純なアップグレードではありません。データの保持方法、トランザクションの転記方法、ユーザーの働き方が変わります。私が関わったあるプロジェクトでは、チームがECCにあった数十本のカスタムレポートをそのまま再構築しました。まだ必要なのかを、誰も確かめませんでした。後になって、その半分は一度も使われていないことが分かりました。移行は技術的には問題なく完了しました。しかし、価値は生まれませんでした。

移行の工数を左右する違いは次のとおりです。

領域	SAP ECC	SAP S/4HANA
データベース	サポート対象の任意のデータベース（Oracle、Db2、SQL Serverなど）	SAP HANAのみ
財務データモデル	FI、CO、収益性分析ごとに別々のテーブルと集計テーブル	ユニバーサルジャーナル（テーブルACDOCA）を明細の単一ソースとして利用
顧客・仕入先マスタ	顧客と仕入先のレコードが別々	ビジネスパートナが必須
ユーザーインタフェース	SAP GUI	SAP Fioriアプリ。オンプレミスとプライベートエディションではSAP GUIも引き続き利用可能
提供形態	オンプレミス	オンプレミス、プライベートエディション（RISE with SAP）、パブリックエディション（GROW with SAP）
拡張	Zプログラムと修正	クリーンコア：リリース済みAPI、オンスタックのABAP Cloud、またはSAP BTP上のサイドバイサイド
メンテナンス	EHP 6〜8は2027年末までメインストリーム、2030年末まで延長	SAPは2040年末までのメンテナンスを確約

私が関わったある顧客は、変換後にカスタムのバッチジョブが動かなくなる理由を何度も尋ねていました。ロジックがECCのテーブル構造に依存しており、S/4HANAで構造が変わっていたのです。移行自体は完了していました。それらのジョブが新しいモデルでも意味を持つのかを、誰も問い直していませんでした。

移行で動くのはデータです。本当の問いは、引き継いだ設計上の判断をどうするかです。

Decide

どの移行アプローチが自社の状況に合いますか？

レガシーが分断されていて、プロセスを再設計したい

→グリーンフィールド

プロセスは健全で、ECCは安定しており、履歴を残す必要がある

→ブラウンフィールド

複数の事業体があり、一部を再利用して選択的にデータを移したい

→ブルーフィールド

グリーンフィールド：ゼロから始める

S/4HANAの新規導入です。レガシーの設定は引き継がず、プロセスはSAPの標準に合わせて再設計し、必要なデータだけをSAP S/4HANA Migration Cockpitでロードします。

向いているのは、レガシーシステムの分断が激しくてきれいに変換できない場合や、事業側がプロセスをなぞるのではなく見直したい場合です。

注意すべきなのは、変化の負荷です。ユーザーは使い慣れたワークフローを失います。グリーンフィールドのシステムは感覚がまるで違うのに、ユーザーへの備えを怠って後悔する企業を、私は見てきました。定着化の計画をトレーニングの段階から始めるようでは、すでに遅れています。

ブラウンフィールド：システムコンバージョン

既存のECCシステムを、そのまま変換します。設定、カスタムコード、履歴はすべて引き継がれます。技術的な変換は、データベース移行オプションを備えたSoftware Update Manager（SUM）で実行します。

向いているのは、プロセスが成熟していて、コンプライアンス上トランザクション履歴が重要で、大規模な再編が進行していない場合です。

注意すべきなのは、引き継ぐ技術的負債です。変換の間に意図して整理しない限り、レガシーの複雑さはそのままついてきます。

選択的データ移行

「ブルーフィールド」として売り込まれることもあります。すべてではなく、選んだ会社コード、事業部門、期間単位のデータだけを移します。多くの場合、専用ツールと、その経験が豊富なパートナー企業が必要です。合併や事業分離でできあがったグループ企業や、長年の履歴がもう重要でない場合に向いています。

向いているのは、グリーンフィールドのようにプロセスを自由に設計しつつ、重要な部分ではブラウンフィールドのようにデータの連続性を保ちたい場合です。

取締役会がよく尋ねる観点で3つを比べると、次のようになります。

評価項目	グリーンフィールド	ブラウンフィールド	選択的移行
プロセスの再設計	SAP標準に合わせて全面的に	大半を維持	対象ごとに選択
履歴データ	引き継がない（または未決済項目と残高のみ）	すべて引き継ぐ	選んだ範囲
本稼働までの期間	長い	短い	範囲による
技術的負債	解消される	引き継がれる	移行対象の範囲では軽減
変更の影響	大きい	小さい	中程度
最適なケース	分断されたレガシー、大幅な再設計	安定して手入れされたECC	合併、事業分離、段階的な展開

移行の流れ

1. 01

   評価

   SAP Readiness Checkを実行します。カスタムコード、アドオン、インタフェースを棚卸しします。

2. 02

   データを分類

   データをホット、ウォーム、コールドに分けます。コールドデータは移さなくて構いません。

3. 03

   クレンジング

   重複、不整合、未入力の項目を解消します。計画より必ず長くかかります。

4. 04

   コードを修正

   ABAP Test Cockpitのチェックを実行します。Zコードは移植するだけでなく、減らします。

5. 05

   テストとカットオーバー

   テストを複数回実施し、少なくとも一回は本番さながらのカットオーバーのリハーサルを行います。

1. 評価と準備状況の確認

まずここから始めてください。必ずです。SAP Readiness Checkは、ECCシステムを分析し、シンプリフィケーション項目、アドオンの互換性、カスタムコード、データ量、サイジングを報告します。

驚きが出るのは、たいていアドオンとカスタムコードです。私が関わった顧客の中には、対象のカスタムオブジェクトが数百に上ったところもあります。そして、ほとんどの顧客が、使われていないコードの多さに驚きます。見つけるなら、12か月目より第2週のほうがはるかに良いのです。

同時に、技術的な前提条件も確認します。変換は、どの拡張パッケージでもSAP ERP 6.0から実行できます。システムはUnicodeである必要があり、そうでなければ2段階の変換を計画します。デュアルスタックのシステムは、先に分割が必要です。顧客マスタと仕入先マスタは、変換前にビジネスパートナへ変換しておく必要があります。最後の項目でつまずくチームが、ほかのどの項目よりも多いのです。

2. データの分析と分類

移す前にデータの量を測り、仕分けます。

1. ホット： 頻繁に使われ、稼働中の処理に必要なデータ。
2. ウォーム： ときどきアクセスされる、関連はあるが日常的ではないデータ。
3. コールド： 履歴データまたは未使用のデータで、監査のためだけに保管しているもの。

コールドデータをS/4HANAに入れる必要はありません。アーカイブしてください。この手順を飛ばすチームは、新しいシステムに不要なデータを持ち込み、移行も性能も遅くしてしまいます。

3. データクレンジングとアーカイブ

このステップは、どの計画が見込むよりも長くかかります。重複した仕入先レコード。不揃いな数量単位。入力が半分しかない顧客マスタ。こうした問題はどのECCシステムにもあり、先に誰かが直さなければ、そのままS/4HANAに移ってきます。

私が関わったある顧客は、データクレンジングとアーカイブだけで5か月を費やしました。クレンジングを飛ばすチームは、カットオーバーの最中に問題を見つけますが、そのときにはきちんと直す時間がありません。この段階をさらに掘り下げた私の記事は、SAPデータ移行が失敗する理由と、その直し方です。

4. カスタムコードの修正

ABAP Test Cockpit（ATC）のS/4HANA対応チェックを実行します。コードをSAPのシンプリフィケーション項目と照合するものです。出力を見れば、構文の修正で済むもの、機能として置き換えが必要なもの、廃止すべきものが分かります。

目標は、動くZコードではなく、Zコードそのものを減らすことです。引き継ぐカスタムオブジェクトはすべて、今後のアップグレードごとにコストを増やします。残ったものをどう分類するかは、私のクリーンコアガイドで扱っています。

5. テスト、トレーニング、カットオーバー

テストは段階を分けて行います。単体、結合、ユーザー受入テスト（UAT）、そして少なくとも一回の本番さながらのカットオーバーのリハーサルです。UATには、パワーユーザーと、たまにしか使わないユーザーの両方を入れてください。見つける問題が違います。

リハーサルは省略できません。全体の手順を通して初めて表に出る、タイミングのずれ、不足している検証、インタフェースの障害が見つかります。これを飛ばすチームは、本稼働の週末にそれらの問題に直面します。

移行計画に載っていてほしいSAPのツールは次のとおりです。

ツール	何をするか	いつ使うか
SAP Readiness Check	シンプリフィケーション項目、アドオン、カスタムコード、サイジング	アプローチを選ぶ前
ABAP Test Cockpit（ATC）	動かなくなるカスタムコードを検出	カスタムコードの修正時
SAP Signavio	文書化されたとおりではなく、実際にプロセスがどう動いているかを可視化	設計凍結の前
SAP LeanIX	アプリケーションとインタフェースをマッピング	連携設計
Software Update Manager（SUM）	技術的な変換を実行	ブラウンフィールドの変換
SAP S/4HANA Migration Cockpit	マスタデータとトランザクションデータをロード	グリーンフィールドのデータ移行

拡張パッケージ6〜8のSAP ERP 6.0では、メインストリームメンテナンスは2027年12月31日に終了します。任意の延長メンテナンスは、メンテナンス基準額に2パーセントポイントを上乗せした料金で、2030年12月31日まで利用できます。それより前の拡張パッケージは、2025年末にメインストリームメンテナンスが終了しています。

2030年より先に進める道は、ごく限られています。SAPのSAP ERP、プライベートエディション、移行オプションが、2031年から2033年までをカバーします。対象は、2030年末までにSAP HANA上のSAP ERPプライベートエディションに移した大規模システムに限られ、しかもSAPのmax success planが条件です。計画ではなく、例外として扱ってください。

期間については、複雑なシステムの全面的な移行は、本格的なテストが始まると18〜24か月以上に延びることがあります。中堅から大企業で、準備の整った変換でも12〜18か月以上が現実的です。複数の事業体にまたがる大規模なグリーンフィールドのプログラムは、24〜36か月かかることもあります。

1. 2027ECCのメインストリームメンテナンス終了12月31日、SAP ERP 6.0 EHP 6〜8の場合
2. 2028今から始めた場合の本稼働の見込み本格的なテストが始まってから18〜24か月
3. 2030延長メンテナンス終了任意で、二ポイントの割増料金
4. 2033移行オプション終了プライベートエディション、大規模システムのみ

出典: SAP News、2020年2月と2025年8月

計算は単純です。複雑なアセスメントを今日始めれば、本稼働は2028年になります。延長メンテナンスの予算を確保し、待つのではなく、その時間をデータの整理とカスタムコードの廃止に使ってください。選択肢を検証するには、私の移行アセスメントをお使いください。

ECCからS/4HANAへのグリーンフィールド移行とブラウンフィールド移行の違いは何ですか？

グリーンフィールドは新規導入です。レガシーの設定やカスタムコードは引き継がず、プロセスはSAPの標準に合わせて設計し、必要なデータだけをロードします。ブラウンフィールドは既存のECCシステムを変換し、設定、カスタムコード、履歴を保持します。速くて混乱も少ない一方、技術的負債も一緒に引き継ぎます。選択的データ移行は、その中間に位置します。

SAP ECCからS/4HANAへの移行期限はいつですか？

拡張パッケージ6〜8のSAP ERP 6.0では、メインストリームメンテナンスは2027年12月31日に終了します。任意の延長メンテナンスは、メンテナンス基準額に2パーセントポイントを上乗せした料金で、2030年12月31日まで利用できます。2031年から2033年までの移行オプションは、2030年末までにSAP HANA上のSAP ERPプライベートエディションへ移した大規模システムにのみ用意されています。

SAP Readiness Checkでは何が分かりますか？

ECCシステムを分析し、設定に影響するシンプリフィケーション項目、アドオンの互換性、カスタムコードへの影響、データ量、HANAのサイジングを報告します。早い段階で実行すると、スコープの議論が変わります。自分たちが依存していることを知らなかったアドオンやカスタムコードが、よく見つかるからです。

ECCからS/4HANAへの移行には、どのくらいの期間がかかりますか？

中堅から大企業で、準備の整った変換なら、12〜18か月以上かかることが多いです。複数の事業体にまたがる複雑なプログラムは、本格的なテストが始まると18〜24か月に延びることがあり、大規模なグリーンフィールドのプログラムは24〜36か月かかります。スケジュールが遅れる原因として最も多いのは、データクレンジングです。

ユニバーサルジャーナル（ACDOCA）とは何で、なぜ移行で重要なのですか？

ユニバーサルジャーナルは、ACDOCAという単一の明細テーブルです。ECCでは別々のテーブルに置かれていた財務会計、管理会計、収益性分析のデータを一つにまとめます。COEPや収益性分析のテーブルなど、旧構造を読み取るカスタムコードやレポートは、見直しが必要です。小さな修正で済むものもあれば、再設計が必要なものもあります。

ECCをS/4HANAに変換するための技術的な前提条件は何ですか？

変換は、どの拡張パッケージでもSAP ERP 6.0から実行できます。システムはUnicodeである必要があり、そうでない場合は2段階の方法をとります。デュアルスタックのシステムは、先に分割しなければなりません。顧客マスタと仕入先マスタは、ビジネスパートナに変換しておく必要があります。日程を確約する前に、SAP Readiness CheckとATCのカスタムコードチェックを実行してください。

ECCからの移行では、RISE with SAPとGROW with SAPのどちらを選ぶべきですか？

カスタムコードが多く、プロセスが複雑なECC顧客の大半は、RISE with SAPのS/4HANA Cloud Private Editionに移行します。既存システムの変換に対応しているためです。GROW with SAPはパブリックエディションを使います。標準プロセスとリリース済みAPIによる拡張のみで構成された新規導入で、SAPの標準を受け入れる意思のある企業に向いています。