SAP S/4HANA Migration Cockpitの使い方：手順ごとの解説

SAP S/4HANA Migration Cockpitは、マスタデータと未決済項目を新しいS/4HANAシステムにロードするためのSAPのツールで、FioriアプリMigrate Your Data（データ移行）を通じて使います。ステージングテーブルか直接転送かを選び、移行オブジェクトを選択し、値をマッピングし、シミュレーションしてからロードします。オブジェクトごとに、依存関係の順に進めます。

プログラムリーダー向けに結論を言えば、新規導入に使い、初週からワークストリームとして計画し、データのオーナーを早めに決めてください。ツールは簡単な部分です。

このガイドは、私のECCからS/4HANAへの移行ガイドを構成する記事の一つです。コックピットをインストールするだけでなく、うまく運用する必要があるプログラムリーダーとデータリーダーに向けて書いています。

コックピットは、事前定義された移行オブジェクトを使って業務データをS/4HANAに移します。各オブジェクトは、得意先、仕入先、品目、未決済項目といった1つのビジネスオブジェクトについて、ソースとターゲットの構造、そして両者の間のマッピングルールを記述したものです。

SAPはその対象範囲を明確にしています。コックピットは新規導入の初期ロード向けに設計されており、システムの同期や継続的なデータフローのためのものではありません。ブラウンフィールドのコンバージョンでは中核の移行にこれを使いません。Software Update Managerがデータをその場で変換するからです。

名称について2点押さえておくと混乱を避けられます。旧来のWeb DynproトランザクションLTMCは非推奨となり、データの移行には使えなくなりました。できるのは古いプロジェクトの表示だけです。後継はFioriアプリMigrate Your Dataで、いま「コックピット」と言えばこれを指します。

コックピットはどのエディションでも使えますが、設定と拡張の方法に違いがあります。次の表は2026年10月時点での比較です。

領域	SAP S/4HANAオンプレミスとSAP Cloud ERP Private（S/4HANA Cloud Private Edition）	SAP S/4HANA Cloud Public Edition
アプリ	Migrate Your Data	Migrate Your Data（アプリF3473）
ステージングテーブル	ローカルのS/4HANAスキーマ、またはリモートのSAP HANAスキーマ	ローカルスキーマ、またはSAP BTP上のリモートのSAP HANA Cloudスキーマ。スコープアイテム2Q2で設定
直接転送	SAP ERP（ECC 6.0以降）、SAP AFS 6.0、SAP EWM 5.1以降、SAP APO SPP（SCM 7.14以降）から	SAP ECC 6.0以降から。スコープアイテムBH3で設定
オブジェクトの変更	トランザクションLTMOM（移行オブジェクトモデラー）	ステージングにはModel Your Migration Objectsアプリ、直接転送にはImplementation Activitiesアプリ。拡張できるのはリリース済みのオブジェクトのみ
ソースシステムの制限	S/4HANAシステムはソースにできない	S/4HANA、Private Edition、Public Editionのシステムはソースにできない

すべての移行プロジェクトは、2つのアプローチのどちらかを使います。この選択がデータのワークストリーム全体を形づくるので、RealizeではなくExploreで決めてください。

ステージングテーブル。 コックピットは、プロジェクト内の移行オブジェクトごとにデータベーステーブルのセットを生成します。それをSAPのXMLテンプレートファイル、CSVファイル、またはSAP Data Servicesや他のETLツールなどの自社ツールで埋めます。ソースは何でも構いません。古いSAPシステム、Oracle、Dynamics、自社開発システム、スプレッドシートでもよいのです。

直接転送。 コックピットはRFC経由でSAPのソースシステムに接続し、自らデータを選択します。ERPのソースなら会社コード単位です。前提条件には、ソースシステムへのDMISアドオンの導入が含まれ、これはS/4HANAのライセンスに含まれています。ソースシステムは非Unicodeでも構いません。

データリーダーが下すべき判断について、両者を比べると次のようになります。

