SAP移行とは？ECCからS/4HANAへの移行方式・注意点を徹底解説

SAP移行は、新たにSAPを導入するプロジェクトとは異なり、既存のSAP ERPや他社基幹システム、そこで動いているアドオン・データ・インターフェースをどのようにS/4HANAやクラウド環境へ持ち替えるかを設計する取り組みです。本記事では、Greenfield／Brownfield／Selectiveといった代表的な移行パターンの違いと向き・不向き、移行プロジェクト特有の論点（アドオン棚卸し、データ移行、カットオーバーなど）、検討の初期段階で押さえるべきポイントを整理し、自社にとって現実的なSAP移行シナリオを描くための視点を解説します。

SAP移行と新規導入との大きな違い

ここでいう「SAP移行」とは、既に稼働している基幹システム（SAP ERP/ECCや他社ERP、オンプレ独自システムなど）を、SAP S/4HANAやクラウド環境へ移し替えることを指します。
ゼロからSAPを入れる「新規導入」とは、考えるべき前提が大きく異なります。

新規導入は、「どのプロセスをどのように標準化するか」を白紙に近い状態から設計できます。一方、移行は次のような制約や前提を抱えたプロジェクトになります。

• 既存業務フロー・アドオン・インターフェース資産をどこまで活かすか
• 過去データをどの粒度・どこまで遡って持ち込むか
• 稼働中システムを止められる時間（ダウンタイム）に制約がある
• グループ会社・海外拠点など、複数システム／インスタンスの統合が絡むことが多い

つまりSAP移行は、ゼロベースで設計し直すプロジェクトというより、既存資産と制約条件を踏まえて最適な落としどころを探るプロジェクトです。

典型的な対象としては、

• SAP ERP（ECC） → SAP S/4HANA（オンプレ／クラウド）
• オンプレSAP → SAP S/4HANA Cloud や SAP RISE ベースのクラウド環境
• 他社ERP／自社開発基幹 → SAP S/4HANA への置き換え

などが挙げられます。

この前提を押さえたうえで、次のセクションでは、SAP移行の代表的なパターン（Greenfield／Brownfield／Selective）を整理していきます。

SAP移行の代表的なパターン（Greenfield／Brownfield／Selective）

SAP移行を検討するとき、まず整理しておきたいのが「どの移行パターンを取るか」です。
一般的には、次の3つのパターンに分類されます。

Greenfield：新環境にゼロベース導入＋必要データだけ移行

Greenfield（グリーンフィールド） は、既存システムの設定やアドオンには基本的に縛られず、新しいS/4HANA環境をゼロベースで設計・導入し、必要なマスタ・トランザクションデータだけを移行する やり方です。

• 現行業務やカスタマイズが複雑で、「一度リセットしたい」場合
• グローバル標準テンプレートや業界テンプレートに合わせて再設計したい場合
• 他社ERPやレガシー独自システムから、初めてSAPへ乗り換える場合

などに検討されることが多いパターンです。

Brownfield：既存ECCをそのままS/4HANAへコンバージョン

Brownfield（ブラウンフィールド） は、既存のSAP ERP（ECC）環境をベースに、その設定やアドオンを生かしながらS/4HANAへ「システムコンバージョン」する 方式です。

• 大枠の業務プロセスは現行の延長線で維持したい
• アドオン資産を極力活かしつつ、技術基盤だけをS/4HANAに更新したい
• 限られた期間・予算の中で、まずは「S/4HANA化」を優先したい

といったケースで候補に上がります。
その一方で、現行の課題や複雑さをどこまで持ち込むかの見極めが重要になります。

Selective：会社・業務・データを選択的に統合・再構成

Selective（セレクティブ） は、グループ内に複数のSAP／非SAPシステムが存在している場合などに、統合と再設計を同時に行う 発想のパターンです。

