SAPのデータ移行はなぜ難しいのか？｜よくある失敗と対策

ERP（Enterprise Resource Planning）の代表格であるSAPは、世界中の大企業が基幹システムとして導入している。その一方で、導入やS/4HANAへの移行プロジェクトで最大の難関とされるのが「データ移行」である。

システム移行プロジェクトでは、業務プロセスの刷新やアドオン開発といった「システムを構築する作業」が注目されやすい。しかし、最終的に新システムを正しく稼働させるためには、マスタデータ、トランザクションデータを欠落や不整合なく移行することが不可欠だ。データ移行に失敗すれば、どんなに優れた新システムを作り上げても、使い物にならない。

SAPのデータ移行は、なぜここまで難しいのか？　理由は大きく分けて以下の三つにある。

本記事では、まずスクラッチ開発システムとSAPの違いを比較し、次にSAP固有の難しさや代表的な失敗例について解説する。さらに、移行を成功に導くために重要となる移行データの範囲の考え方を整理し、最後にデータ移行ツールの選択肢を紹介する。

本記事が、これからSAPのデータ移行に挑むすべての情報システム担当者、およびSAPプロジェクト関係者にとって、少しでも参考になれば幸いである。

スクラッチ開発システムとの比較でわかる難所

スクラッチは「テーブル直書き」「順序非依存」が可能

スクラッチ開発システムでは、データベースのテーブルが開発者にとってオープンである。データ移行の際も、SQLで直接INSERT文やUPDATE文を流し込めば基本的に成立する。もちろん、外部キーや整合性制約は存在するが、必要に応じて制約を一時的に外したり、後処理で不整合を解消したりできる柔軟性がある。

このため、スクラッチシステムの移行は「とりあえず入れて、後から修正する」というアプローチでも何とかなる場合が多い。

SAPはアプリ層経由（BAPI／IDoc／API）必須

SAPは根本思想が異なる。テーブルに直接データを書き込むことは原則として禁止されており、必ずアプリケーション層を通す必要がある。代表的な手段は以下のとおりだ。

方式	特徴	主な用途
BAPI (Business API) / RFC	業務ロジックを公開した標準API。ABAPからだけでなく外部アプリケーションからも呼び出し可能。	プログラム経由でマスタ／トランザクションデータ登録
IDoc (Intermediate Document)	EDIのようにデータを構造化してSAPに送り込む仕組み。受信時にSAPロジックを通過	EDI、外部システム連携、大量データ移行
OData API	新しいUIであるFioriやWeb環境で利用されるWeb API	外部アプリやクラウド統合
Batch Input (BDC)	RPAのようにSAP GUI操作を模倣。画面経由でデータ登録する。	トランザクション（T-Code）単位の投入

これらを通すことで、単にテーブルにデータを挿入するだけでなく、企業固有のビジネスロジック（設定された制約）を通過させ、派生データの生成や関連テーブルの更新も同時に行われる。

データを登録できる「層」の違い

SAPは「アプリケーション層」を必ず通さなければならないと書いたが、他には以下のような「層（レイヤー）」が存在する。

S/4HANAのテーブル＝データベース層に隣接するのは「データアクセス層」であり、この層では、テーブルを直接操作できるINSERT／UPDATEといったSQL文が該当する。

スクラッチ開発システムでは、開発者がこのデータアクセス層（SQL）を通じてデータベース層に直接アクセスできる構造になっている。

一方、SAPではアプリケーション層を介してしかデータベースにアクセスできない設計となっているため、データアクセス層は事実上存在しないといえる。

層（概念）	スクラッチ開発システム	SAP
ユーザー層	自作の画面/UI、または外部ツール	SAP GUI、Fiori、Webサービス
アプリケーション層	任意に設計されたビジネスロジック。整合性チェックは設計者次第で弱い場合もある	ABAPアプリケーション層。BAPI、IDoc、OData APIを経由して必ず整合性チェックを実行
データアクセス層	SQLで直接DB操作可能。アプリ層をバイパスできる	アプリ層経由のみDB操作可のため事実上存在しない
データベース層	任意設計のDBスキーマ／テーブル。外部キーや制約は開発者が決める	SAP標準テーブル群（MARA, VBAK, BKPFなど数万単位）。高度に正規化＋業務ロジック依存
基盤層	任意のOS/サーバ/クラウドを選択可能	SAP NetWeaver / SAP HANA / OSに依存（特定の構成に最適化）