問い	ステージングテーブル	直接転送
どのソースに対応するか	ファイルやツールを通じてあらゆるシステム	サポートされるSAPのソースのみ
どこでクレンジングするか	ロード前に、ステージングテーブル内またはその上流で	主に選択前のソースシステムで
ロード前に誰がデータを確認できるか	テーブルやファイルにアクセスできる人なら誰でも	主にコックピットの画面を通じてコックピットチームが
立ち上げの工数	多い：抽出を構築し、テーブルを埋める	少ない：コックピットが選択してくれる
最適なケース	複数のソース、汚れたデータ、大がかりな変換	新しいS/4HANAの設計に移る、きれいなSAP ERPのソース

直接転送でも、選択したデータを中間保存としてステージングテーブルに置くことができ、その間に確認のポイントを設けられます。それを前提に設計する前に、自社のリリースが対応しているかを確認してください。

私が率いるチームがステージングテーブルを使う理由

私が率いるチームはコックピットを使いますが、私自身が手を動かして操作するわけではありません。チームの標準であり私の好みでもあるのは、直接転送よりステージングテーブルです。

理由はコントロールです。ステージングテーブルでは、ロードされるデータがテーブルに置かれ、S/4HANAに何かが触れる前に照会し、業務ルールと照らし合わせ、修正できます。データスチュワードは、信頼するしかない選択結果ではなく、実際に目にしたものを承認できます。

クレンジングとロードを分けられることも理由です。重複した仕入先、欠けた銀行情報、誤った数量単位は監査証跡を残して一か所で修正され、ロードそのものは繰り返し実行できるようになります。直接転送は立ち上げが速いものの、ソースシステムの習慣をそのまま新システムに持ち込みがちです。

それでも直接転送には使いどころがあります。ソースが1つのよく保守されたSAP ERPシステムで、ターゲットの設計がそれに近ければ、抽出作業を大きく省けます。

SAPは移行プロセスを決まった順序として説明しています。以下は、チームがステージングテーブルで実行する手順です。

Migration Cockpitのプロセス

1. 01

   プロジェクト作成

   Migrate Your Dataを開き、プロジェクトを作成して、対象の移行オブジェクトを選択する。

2. 02

   ステージングテーブルの充填

   テンプレートをダウンロードしてアップロードするか、自社ツールでテーブルを埋める。

3. 03

   値のマッピング

   未処理のマッピングタスク（値マッピングと固定値）を処理する。

4. 04

   シミュレーション

   ロードをシミュレーションし、何かを転記する前にすべてのエラーを修正する。

5. 05

   移行と修正

   依存関係の順にロードし、失敗したレコードを修正して照合する。

1. 移行プロジェクトを作成する。 Migrate Your Dataアプリでプロジェクトを作成し、ステージングテーブルの置き場所（ローカルまたはリモートのスキーマ）を選び、対象のオブジェクトを選択します。SAPは、まず本番環境のコピーであるテストシステムでプロジェクトを作成し、テスト転送のたびに前回の修正を引き継いだ新しいプロジェクトを作ることを推奨しています。
2. 依存関係を確認する。 移行オブジェクトには、先に処理しなければならない先行オブジェクトと、後に続く後続オブジェクトがあり得ます。Explore Migration Objectsアプリ（F8638）は、必須と任意の先行オブジェクトをグラフで表示します。未決済項目の前にビジネスパートナー、在庫の前に品目です。コックピットは順序を飛ばすことを許しません。
3. ステージングテーブルを埋める。 XMLテンプレートはSAPの標準かつ推奨のオプションです。各ファイルにそのオブジェクトのすべての構造と説明が含まれるからです。CSVは上級者向けのオプションで、構造ごとに1ファイルです。1つのXMLファイルは最大100 MBで、複数のXMLファイルをまとめたzipも100 MBを超えられません。ですから大きなオブジェクトは分割するか、テーブルに直接書き込むツールが必要です。
4. 検証メッセージを読む。 アップロード後、システムはファイルを検証し、すべてのエラーと警告をセルにひも付けたMessagesシートを追加します。警告のあるファイルは、データが次に進む前に、無視してよいかを誰かが判断する必要があります。
5. マッピングタスクを処理する。 値マッピングのタスクは、古いプラントコードを新しいものに置き換えるように、ソースの値をターゲットの値に変換します。固定値のタスクはデフォルト値を設定します。マッピングが大量なら、画面で値を入力するのではなく、マッピングテンプレートをダウンロードしてください。
6. シミュレーションする。 シミュレーションは転記せずにロードを実行し、どのインスタンスが成功しどれが失敗するかを示します。新たなマッピングタスクが発生することがあるので、それを処理して再度シミュレーションします。シミュレーションできないオブジェクトもいくつかあるため、それらには追加の確認を計画してください。
7. 移行する。 オブジェクトごとに、先行オブジェクトから順にロードを実行します。転送ステップが複数あるオブジェクトもあり、各ステップを順番にシミュレーションし移行します。
8. 修正し照合する。 必要に応じて修正ファイルを使って失敗したインスタンスを修正し、件数と財務上の合計をソースと照合します。エラーなしで終わったジョブは、データが正しいことの証明にはなりません。