• 一部の会社・事業だけを先にS/4HANAへ移行したい
• グループ統合や組織再編に合わせて、システムも整理・統合したい
• 過去データを全件ではなく、期間や条件を絞って持ち込みたい

といったニーズに対し、「完全新規」か「完全コンバージョン」かの二択ではなく、残すもの／捨てるもの／まとめるものを選びながら移行する アプローチになります。

「何を残し、何を入れ替えるか」という視点で見る

3つのパターンは、技術的な方式の違いであると同時に、

• 現行の設定・アドオン・データをどこまで引き継ぐのか
• 業務プロセスをどこまで作り直すのか
• システムランドスケープ（拠点・会社・システム数）をどう整理するのか

という「何を残し、何を入れ替えるか」の違いでもあります。

次のセクションでは、それぞれのパターンのメリット・デメリットと、どのような企業・状況に向いているかをもう一歩踏み込んで解説していきます。

パターン別のメリット・デメリットと向いているケース

3つの移行パターンは、名前だけ聞いても違いがわかりにくいので、まずは「業務の変え方」と「プロジェクト負荷」という観点で大枠を比較しておきます。

パターン	業務プロセスの見直し度合い	期間・工数感	技術的リスク感	主なねらい
Greenfield	大きい（再設計前提）	中〜長期になりやすい	移行より構想の難度高め	業務刷新・標準化・テンプレ活用
Brownfield	小〜中（基本は現行踏襲）	比較的短期も狙いやすい	互換性・アドオン対応	まずはS/4HANA化・基盤更改
Selective	中〜大（領域ごとに調整）	中〜長期（設計次第）	設計の複雑さが増えやすい	統合・再編・段階的な業務刷新

以下では、それぞれ「どんなケースに向くか」をもう少し具体的に見ていきます。

Greenfieldが向いているケース

Greenfieldは、「今の業務や設定を引きずらず、これを機に設計し直したい」 企業に向きます。

• 現行ECCや他社ERPが、アドオン・ローカルルールで極端に複雑化している
• グローバルでプロセスを統一したい／本社テンプレートを作りたい
• 既存システムの制約で、本来やりたい分析・管理ができていない

といった状況では、「現行踏襲」を前提にすると、S/4HANAを入れても課題があまり解決されません。

一方で、

• Fit/Gap・業務設計にしっかり時間とリソースをかける必要がある
• 現場の業務変更インパクトが大きく、チェンジマネジメントが重要になる

という意味で、期間・コスト・社内負荷は比較的重くなりやすいパターンです。

Brownfieldが向いているケース

Brownfieldは、「現行SAPは大枠として機能しており、まずはS/4HANA対応と技術基盤更新を優先したい」 という場合に選ばれます。

• ECCの保守切れが迫っており、早期にS/4HANAへ移行したい
• 業務プロセスは大きく変えずに、まずは技術的な延命をしたい
• アドオンが多く、いきなりゼロベース設計に切り替えるのが現実的でない

といった状況では、Brownfieldによるコンバージョンが現実的な選択肢になります。

ただし、

• 既存のアドオンや設定をどこまで持ち込むか
• S/4HANAで非推奨・廃止となる機能への対応をどう整理するか

を誤ると、課題もS/4HANAに持ち込んでしまうリスクがあります。
そのためBrownfieldでも、アドオンの棚卸しと「残す／捨てる／作り替える」の判断は必須です。

Selectiveが向いているケース

Selectiveは、「システムも組織も入り組んでおり、統合と再設計を同時に進めたい」 企業に向きます。

• グループ内に複数のSAP／他社ERPが乱立しており、S/4HANAで統合したい
• M&A・事業統合・会社分割など、組織再編と並行してシステムも整理したい
• すべてを一気にやり直すのではなく、「先にこの会社・この業務だけ」など段階的に刷新したい

といったケースで、「どの会社・業務・データを新環境に持ち込むか」を選択しながら進めるアプローチです。

その一方で、