SAPはデータ削除できない

システム監査やガバナンスの観点から、SAPでは基本的にデータを物理削除できないようになっている（BOMなど一部の例外を除く）。

たとえば、在庫の入出庫データや入出金データを誤って移行してしまった場合、スクラッチシステムなら、SQLのDELETE文で該当レコードを消してしまえば済む。

しかし、SAPではそうはいかない。

レコードの物理削除は原則として許可されておらず、削除フラグを立てるなどの「論理削除」で対応する仕組みになっている。つまり、「なかったこと」にはできないのだ。

このように、すべての業務記録を漏れなく残すという設計思想があるからこそ、SAPは監査に強く、ガバナンス面でも圧倒的に堅牢なシステムと言える。

一方で、この強固な仕組みは試行錯誤しながらのデータ移行も許さないという、融通の効かなさも際立たせている。

システムを守るという思想

テーブル仕様がオープンでない理由

SAPの内部には、数万単位のテーブルが存在している。これらのテーブルの一部は仕様が公開されているが、業務ロジックに依存する補助テーブルや、派生データを格納する内部テーブルなど、非公開のものも非常に多い。そのため、SAPのテーブル構造は一般的に「ブラックボックス」と呼ばれている。

SAPがテーブル仕様をブラックボックス化しているのには、明確な理由がある。

もし、すべてのテーブル仕様が公開されていた場合、SQLのINSERTやUPDATEを用いて直接データベースのテーブルを操作しようとする開発者が出てくる可能性がある。

しかし、SAPの業務データは伝票（ヘッダと明細）や会計転記など、複数のテーブル間で整合性を保ちながら構築されている。これらをアプリケーション層を介さず直接書き換えると、ヘッダと明細の不整合や会計データの欠損が発生し、システム全体の整合性が崩壊する危険がある。最悪の場合、システムが正しく動作しなくなり、修復不能な状態に陥ることもある。

このようなリスクを防止するため、SAPではテーブルの直接操作を明確に禁止している。また、テーブル仕様を非公開にしているのは、開発者が誤って直接操作しないようにするためのセキュリティ的措置でもある。

さらに、SAPではすべてのデータ更新処理がアプリケーション層を通じて行われるという設計思想に基づいているため、テーブル仕様そのものを詳細に公開する必要がない、という考え方でもある。

登録順序を守らなければならない理由

SAPでは、データ登録の順序も非常に厳格だ。

たとえば「受注データ」を移行する場合、以下のデータが事前に存在しなければならない。

• 得意先マスタ（BP）
• 与信情報
• 商品マスタ（品目マスタ）
• 在庫データ
• 価格条件

これらが揃って初めて受注が登録できる。順序を間違えればエラーが発生し、登録できない。スクラッチでは回避できた「順序問題」が、SAPでは移行の最大ボトルネックになるのだ。

SAPのデータはテーブルの集まりではない

スクラッチシステムではデータは「テーブルの集まり」として捉えるが、SAPシステムに対してこの思想で臨むと手痛いしっぺ返しを喰らうことになる。

SAPのデータ構造は、「単なるテーブル群」ではなく「ビジネスロジックに紐づくオブジェクト群」として理解しておく必要がある。具体的には以下のような特徴がある。

品目マスタ

品目の基本情報に加え、販売、購買、生産、在庫評価など複数のビューを持つ。どのビューを持たせるかはカスタマイジング（パラメータ設定）依存であり、画一的な「品目マスタのレイアウト」というものは存在しない。つまり、登録する製品や部品の特性によってレイアウトが変わる。テーブル風にいえば、列構造が都度変わるのだ。このため、移行時にはパターン（品目タイプ）別に仕分けしてデータを準備する必要がある。