直接転送も同じパターンですが、最初に1つ違いがあります。テーブルを埋める代わりに、ソースシステムに対してSelect Dataを実行します。選択範囲はモデラーでさらに絞り込めます。

遅かれ早かれ、移行オブジェクトがうまく合わない場面が来ます。ソース側のカスタム項目、取り込み時に必要な分割、あるいはSAPが提供していないオブジェクトです。

オンプレミスとプライベートエディションでは、使うツールはトランザクションLTMOM、つまりSAP S/4HANA移行オブジェクトモデラーです。チームは標準オブジェクトを拡張し、項目を追加し、カスタムオブジェクトを定義し、システム間での移行コンテンツの移送を管理できます。専用の開発者ロールが必要なので、誰がそれを持つかを計画してください。

パブリックエディションでは選択肢が狭くなります。ステージングテーブルの場合、Model Your Migration Objectsアプリで拡張できるのはSAPがリリースした一部の移行オブジェクトだけで、オブジェクトごとに拡張できる内容を示すSAP Noteがあります。これはパブリックエディションのClean Coreのモデルと一貫しており、自社のデータが本当に以前と同じ形である必要があるのかを試す良い機会になります。

私の助言は、モデラーでの変更をすべてカスタムコードと同じように扱うことです。記録し、オーナーを決め、業務部門に本当に必要なのかを確かめてください。

私が見るS/4HANAプログラムでは、データ移行が工数の30から40%を占めます。コックピットはそのワークストリームの中にあるので、うまくいかないことの大半はツールの問題ではありません。

コックピットの作業が成功するかどうかは、次の5つで決まります。

1. Exploreでオブジェクトのスコープを決める。 すべての移行オブジェクトについて、ソース、件数、オーナーを一覧にします。実際の件数が分かれば、無料のデータ移行見積もりツールで説明のつく工数の幅が得られます。
2. オブジェクトごとにデータオーナーを指名する。 得意先と仕入先の財務データは財務部門、品目は購買部門が持ちます。重複した2つの仕入先のどちらが正しいかを、ITは決められません。
3. 終了基準付きでロードサイクルを計画する。 各サイクルはテストシステムでの新しいプロジェクトであり、それぞれ業務部門が承認する照合で終わります。私のSAPのデータ移行が失敗する理由のガイドには、そのまま使える模擬ロード計画があります。
4. カットオーバーの時間枠を見積もる。 1サイクルは本番と同じデータ量で実行します。ファイルの制限やロード時間は、実際の規模になって初めて見えてきます。
5. カットオーバー前にオブジェクトとマッピングを凍結する。 本番ロードは、同じプロジェクト、テンプレート、マッピングで、最終リハーサルを繰り返すものであるべきです。

