はじめに：データ移行はSAPプロジェクト成功の鍵
SAP導入プロジェクトで最も失敗しやすい工程が「データ移行」です。どれだけ業務設計とSAPの設定（Customizing）が完璧でも、移行されたデータの品質が悪ければ稼働後の業務が回らず、プロジェクトは事実上の失敗となります。
なぜデータ移行が難しいのか（why so）。理由は3つあります。第一に、レガシーシステムには長年の運用で蓄積された「データの汚れ」が必ずあります。第二に、SAPは構造化された厳密なデータモデルを要求するため、レガシー側のフォーマット差分を埋める変換ロジックが膨大になります。第三に、移行作業はカットオーバーという「短期間の一発勝負」で、失敗時のロールバックが極めて困難です。
ではどうすべきか（so what）。データ移行の成否は「ツールの選定」よりも「準備の徹底」で決まります。本記事では、移行戦略の立て方・対象データの整理・ツールの使い分け・データクレンジング・リハーサル設計・カットオーバーまで、現場でつまずきやすいポイントを体系的に整理します。
S/4HANA Cloud導入の実例で「データ移行が4ヶ月かかった」事例については大手製造業のS/4HANA Cloud導入事例も参考にしてください。
データ移行の全体プロセス
データ移行は単発の作業ではなく、プロジェクト初期から稼働後まで継続するワークストリームです。SAP Activate方法論における各フェーズでの活動を整理します。
flowchart LR P1["Prepare
移行戦略策定
対象データ棚卸し"] --> P2["Explore
マッピング設計
クレンジング"] --> P3["Realize
変換プログラム
リハーサル"] --> P4["Deploy
本番移行
検証"] P4 --> P5["Run
残課題対応
後続データ移行"]
ポイントは、データ移行を「Realize工程の終盤に始める作業」と捉えると失敗します。Prepare段階から並行で着手するのが鉄則です。
STEP 1：移行対象データの棚卸し
最初の工程は「何を、いつ、どこから移行するか」を明確にすることです。
移行データの分類
| 分類 | 例 | 移行タイミング | 留意点 |
|---|---|---|---|
| マスタデータ | 得意先、仕入先、品目、勘定科目、組織単位 | カットオーバー前 | 移行の主軸。クレンジングが最重要 |
| オープン残高（半端データ） | 未消込の発注、未出荷の受注、未払請求書 | カットオーバー直前 | 業務継続のために必須 |
| 期末残高 | 在庫残高、勘定残高、未決済債権/債務 | カットオーバー時点 | 会計監査要件で完全性が必要 |
| 過去トランザクション | 過去3年分の伝票履歴 | カットオーバー後（任意） | 必須ではない。アーカイブ参照で十分なケースが多い |
移行スコープの判断基準
「過去データをどこまで移行するか」が悩ましい論点です。判断基準は次の通りです。
- 法令保管要件：日本の場合は会計帳簿類は7年保存が必要だが、レガシー側でアーカイブ参照できるなら移行不要
- 業務上の参照頻度：月1回未満しか参照しないデータは移行不要
- データボリューム：移行データ量の増大は移行時間とリスクを比例増加させる
実務では、マスタ＋オープン残高＋期末残高に絞り、過去トランザクションは移行しない方針が一般的です。
STEP 2：データクレンジング
データ移行で最も時間がかかり、最も重要な工程です。
よくあるデータ品質の問題
| 問題 | 具体例 | 対処方針 |
|---|---|---|
| 重複データ | 「(株)ABC」「ABC株式会社」「ABC（株）」が別レコードで登録 | 名寄せルールを定義し統合 |
| 必須項目の空白 | 仕入先の住所欄が空、得意先の与信枠が未設定 | 業務オーナーに補完依頼 |
| 表記ゆれ | カナ全半角、長音符の有無、商品名の表記バリエーション | 表記統一ルールを策定 |
| 廃止済みデータ | 取引終了した仕入先がActive状態のまま | クレンジング時に明示的に廃止フラグ |
| 不正な参照 | 削除された組織コードを参照する伝票 | 移行対象から除外 or 暫定組織で吸収 |
| 値域違反 | 想定外の文字コードや桁あふれ | 値域チェックで弾き、業務側で修正 |
クレンジングの進め方
flowchart LR E["① データ抽出
レガシーから
CSV出力"] --> A["② 分析
重複・欠損
の検出"] --> R["③ ルール定義
名寄せ
表記統一"] --> C["④ 業務確認
業務オーナー
がレビュー"] --> F["⑤ クレンジング
適用"] --> V["⑥ 再検証
残存問題
を洗い出し"]
重要原則：業務オーナーがクレンジングの最終判断者
クレンジングを「ITの作業」と切り離してはいけません。「この仕入先は廃止していいか」「この品目は統合していいか」は業務側の判断であり、ITはツールと変換ロジックを提供する役割です。業務オーナーが当事者意識を持たないクレンジングは、稼働後に「移行漏れ」として噴き出します。
STEP 3：移行ツールの選択
SAPへのデータ移行ツールには複数の選択肢があり、用途に応じて使い分けます。
主要ツール比較
| ツール | 特徴 | 適した用途 | 学習コスト |
|---|---|---|---|
| LSMW（Legacy System Migration Workbench） | SAP標準・無料・GUIベース | ECC時代の定番。マスタ・伝票の少量〜中量移行 | 中 |
| LTMC / LTMOM（Migration Cockpit） | S/4HANA時代の標準ツール。XMLテンプレート方式 | S/4HANAへの移行で第一選択肢 | 低〜中 |
| BAPI / RFC | プログラム呼び出し型。ABAPで実装 | 大量データ、複雑な変換、エラーハンドリングが必要なケース | 高 |
| IDoc | 非同期メッセージ形式 | EDI連携を兼ねた初期ロード、外部システムとの並行運用 | 高 |
| ETLツール（SAP Data Services / BODS） | 大規模変換処理に強い | 複雑な変換ロジック、複数ソースの統合 | 高（追加ライセンス必要） |
| 直接INSERT | 非推奨 | 業務トランザクションをバイパスするため絶対に使わない | — |
S/4HANA Cloud / On-Premise どちらでも：LTMCが第一選択
S/4HANA時代の主流はLTMC（Migration Cockpit）です。Public Edition / Private Editionどちらでも提供され、移行オブジェクト（Customer、Material、Vendorなど）ごとにXMLテンプレートが用意されています。テンプレートの項目を埋めて投入すれば、SAP標準のバリデーションとビジネスロジックを通じて正規ルートでデータが登録されます。
LSMWはECC時代のレガシーで、S/4HANAでも使えますが、新規プロジェクトでLTMCを使えるならLSMWを選ぶ理由はほぼありません。
BAPIを選ぶケース
LTMCのテンプレートに収まらない複雑な変換、または極端な大量データ（数千万件以上）の場合はBAPIをABAPで呼び出すカスタムプログラムを組みます。BAPIは個別の業務トランザクションを実行する関数モジュールで、SAP標準ロジックを通すため、データ整合性が保証されます。
STEP 4：マッピング設計
レガシーのデータ項目をSAPの項目に対応付ける作業です。マッピング設計の品質がそのまま移行品質を決めます。
マッピングシートの基本構成
| レガシー項目 | レガシー値の例 | SAP項目 | SAP値の例 | 変換ルール |
|---|---|---|---|---|
| 取引先コード | “C0001” | KNA1-KUNNR | “0000100001” | 先頭3桁を削除し10桁ゼロ埋め |
| 取引先区分 | “1=得意先, 2=仕入先” | KNA1-KTOKD | “Z001” / “Z002” | レガシー値→SAP勘定グループの変換テーブル |
| 通貨コード | “￥” | KNA1-WAERS | “JPY” | ISO 4217標準コードに変換 |
| 与信限度 | レガシーには無し | KNVV-KLIMK | “10000000” | 業務オーナーが新規設定（与信限度参照） |
マッピング設計の原則
- 1対1マッピングを目指す：複雑な分岐ロジックは保守困難になる
- 不明な値は業務側にフィードバック：「この値はどう変換すべきか分からない」を曖昧にしない
- マッピングシートは1つの「契約書」：業務・IT双方の合意文書として管理する
STEP 5：移行リハーサル
本番移行前に必ず複数回のリハーサルを実施します。
リハーサルの3ラウンド構成
| ラウンド | 目的 | 対象データ |
|---|---|---|
| Mock Cutover 1 | 手順の確認、明らかなエラーの除去 | サンプルデータ（実データの10%程度） |
| Mock Cutover 2 | フルボリュームでの所要時間計測、全エラー対処 | 実データ全量 |
| Mock Cutover 3（Final Rehearsal） | 本番想定の手順・タイミング・人員配置 | 実データ全量＋本番想定の前後業務処理 |
リハーサルで計測すべき指標
- 移行所要時間（オブジェクト別）：これがカットオーバー計画のベースになる
- エラー率と原因分類：データ起因かツール起因かを区別
- ロールバック手順の所要時間：万一の戻し時間を把握
- 検証作業の所要時間：データチェックも含めて完了する時間
STEP 6：カットオーバー計画
カットオーバーは本番切り替えのことで、レガシーを止めてSAPを稼働させる、プロジェクト最大の山場です。
典型的なカットオーバー期間
flowchart LR D-3["D-3
レガシー停止
マスタ最終出力"] --> D-2["D-2
マスタ移行
残高出力"] D-2 --> D-1["D-1
残高・オープン
移行・検証"] --> D0["D-Day
業務開始
初日サポート"] D0 --> D1["D+1〜7
稼働後監視
緊急対応"]
カットオーバー成功のコツ
- 計画は分単位まで詳細化：「11:00 マスタ移行ジョブ起動、12:30 完了確認」レベルで作る
- ロールバック判断基準を事前合意：「どのレベルのエラーが出たら切り戻すか」を明文化
- 連絡・意思決定経路の単純化：問題発生時に判断を仰ぐ相手を絞る
- 休日・夜間活用：業務影響を最小化するため、土日や祝日連休を選ぶ
- 緊急対応チーム待機：D-DayからD+3までは即応できる体制
データ移行のよくある失敗パターン
失敗1：データクレンジングを後回しにする
「移行ツールでなんとかなる」という発想は禁物です。クレンジングはデータ品質の問題であり、ツールの問題ではありません。対策：プロジェクトキックオフ直後からデータ担当を任命し、Explore段階で着手する。
失敗2：移行対象の見積もりが甘い
「品目マスタは1万件くらい」と聞いていたら、実際は重複込みで3万件あった、というのが典型例。対策：プロジェクト早期に実データのサンプル抽出を行い、想定外を炙り出す。
失敗3：データ検証が不十分
「移行完了＝正しい」ではありません。対策：件数チェック・残高合計突合・サンプル目視検証の3層検証を必ず実施。
失敗4：マッピングルールの曖昧さ
「不明な場合はそのまま」のような曖昧なルールが残ると、稼働後に必ず問題化します。対策：マッピングシートを業務オーナーがレビュー・サインオフする運用にする。
失敗5：リハーサル不足
「時間がないから1回だけ」という妥協が、本番事故に直結します。対策：プロジェクト計画段階でリハーサル3回を必須スケジュールに組み込む。
失敗6：稼働後フォロー体制の不足
カットオーバーで終わりではなく、稼働後1〜2週間が最大のリスク期間です。対策：データ移行チームを稼働後2週間まで継続体制にし、データ起因のトラブル対応にあたる。
データ移行成功のチェックリスト
プロジェクト各段階で確認すべきポイントを整理します。
Prepare（移行戦略確定時）
- 移行対象データの分類と量を文書化した
- 過去トランザクションの移行方針を決定した
- 移行ツール（LTMC / BAPI / IDoc等）の選定理由が明確
- 移行体制（業務オーナー・IT・SAPコンサルの責任分担）が確定
Explore（マッピング設計完了時）
- 全マスタオブジェクトのマッピングシートが完成
- 業務オーナーがマッピングシートをレビュー・承認
- データクレンジングが概ね完了（残課題リスト化）
- 名寄せ・表記統一ルールが文書化
Realize（リハーサル前）
- 変換プログラム / 移行プログラムの単体テスト完了
- サンプルデータでの試験移行で正常終了を確認
- 検証方法（件数・残高・サンプル）が定義済み
Realize（カットオーバー前）
- Mock Cutoverを3回以上実施
- フルボリュームでの所要時間が確定
- エラーパターンと対処方法が文書化
- ロールバック計画が文書化・承認済み
Deploy（カットオーバー時）
- 分単位のカットオーバー計画を全員と共有
- 緊急対応チームと連絡経路が確立
- データ検証基準（件数・金額・サンプル）が明文化
よくある疑問（FAQ）
Q1. LSMWとLTMCはどちらを学ぶべきですか？
A. S/4HANAプロジェクトを前提にするならLTMCを優先してください。LSMWはECC時代の標準でしたが、S/4HANAではLTMCが第一選択肢です。ただしオンプレミスの既存システムや過渡期のプロジェクトではLSMWに遭遇するため、両方の概念を理解しておくのが安全です。
Q2. マスタデータ件数はどれくらいまでLTMCで処理できますか？
A. 経験則として数十万件までならLTMCで十分です。それ以上の規模（数百万〜数千万件）になるとパフォーマンス・エラーハンドリングの観点でBAPIベースのカスタムプログラムが必要になります。
Q3. データ移行で必須となる技術スキルは？
A. ABAPの読解能力、SQLでのデータ抽出・分析、Excel関数の高度な活用が3大基本です。加えてSAP側のデータモデル（品目タイプ、勘定グループ、評価エリア等）の理解が必須です。
Q4. 移行データは元のシステムに戻せますか？
A. 一方向です。SAP側に取り込んだ後、レガシーに戻す逆変換は通常行いません。ロールバックが必要な場合は「カットオーバー全体を巻き戻す」という重い判断になります。だからこそリハーサルとカットオーバー計画が重要です。
Q5. 並行運用（レガシーとSAPを一時期両方動かす）は可能ですか？
A. 技術的には可能ですが、推奨されません。理由は「同じ業務を2回入力する負担」「データの不整合」「業務担当者の混乱」が発生するためです。やむを得ない場合は、移行範囲を絞った段階移行（部門別 or 機能別）を検討してください。
Q6. データ移行の失敗で稼働延期になることはどれくらいありますか？
A. 体感では中規模以上のSAPプロジェクトの3〜4割でデータ移行起因の延期またはトラブルが発生します。逆に言えば、データ移行を真摯に準備したプロジェクトは大きな差別化要因となります。
Q7. クラウドからオンプレミスへの逆移行はできますか？
A. 技術的には可能ですが、SAPの推奨方向ではありません。S/4HANA Cloudは「Cloud-First」を前提にしており、Public Editionからオンプレミスへの逆移行は手作業に近い変換が必要です。基本的にはCloudから始めたら継続する前提で計画してください。
まとめ
- データ移行の成否は「ツールの選定」より「準備の徹底」で決まり、プロジェクト初期から並行で着手するのが鉄則
- 移行対象は「マスタ＋オープン残高＋期末残高」に絞り、過去トランザクションは原則移行しない
- データクレンジングは業務オーナーが最終判断者、ITは変換ロジックとツールを提供する役割
- ツール選定はS/4HANA時代ならLTMCが第一選択。大量・複雑な移行ではBAPI、EDI連携を兼ねるならIDoc
- マッピングシートは業務とITの「契約書」として、レビュー・承認運用にする
- リハーサルは最低3ラウンド（手順確認・フルボリューム・本番想定）を必須化
- カットオーバーは分単位の詳細計画とロールバック判断基準の事前合意が成功の前提
- よくある失敗は「クレンジング後回し」「見積甘さ」「検証不足」「マッピング曖昧」「リハーサル不足」の5つ
データ移行は「準備9割」です。プロジェクト初期からデータ担当者を巻き込み、早めにデータクレンジングに着手することが、スムーズなSAP導入の近道です。
実例として、S/4HANA Cloudで8ヶ月の短期導入を成功させた事例については大手製造業のS/4HANA Cloud導入事例、SAP導入方法論の全体像についてはSAP Activate方法論、移行後の運用基盤についてはABAP Cloud入門もあわせてご覧ください。
データ移行の全体感をつかむには、S/4HANAの仕組み全体を先に理解しておくのが効率的です。約2時間の動画で主要機能と特徴を一通り押さえられます。