• 設計と移行シナリオが複雑になりやすく、上流設計の難度は高い
• ツール選定やPoCを含め、専門性の高いパートナーが必要になる

といった点から、プロジェクトマネジメントとアーキテクチャ設計の成熟度が求められるパターンでもあります。

自社の制約条件からパターンを絞り込む

最終的には、

• どの程度業務を変えられるか（変えたいか）
• いつまでにS/4HANA、クラウドに移行しなければならないか
• グループ統合や組織再編の予定があるか
• どこまで投資できるか、どこにリスクを取りたくないか

といった自社の制約と狙いから逆算して、Greenfield／Brownfield／Selectiveのいずれか、または組み合わせたシナリオを検討していくことになります。

次のセクションでは、アドオン・データ・カットオーバーなど、SAP導入プロジェクトとは異なりSAPの移行ならではのポイントに絞って整理していきます。

SAP移行プロジェクト特有のポイント

SAP移行は、「新規導入プロジェクト＋α」ではなく、既存資産を抱えた別種のプロジェクトとして捉えたほうが安全です。
ここでは、導入プロジェクトと比べたときの移行ならではの論点に絞って整理します。

アドオン／カスタマイズの棚卸しと「残す・捨てる・作り替える」

最も大きな違いが、既に存在するアドオンやカスタマイズの扱いです。

• どれだけあるのか（本数・規模・担当モジュール）
• いまも本当に使われているのか（利用状況・頻度）
• S/4HANA標準機能で代替できるものはないか

といった観点で、1本ずつ「残す／捨てる／標準で代替／設計し直す」を判断する作業が発生します。

ここを曖昧にしたまま進めると、

• 不要なアドオンまで新環境に持ち込んでしまう
• 後から「やはり要らなかった」となり、再改修が発生する

といったムダが増えます。移行プロジェクトでは、この棚卸しと判断プロセス自体が大きなワークになります。

データ移行の難易度（履歴データ・品質・変換）

新規導入と違い、移行では 「膨大な履歴データをどう扱うか」 が大きな論点になります。

• どの時点からのデータを新環境に持ち込むか（何年分、どの種類）
• データ品質（コード体系、マスタの重複・欠損）がどの程度整っているか
• S/4HANA側でデータモデルが変わる領域で、どのようにマッピング・変換するか

履歴を「全件持ち込む」のか、「サマリ化する」のか、「参照用に旧環境を残す」のかで、移行のボリュームもリスクも大きく変わります。
SAP移行は、データガバナンスの現状と向き合わざるを得ないプロジェクトとも言えます。

並行稼働／カットオーバーの設計

既存システムがすでに業務の中心にあるため、本番切り替え（カットオーバー）の設計も新規導入以上にシビアです。

• どのタイミングで旧システムから新システムへ切り替えるか
• どのくらいのダウンタイムならビジネス的に許容できるか
• 並行稼働期間を設けるのか、一気に切り替えるのか
• 切り替え後に不具合が出た場合の「戻し方（ロールバック）」をどう考えるか

これらは、移行方式（Greenfield／Brownfield／Selective）や業種によってベストな答えが変わり、早い段階でカットオーバー戦略を決めておくことが重要です。

S/4HANAで変わる機能・データモデルへの対応

S/4HANAでは、一部の機能やデータモデルがECCから変更されています。

• 廃止・非推奨になった機能やトランザクション
• データモデルが統合・再設計された領域（例：FI/COの一体化、マテリアル関連など）
• アドオンやレポートが前提としていたテーブル構造の変更

これらへの対応を誤ると、コンバージョン後に動かない機能やレポートが大量に出るリスクがあります。
そのため、事前の事前調査（Simplification Itemチェックなど）と、「どの仕様変更を受け入れ、どこは追加対応するか」の切り分けが、移行プロジェクト特有の大きなテーマになります。

このように、SAP移行は

• アドオン／カスタマイズの棚卸し
• データの選別と変換
• カットオーバー戦略
• S/4HANA固有の変更点対応