S/4HANAプログラムで私が見る最大の誤りは、開始時にきちんと計画しないことです。コックピットでは、それがオブジェクト一覧の遅れ、オーナーの不在、そしてExploreで見つけるべきだった問題をRealizeの最初のロードサイクルで見つけることとして表れます。

それらのサイクルは全体の計画も形づくります。私のS/4HANA移行スケジュールのガイドではアプローチ別にロードサイクルがどこに入るかを示し、S/4HANA移行コストガイドではデータの予算を左右する要因を扱っています。

コックピットについてパートナーに尋ねるべきこと

署名する前に、パートナーにはデータへのアプローチを、売り込みの場ではなく書面で示すよう求めてください。

1. オブジェクトごとに、ステージングテーブルと直接転送のどちらを提案するのか、そしてその理由。
2. ロードサイクルを何回計画しているのか、それぞれの終了基準は何か。
3. どのオブジェクトをモデラーで変更する見込みか、その変更を誰が保守するのか。
4. 自社側で各オブジェクトを誰が、いつ承認するのか。

ここで一般論の回答が返ってきたら、警告のサインです。これを以前に手がけたパートナーなら、自社の業種で厄介なオブジェクトを名指しできます。

今月中に、得意先、仕入先、品目のマスタを完全に抽出し、レコードを数え、品質をプロファイリングしてください。そのうえで、オブジェクトごとにステージングテーブルか直接転送かを決め、オーナーを指名してください。

ソースシステムのアセスメントがまだなら、SAP Readiness Checkと移行アセスメントから始めてください。データ移行計画について独立した視点が必要でしたら、ご連絡ください。

SAP S/4HANA Migration Cockpitとは何ですか？

新しいS/4HANAシステムへの業務データの初期ロードのためのSAPのツールで、FioriアプリMigrate Your Dataを通じて実行します。マスタデータと未決済項目向けの事前定義された移行オブジェクトを使い、ステージングテーブルと、SAPのソースシステムからの直接転送という2つのアプローチに対応しています。

S/4HANAでLTMCはまだ使えますか？

データの移行には使えません。SAPはトランザクションLTMCを非推奨としており、S/4HANAへのデータ移行には使えなくなりました。古いプロジェクトの表示はまだできます。

新しい移行はMigrate Your Dataアプリで実行します。

ステージングテーブルと直接転送の違いは何ですか？

ステージングテーブルでは、コックピットが移行オブジェクトごとにテーブルを生成し、それをXMLやCSVのテンプレート、または自社ツールで、どのソースからでも埋めます。直接転送では、コックピットがSAP ERP 6.0などのサポートされるSAPのソースシステムから、RFC接続で直接データを読み取ります。ステージングテーブルのほうが、ロード前に確認しクレンジングする余地が大きくなります。

Migration Cockpitはブラウンフィールドのコンバージョンに使えますか？

中核の移行には使えません。SAPはコックピットを新規導入シナリオでの初期ロード向けに設計しています。ブラウンフィールドのシステムコンバージョンでは、Software Update Managerがデータをその場で変換します。

SAPのLTMOMとは何ですか？

LTMOMは、オンプレミスとプライベートエディションで使うSAP S/4HANA移行オブジェクトモデラーのトランザクションです。標準の移行オブジェクトの拡張、カスタム項目の追加、独自オブジェクトの作成、移行コンテンツの移送ができます。パブリックエディションでは、Model Your Migration Objectsアプリが同じ仕事をより狭い範囲で担います。

S/4HANA Migration Cockpitのファイルサイズの上限はいくつですか？

1つのXMLテンプレートファイルは最大100 MBで、複数のXMLファイルをまとめたzipも100 MBを超えられません。zip内のファイルは圧縮後であればより大きくでき、ファイルごとの上限はエディションとリリースによって異なります。

CSVのフォルダも100 MBまでに制限されています。非常に大きなオブジェクトは、ファイルではなくツールでステージングテーブルを埋めてください。