SAP
SAPデータ移行手法の選び方:DMCとLTMCを実務で使い分ける
SAP S/4HANAへのデータ移行で、Migration Cockpit(DMC)とLTMCをどのような基準で選ぶかを整理します。移行対象、データ準備、接続方式、テスト、切替判定まで実務の判断手順を解説します。
SAP S/4HANAへの移行では、業務データをどの方式で取り込むかが後続工程の品質と切替時間を左右します。候補として検討されるのが、SAP S/4HANAのMigration Cockpitを中心としたDMCと、移行プロジェクトで利用されてきたLTMCです。
両者は単純な機能比較だけで決めるものではありません。対象リリース、移行対象オブジェクト、ソースシステムとの接続、データ量、変換要件、反復テストの回数を整理し、プロジェクトの実行条件に合う方式を選びます。本稿では、選定からリハーサル、エラー分析、カットオーバーまでの進め方を説明します。
DMCとLTMCの位置付け
DMCは、SAP S/4HANAのMigration Cockpitを使って移行対象を選び、移行プロジェクトを作成し、テンプレートまたは接続方式でデータを取り込む考え方です。対象オブジェクトごとに、項目、必須値、変換ルール、依存関係を確認しながら進めます。
LTMCは、移行テンプレートを生成し、ファイルを準備してロードする方式を中心に運用します。既存のプロジェクト資産や、すでに整備されたテンプレートを活用できる場合には、作業手順を標準化しやすい方式です。
実務上は、DMCを現行のMigration Cockpitを使う移行方式の総称として扱い、LTMCを従来型のテンプレートベースの実行方式として整理すると、関係者間の会話が明確になります。最終判断では、対象のSAP S/4HANAリリースで利用できる移行オブジェクトと、プロジェクトで許可された実行方式を確認します。
最初に固定する選定条件
方式を決める前に、次の情報を移行台帳へ記録します。
- 対象会社コード、プラント、保管場所、販売組織などの組織範囲
- マスタ、残高、未消込明細、オープン受注、オープン購買伝票などの対象データ
- ソースがSAP ERPか、別のSAPシステムか、外部ファイルか
- データの抽出担当、変換担当、業務検証担当、移行実行担当
- 移行実行の回数、許容停止時間、切替日、再実行の条件
- 個人情報、金融情報、取引先情報などの保護要件
データ量だけで方式を決めると、変換や照合の作業量を見落とします。特に残高と明細では、件数の多さよりも、元システムと新システムで意味が変わる項目の確認が重要です。
対象オブジェクトを一覧化したら、前提となる業務変更を確認します。簡素化項目、ビジネスパートナへの統合、勘定設定、在庫評価、税コード、出荷・請求の設計が移行データの形を決めます。移行前の影響確認には、SAP S/4HANA移行の概要を参照できます。
DMCを選びやすいケース
Migration Cockpitの利用が適するのは、SAP S/4HANA側で提供される移行オブジェクトに沿って、対象データを段階的に登録・検証したいケースです。オブジェクト単位で作業状況を管理しやすく、業務担当者と移行担当者が同じ対象範囲を確認できます。
代表的な判断材料は次のとおりです。
- SAP S/4HANA側の標準移行オブジェクトが対象業務をカバーしている
- ファイル準備に加えて、ソースシステムとの接続方式を検討できる
- オブジェクトごとにマッピングと検証結果を管理したい
- リハーサルを複数回実施し、実行履歴を比較したい
- 標準機能を優先し、個別開発を抑えたい
DMCでは、最初にプロジェクトを作成し、対象オブジェクトを選びます。その後、項目定義を取得し、サンプルデータでマッピングを確認します。全件を一度に投入するのではなく、少量データで必須項目、コード値、組織割当、関連オブジェクトの順序を確認します。
ソースデータを直接利用できる方式では、接続ユーザー、権限、抽出範囲、ネットワーク経路、実行時間帯を事前に決めます。ファイル方式では、テンプレートの列構成、文字コード、日付形式、区切り文字、ファイル命名規則を移行台帳で固定します。
LTMCを選びやすいケース
LTMCは、ファイルテンプレートを中心とする移行手順をすでに整備しており、対象データの抽出・変換・承認をファイル単位で管理するケースで検討しやすい方式です。業務部門が表形式で値を確認し、移行チームが統合したファイルをロードする運用に向きます。
選定時には、次の項目を確認します。
- 対象リリースでLTMCを利用できること
- 既存テンプレートが現行の移行オブジェクトと整合していること
- ファイルの作成者と承認者を明確にできること
- 大量ファイルの分割、保管、再処理を管理できること
- エラー行を修正して再ロードする手順があること
LTMCを採用する場合も、テンプレートを作成した時点で完了とは扱いません。少量データのロード後に、伝票、残高、組織割当、参照関係、後続業務の結果を確認します。テンプレートの列を手作業で追加・削除せず、移行対象の定義と照合しながら管理します。
DMCとLTMCの比較軸
| 比較軸 | DMC(Migration Cockpit) | LTMC |
|---|---|---|
| 主な操作単位 | 移行プロジェクトと移行オブジェクト | 移行プロジェクトとテンプレート |
| データ準備 | テンプレート、接続方式など | テンプレート中心 |
| 適した運用 | 標準オブジェクトを反復検証する運用 | ファイル承認とロードを統制する運用 |
| 重要な確認点 | 利用可能なオブジェクト、接続、権限 | テンプレート、ファイル管理、再処理 |
| 判断の基準 | 現行リリースと標準機能への適合 | 既存資産と運用手順の継続性 |
この表は優劣を示すものではなく、プロジェクト条件を同じ観点で確認するためのものです。複数の方式を検証環境で比較し、作業時間、エラー率、再実行性、照合結果を記録すると、関係者が納得しやすい判断になります。
実行手順を標準化する
移行方式を決めたら、次の順序で実行手順を文書化します。
- 移行対象オブジェクトと前提条件を確定する
- ソース項目とSAP S/4HANA側項目のマッピングを作成する
- コード変換、単位変換、日付変換、組織変換を定義する
- サンプルデータをロードする
- アプリケーション上の登録結果を業務担当者が確認する
- エラーを分類し、データ修正と設定修正を分離する
- 全件リハーサルを実施する
- 件数、金額、残高、参照関係を照合する
- 本番切替の停止時間と実行順序を確定する
- 切替後の確認とロールバック判断を記録する
移行プロジェクトの工程全体との関係は、SAP S/4HANA移行プロジェクトのフェーズで整理できます。DMCとLTMCの選択は準備工程で完了させ、実現工程では選択した方式の再現性を高めます。
データ品質とマッピングを管理する
エラーの多くはツールの操作より、ソースデータの品質と業務ルールの未確定から発生します。次の項目を移行前に検査します。
- 必須項目の空欄
- コード値の未定義、重複、桁数超過
- 会社コード、プラント、販売組織などの組織値
- 通貨、数量単位、日付、タイムゾーン
- 取引先、品目、勘定科目などの参照先
- 有効期限、削除フラグ、重複キー
- 明細とヘッダ、残高と明細の整合性
マッピング表には、元項目、変換式、変換後項目、変換担当、業務承認者、テスト結果を記録します。変換ロジックを表計算ファイルの隠れた式だけで管理せず、仕様書とテストケースへ反映します。
SAP S/4HANAで構造や業務パートナーの扱いが変わる対象は、移行方式の選択と同時に設計します。特に取引先統合を含む場合は、SAP S/4HANAのビジネスパートナ変換と移行対象の順序を合わせます。
リハーサルと切替判定
リハーサルでは、ツールが完了したかだけでなく、業務結果が利用可能な状態になったかを判定します。最低限、次の証跡を残します。
- 移行対象件数とロード成功件数
- エラー件数、原因分類、再処理結果
- 金額、数量、残高のソース・ターゲット照合
- 伝票間の参照関係と後続処理の結果
- 実行開始・終了時刻と処理時間
- 業務担当者による受入確認
リハーサルの結果は、DMCまたはLTMCの実行ログだけに依存させません。ソース抽出ファイル、変換後ファイル、実行ログ、エラー修正履歴、照合レポートを同じ移行回の識別子で保管します。
切替判定では、許容エラー件数、未移行対象の扱い、再実行可能な範囲、業務開始前の確認項目を明文化します。移行対象が多い場合は、停止時間の短縮と実行順序を先に検証し、データ量を根拠にした作業時間を提示します。関連する考え方は、SAP S/4HANA移行のダウンタイム最小化で確認できます。
方式選定の最終チェック
最終決定前に、プロジェクト責任者、業務担当、データ担当、システム担当が同じチェックリストを確認します。
- 対象リリースで方式と移行オブジェクトを利用できる
- 対象データの抽出元と責任者が確定している
- マッピングと変換ルールが承認されている
- 標準設定と移行順序の依存関係が整理されている
- 少量ロードと全件リハーサルを実施している
- エラー分類と再処理手順が確立している
- 件数・金額・業務結果の照合方法が決まっている
- 本番切替の実行権限、停止時間、連絡経路が確定している
DMCとLTMCの選択は、名称の新しさではなく、対象リリース、移行オブジェクト、データ準備、反復テスト、切替運用の組み合わせで決まります。プロジェクト固有の条件を検証環境で再現し、測定結果をもとに方式を確定すると、本番移行での判断変更を抑えられます。