といった論点が前面に出るプロジェクトです。

次のセクションでは、こうした前提を踏まえて、SAP移行を検討する企業が最初に押さえておくべきステップを整理していきます。

SAP移行を検討する企業が最初にやるべきこと

SAP移行は、いきなり「どのパターンが良いか」「どのベンダーに依頼するか」から入ると議論が拡散しがちです。
まずは、自社側で最低限の前提をそろえておくことが重要です。

1. 現行システムの「健康診断」を実施する

最初の一歩は、現状を数字と事実で把握することです。

• 利用中のSAPバージョン、サポート期限
• アドオン本数・規模、利用中の拡張ポイントの数
• インターフェース数（接続している外部システム、ファイル連携含む）
• データ量（主要テーブルのレコード数／DBサイズ）とデータ品質の大まかな評価

これにより、

• Greenfieldが現実的か、Brownfieldを前提に考えるべきか
• データ移行がどの程度のボリュームと難易度になりそうか

といった移行の難易度の目安が見え始めます。

2. 業務刷新の要否とレベル感を決めておく

次に、業務をどこまで変える覚悟があるか／ないか を、経営・業務・ITの間で粗く合わせておきます。

• 今の業務やローカルルールを、どこまで見直したいのか
• グローバルで標準化したいプロセスがあるか
• 会計・販売・在庫・製造など、特に課題感が強い領域はどこか

ここで、

• 「業務刷新も含めて大きく変えたい」のか
• 「まずはS/4HANA化を優先し、業務の見直しは段階的にやりたい」のか

といった方向性が見えてくると、Greenfield／Brownfield／Selectiveの候補も自然と絞られていきます。

3. 現実的な移行パターン候補を2〜3案に絞る

上記の現状把握と業務刷新の方針を踏まえ、社内で一度、たたき台のシナリオを作っておくのがおすすめです。

例：

• 案A：主要拠点はBrownfieldで早期にS/4HANA化し、その後テンプレートを磨き込む
• 案B：本社・基幹会社はGreenfieldで再設計し、他拠点は段階的にロールイン
• 案C：グループ内の複数SAPをSelectiveで統合しつつ、業務標準化も同時に進める

この段階では粗くて構いませんが、自社なりの前提と優先順位を明文化しておくことで、ベンダー各社の提案内容も比較しやすくなります。

4. 移行プロジェクトに関わる制約条件を明文化する

最後に、SAP移行に伴う制約条件を、早い段階で言語化しておきます。

• いつまでにS/4HANA／クラウド化を完了したいか（法令・サポート・事業計画などの観点）
• 本番切り替え時に許容できるダウンタイム／システム停止時間
• 投資上限や、年間の予算枠の制約
• 他の大型プロジェクト（基盤更改、組織再編、工場建設など）とのスケジュール関係

これらを明確にしておくと、

• 「そもそもGreenfieldは期間的に無理」
• 「Brownfield単独ではグループ統合の要件が満たせない」

といった判断が早い段階ででき、現実的な移行シナリオに議論を収束させやすくなります。

ここまでの整理を社内で行ってからパートナー選定・RFP作成に進むことで、単なる「ベンダー任せの移行」ではなく、自社の狙いに沿ったSAP移行プロジェクトを設計しやすくなります。

まとめ｜自社にとって現実的なSAP移行シナリオを描くために

本記事では、SAP移行の代表的なパターン（Greenfield／Brownfield／Selective）の特徴と向き・不向き、アドオン棚卸し・データ移行・カットオーバーなど移行プロジェクト特有の論点を解説しました。SAP移行は、既存資産と制約を踏まえて最適な落としどころを設計するプロジェクトです。

まずは現行システムの健康診断と業務刷新のレベル感の共有から始め、現実的な移行シナリオを2〜3案に絞り込むことが成功への第一歩です。詳細な移行手法については、SAP公式サイトをご確認ください。