ビジネスパートナー（BP）

いわゆる「得意先マスタ」「仕入先マスタ」である。S/4HANA以前のSAP ERPではトランザクション（登録画面）が明確に分かれていたが、S/4HANAからはBPとして一つに統合された。対象のBPが得意先か仕入先かは、「ロール」によって決定され、登録できる項目も変化する。1つのBPに複数のロールを登録できるため、データ移行時はどのロールを割り当てるのかを整理しておく必要がある。

このように、単純にデータを「コピー」するのではなく、SAP特有の依存関係を理解したうえで移行設計を行う必要がある。

よくある失敗パターンと対策

SAPシステムのデータ移行で頻発する失敗例と、その対策例をいくつか挙げる。

テーブル項目を単純にマッピングしようとする

データ移行の失敗は、往々にして設計段階から始まっている。

スクラッチ開発の経験が長い担当者ほど、SAPのデータ構造を「単なるテーブル群」として捉えがちである。レガシーシステムのテーブルを、そのままSAPのテーブルへマッピングすれば移行できると考えるのだ。

このような顧客からは、「SAPのテーブル構造を一覧で教えてほしい」といったリクエストがしばしば寄せられる。スクラッチ開発では自然な発想かもしれないが、SAPにおいてはこのアプローチは早々に行き詰まる。

確かに、一部の項目は単純にマッピングできる。しかし、SAPのテーブルには、アプリケーション動作を制御するシステム固有の項目が数多く存在する。そのため、表面上の項目マッピングだけでは成立しないケースが多い。

さらに、SAPではデータ登録時にアプリケーション層を必ず経由するという原則がある。つまり、アプリケーションの動作ロジックを無視して、テーブル項目のマッピングだけを行っても、整合性のとれたデータ移行は不可能である。

要するに、テーブル同士の単純なマッピングを目指すよりも、SAPシステムの仕組みそのものを理解することが、結果的にデータ構造理解への最短ルートとなるのである。

マスタ不整合

マスタ不整合では、以下のようなケースがデータ移行失敗の典型例だ。

品目マスタのビュー不足

品目マスタの「ビュー」が不足していると、目的の業務データを登録できない。

たとえば、受注伝票を登録しようとしても登録できない場合、その原因として「販売」ビューが品目マスタに登録されていなかった、というケースがある。

このような問題が起こる原因は、品目マスタがどの業務（この場合は「受注登録」）で使用されるのか、整理が不十分だった場合である。

数量単位の誤り

数量単位、特に品目マスタの「基本数量単位（Base Unit of Measure）」は、データ移行において特に注意を払うべき項目の一つだ。

基本数量単位は、一度登録してトランザクションデータ（発注・入出庫・在庫など）が発生すると変更が不可能になる。

たとえば、本来「g（グラム）」単位で管理すべき品目を誤って「kg（キログラム）」として登録した場合、実地棚卸では評価価格が1000倍となり、購買では本来グラム単位で発注すべき数量をキログラム単位で発注してしまう。結果として、過大なコスト発生と不適正な在庫増加という重大なトラブルを招く。

この誤りが発覚した場合、既存の発注データや入出庫データなどの全トランザクションを削除しなければならない。発注直後であれば、仕入先に発注取り消しの連絡を入れることも必要だ（もちろん、平謝りしながら）。加えて、品目マスタの基本数量単位は変更できないため、新たな品目コードを登録し直す必要がある。このように、リカバリー作業には膨大な時間と労力を要し、場合によっては業務停止リスクを伴う。

品目タイプやBPロールの誤りは、トランザクション登録時にエラーとして検知されるため、その時点で気付くことができ、リカバリーも比較的容易である。一方、基本数量単位の誤りはトランザクション登録時点ではエラーとならないため、往々にして見過ごされやすい。実際に気付くのは、後になって評価額や発注金額を参照した際、すでに影響が発生している場合である。このような特性があるため、基本数量単位の設定は特に慎重に行う必要がある。

BP（取引先マスタ／仕入先マスタ）の不整合

取引先コード体系の統一が不十分で、同じ取引先が複数コードで重複登録されていたというケース。同じ取引先が複数存在するため売掛金・買掛金の残高が正しく突合できず、会計（FI）との照合エラーが多発する。

番号範囲の誤り

取引先コードや伝票番号の番号範囲が旧システムと一致せず、データ登録時に「番号範囲エラー」となり、データ登録ができないケース。

番号範囲の設定はカスタマイジング項目ではあるが、「移送による設定が効かない」場合が多く、移行先のクライアントを直接設定する必要がある。

また、番号範囲の設定を忘れた状態で、その番号範囲内にデータが登録されると、番号範囲の設定変更はできない。そうなると、修正はクライアント（システム環境）を一から再構築する以外になく、移行期間が大幅に延びてしまう。

大量データによるパフォーマンス問題

一括アップロードを行う際、データ件数が多いと予想していたデータ登録時間をオーバーする。結果、データ移行が予定の期間内に完了せず、システムのカットオーバーが延期となる。

スクラッチのテーブル直書きの場合、数十万～数百万件のデータでも登録は数分で完了することが多い。この感覚に慣れていると、SAPシステムのデータ登録にかかる時間は驚くほど長く感じる。データの種類にもよるが、数時間どころか、下手をすれば数日かかることも珍しくない。

どこまでを移行するか｜過去データや仕掛データの扱い

データ移行プロジェクトにおいて最初に決めるべき方針の一つが、「どこまでのデータを移行対象とするか」である。

理想を言えば「全データを移したい」と思うかもしれないが、実務的にも技術的にも、それは現実的ではない。システムの世代もデータ構造も異なる以上、全件移行を試みれば、コスト・工期・品質のいずれも破綻する。

したがって、データ移行計画では「過去データ」と「仕掛データ」を明確に切り分け、移行対象を絞ることが重要である。

過去データは移行対象外とすべき

過去データは、すでに完結した取引や会計処理に関する履歴情報である。これらをS/4HANAに移す意義は極めて薄い。理由は以下の三点に整理できる。

1. システム構造が異なるため、完全移行は不可能

レガシーシステム（独自システム）とS/4HANAでは、データ構造そのものが異なる。
まったくデータモデルが異なるデータを、新システム上に正確に再現することは不可能である。不可能なことに、時間とコストをかけるのは不合理である。

2. 進行中の業務には影響しない

過去データは参照用途でしか使われず、新しい取引を行ううえで必要なデータではない。
過去データを移行したとしても、日常業務で使われることはほとんどない。したがって、移行コストを投じてまでS/4HANAに残す意味はない。

3. 参照ニーズは別の方法で満たせる

過去データを参照したい場合は、レガシーシステムを「参照専用」として一定期間残すのが現実的である。
また、データ分析やBI目的であれば、S/4HANAとは別に DWH（データウェアハウス） や データレイク を構築し、必要な履歴情報をそこに集約して可視化すればよい。DWHなら、S/4HANA本体の負荷を増やすことなく、高度な分析も可能である。

したがって、過去データは「移行しない」という選択が最も合理的である。

過去データは移行対象から除外し、S/4HANAにはあくまで「今後の運用に必要なデータ」のみを移行するのがベストプラクティスである。

仕掛データは最小限にとどめるべき

仕掛データ（ワーク・イン・プログレス）は、移行時点でまだ完結していない取引データを指す。代表的な仕掛データは以下である。

これら仕掛データも可能な限り、レガシーシステム上で取引（トランザクション）を完結させ、取引結果としての在庫数や金額データをS/4HANAに登録するのが、最もリスクが少ない。

移行する場合、発注残・受注残 は比較的移行が容易である。レガシーシステムの残データを抽出し、S/4HANAに再登録すればよい。たとえば受注残なら、S/4HANAのSDモジュールに「受注伝票」として登録すれば、業務継続に支障はない。発注残も然りだ。

一方で、最も扱いが難しいのが 製造仕掛データ（生産中の製造指図） である。

製造仕掛データの移行が”超困難”な理由

製造指図（Production Order）は、工程進捗・原価計算・資材消費・出来高報告 など、多数のテーブルにまたがる複雑なトランザクションで構成されている。このデータを途中状態のまま新システムに持ち込むことが難しい理由は以下の通りだ。

1. 進捗ステータスが途中状態で多層的に存在する

製造プロセスは「仕掛」「検査中」「完了」「入庫」など複数のステータスがあり、どの段階のデータをどこまで移行するかを一律に定義できない。

2. 原価計算と仕掛管理が会計統合されている

S/4HANAでは、製造原価と会計がユニバーサルジャーナル（ACDOCA）で統合されているため、途中状態の原価要素を再現するには、会計仕訳を伴う多数の関連テーブルを再構築しなければならない。

3. 在庫・購買・生産の依存関係が強く、整合チェックが厳格

S/4HANAの製造指図は、在庫数量、部品・外注の購買発注、入出庫、原価計算など複数のデータ要素と密接に連動しており、仕掛中の移行はこれらのデータと整合が取れなくなるリスクが高い。結果として、新システムで伝票登録や照会がエラーとなるケースが多発する。

4. 業務的にも「引継ぎの瞬間」が不明確になりやすい

旧システムで製造中の品目を、どの時点で新システムに切り替えるかを誤ると、同一製品が二重管理される恐れがある。

製造仕掛データの推奨移行方針

製造仕掛データについては、以下のような「状態別対応」が推奨される。

製造指図の状態	推奨対応	理由
製造中（作業進行中）	レガシーシステムで完結させ、データ移行の対象外とする。 完成後、在庫データとしてS/4HANAへ登録する。	進捗・原価・在庫を途中状態で持ち込むと整合性を崩すため。
製造前（指図未着手）	S/4HANA側で再登録し、新システムで製造実行する。	新システムの通常業務プロセスで処理できる。
完了済（仕掛清算済み）	移行対象外。過去データとして扱い、参照のみ。	会計的に完結しており、再現不要。

この方式により、整合性を保ちつつ移行リスクを最小化できる。特に製造業では「仕掛の途中移行」は多くの障害を招くため、敢えて切り捨てる勇気が求められる。

データ移行ツールの選択肢と特徴

データ移行では「どの手段を使うか」も重要な検討ポイントである。適切な手段とツールを選択しなければ、データ登録が正しく行えないだけでなく、作業時間やコストを浪費しかねない。

たとえば、RPA（Robotic Process Automation）は、SAPの入力画面（アプリケーション層）をロボットが自動操作することで、手入力と同じ手順でデータを登録する仕組みである。この方法では、アプリケーション層を経由するため整合性の高い安全な方法である一方、入力操作を1件ずつ模倣する必要があるため、処理に時間がかかる。そのため、大量データの一括登録には不向きである。

以下では、SAPにおける代表的なデータ移行ツールを紹介する。SAP標準ツールと、サードベンダが提供するツールの両面から整理しておく。

SAP標準ツール

ツール	特徴	S/4HANAでの推奨度
SAP S/4HANA Migration Cockpit	S/4HANA移行専用に提供される公式ツール。事前定義された移行オブジェクト（顧客、仕入先、品目、会計など）が多数用意されている。GUIまたはExcelテンプレート経由でデータ投入が可能。LTMOM（Migration Object Modeler）を使えば、標準オブジェクトの拡張やカスタムオブジェクトへの対応もできる。	推奨。S/4HANA移行の第一選択肢
BAPI / IDoc / OData API	SAPアプリケーション層の正式なインターフェース。BAPIは汎用API、IDocはデータ交換用のEDI形式、OData APIはクラウドやWebサービス連携に適する。移行時は、これらを直接呼び出すか、ETLツールやスクリプト経由で利用する。整合性を担保でき、S/4HANA以降でも長期的に利用可能。	推奨。標準インターフェースのため長期利用可
Batch Input（BDC）	SAP GUI操作を模倣してデータを投入する古典的方式。内部的にはアプリ層を経由するが、処理速度が遅く、GUI依存のためバージョン変更に弱い。一部のトランザクションでBAPIが存在しない場合に利用される。	限定的に利用可能。基本的には代替手段を推奨
LSMW（Legacy System Migration Workbench）	ECC時代の代表的な移行ツール。マッピング設定や変換ルールをGUIで定義し、BDCやBAPIを通してデータ登録する。しかし、S/4HANAの新データモデル（BP統合、ユニバーサルジャーナル等）には非対応。SAP自身が「S/4HANAでは非推奨」と明言しており、今後の拡張予定もない。	一応動作はするが、非推奨。新規利用は避けるべき
SAP Data Services（BODS）	SAP公式のETLツール。データ抽出・変換・クレンジング機能に優れ、大規模移行に向く。他システム（非SAP）とのデータ統合も可能。学習コストや導入コストが高いため、中規模以上のプロジェクト向け。	大規模・複雑移行では有効

サードベンダーツール

SAP標準のデータ移行ツールは、S/4HANAへのデータ登録に特化している。

一方、サードベンダが提供するツールは、異種システムとのデータ連携に対応していたり、データクレンジング（移行前のデータ整備）機能を備えていたりと、標準ツールにはない機能を持っている。また、Excelをフロントエンドとして利用できるツールもあり、ユーザーが直接データを操作できる手軽さを重視している点も特徴である。

ツール	特徴	適用シナリオ
Informatica	世界的に利用されるETLプラットフォーム。豊富なコネクタによりSAP以外の多様なシステムからデータを統合可能。変換ルールやクレンジング機能が強力で、大規模なデータ移行に適する。	グローバルプロジェクト、多数のソースシステム統合
Talend	オープンソース発祥のETL。柔軟なカスタマイズ性が高く、開発者にとって扱いやすい。クラウドネイティブ対応も強化されており、コストを抑えたい場合に有効。	中規模移行、クラウド併用環境
Boomi	iPaaS（Integration Platform as a Service）型。クラウドSaaSや外部サービスとの連携に強みを持つ。オンプレSAPとクラウドアプリを組み合わせるシナリオで効果的。	クラウド中心の基盤、ハイブリッド環境
Syniti	データ移行・マスターデータ管理に特化したソリューション。移行プロジェクト用に品質チェックやマッピング再利用機能を提供。監査証跡やガバナンス強化が求められる大規模移行に適する。	ガバナンス重視の大規模移行、長期的MDM連携
ユアソフト（YourSoft リアルモデル Excel連携ツール）	Excelフォーマットを基盤にデータ入力・変換を行い、SAPに登録可能。BAPI/トランザクション呼び出し両対応。業務部門主体で移行作業を進められる強みがあるが、大規模データには不向き。	小〜中規模移行、業務部門が主導する移行
MALSY（マルシー, 三菱電機インフォメーションシステムズ）	ExcelをフロントエンドとするSAPデータ登録ツール。バッチインプット方式とBAPI呼び出し方式の両方をサポート。移行時だけでなく、運用時のマスタやトランデータ登録にも活用可能。導入事例では移行コスト85％削減の効果も報告されている。	中規模移行、Excel操作に慣れた業務部門を巻き込むシナリオ

まとめ｜難しいSAPのデータ移行に挑むには

SAPのデータ移行は「難しい」。その理由は、スクラッチ開発との比較で明らかなように、テーブル直書きができず、複雑な依存関係と厳格な整合性を求められるからである。

しかし、難しさの本質を理解し、適切な移行ツールを選び、ベストプラクティスに基づいて計画・実行すれば成功は可能だ。

これからSAPのデータ移行に臨む情報システム部門の担当者、特に、スクラッチ開発の経験が長い担当者ほど、SAPのデータ構造を「単なるテーブル群」として捉えることなく、「ビジネスロジックに紐づくオブジェクト群」として理解してほしい。そして、その理解をもとに、SAPのデータ移行を確実に成功に導いてほしい。

---