データ移行アシスタントご利用ガイド

まず最初に: 2つのプラグインの役割
このプラグインでできること
移行前に準備するもの
移行できるもの・注意が必要なもの
全体の流れ
画面1: ステップ1でバックアップを読み込む
画面2: ステップ2で移行対象と実行条件を確認する
画面3: ステップ3でプレビュー確認と追加ファイルの指定を行う
画面4: 移行ジョブで結果・再実行・復元を確認する
よくある質問

このプラグインでできること

このプラグインは、移行先サイトでバックアップを受け取り、内容を確認し、実際に取り込むためのプラグインです。具体的には、移行元バックアップの読込み、移行対象データの選択、 連携プラグイン・テーマ依存の確認、画像・公開ファイル・app 側補助ファイルの取込み、 実行前バックアップ、メンテナンスモード切替、 移行元の登録日・更新日の保持、会員パスワード互換の確認、 移行ジョブの結果確認、再実行、そして必要に応じた移行前データの復元まで行えます。

まずは「何を読み込むか」、次に「何を移すか・どの条件で実行するか」、最後に「この内容で実行してよいか」を順番に確認していく流れです。このガイドでは、その流れを画面ごとに整理して説明します。

このガイドの画面例は、EC-CUBE 3.0.18-p7 から 4.3.1-p1 への移行デモ をもとにしています。ただし、プラグイン自体は EC-CUBE 3.x から EC-CUBE 4.3 への移行を想定して利用できます。

また、SQLite / MySQL / PostgreSQL の各データベース構成を前提に利用でき、 商品数・受注件数の多いサイトや画像ファイルが多いサイトでも移行フローを進めやすいように設計されています。連携プラグインについても、多くのプラグインデータを対象に移行可否や依存関係を確認しながら進められます。

※ テーマ移行では現在のテーマを削除せず新規テーマとして取り込むため、元に戻しやすく安心です。一方で、移行元テーマに複雑な独自カスタマイズがある場合や、移行先に導入されていないプラグインに依存するコードが含まれる場合は、意図どおりに移行できない、またはエラーになることがあります。

1. まず最初に: 2つのプラグインの役割

移行元サイトで使うもの

データ移行向けバックアップ生成プラグイン

移行に使うバックアップファイルを作成する
商品画像・公開ファイル・html/user_data をまとめる
テーマ本体とテーマ依存情報をまとめる
会員パスワード互換に必要な認証情報をバックアップへ含める
移行前に事前診断で内容を確認する

移行先サイトで使うもの

データ移行アシスタント

移行元のバックアップファイルを読み込む
移行するデータ、実行オプション、連携プラグイン、テーマ依存を確認する
画像・公開ファイル・app 側補助ファイルを取り込む
移行結果を確認し、必要なら再実行や移行前データの復元を行う

役割はシンプルです。移行元サイトでは「準備する」、移行先サイトでは「取り込む・確認する」と考えると分かりやすいです。

2. このプラグインでできること

移行前の確認

移行元バックアップの読込み
移行元サイトと移行先サイトの情報確認
移行対象データの選択
連携プラグイン状態の確認
テーマ移行とテーマ依存の要確認表示を確認
会員パスワード互換の状態確認

実行と安全対策

画像・公開ファイル・app 側補助ファイルの取込み
実行前に移行先データベースをバックアップ
実行中だけメンテナンスモードを有効化
移行元の登録日・更新日を保持するか選択
移行ジョブの確認・再実行
必要に応じた移行前データの復元

このプラグインが判断・補完してくれること

特に重要なのは、連携プラグインのデータが移せるかどうか、テーマ内で必要なプラグインが移行先で有効かどうか、そして 移行元会員パスワードをそのまま使えるかどうか を事前に確認できる点です。料金の有無ではなく、移行先にも対応するプラグインがあり、互換性や依存関係に問題がないか が判断基準になります。

データ本体・画像・テーマ・連携プラグインを分けて確認できるため、大きなデータセットでも段階的に移行を進めやすい構成です。

3. 移行前に準備するもの

必要なもの	使いどころ	補足
data_migration_backup_XXXXXX.tar.gz	ステップ1でアップロードします。	必ず必要になるメインバックアップです。テーマ archive や会員パスワード互換情報もこの中に含まれます。
assets_html_XXXXXX.tar.gz	ステップ3で指定します。	商品画像・公開ファイル・html/user_data を移したい場合に使います。EC-CUBE 3 のユーザーページ本文もこのファイルに含まれます。
assets_app_XXXXXX.tar.gz	ステップ3で指定します。	app/template/user_data などのアプリ側補助ファイルを移したい場合に使います。テーマ本体そのものはメインバックアップに同梱されます。
移行先に入れておく対応プラグイン	ステップ2の連携プラグイン確認で使います。	プラグインデータも移したい場合は、移行先にも対応プラグインを入れて有効化しておく必要があります。
最新のバックアッププラグイン	移行元サイトでバックアップを作るときに使います。	会員パスワード互換を引き継ぐには、認証情報を含められる最新のバックアッププラグインでバックアップを再作成してください。

最優先で必要なのは data_migration_backup_XXXXXX.tar.gz です。画像や公開ファイルを移したい場合は assets_html、app 側補助ファイルを移したい場合は assets_app を追加で用意します。

バックアップデータの準備

これらのファイルは、移行元サイトに導入した データ移行向けバックアップ生成プラグイン で作成します。
まずは data_migration_backup_*.tar.gz を作成し、移行先のステップ1で読み込みます。
商品画像・公開ファイル・EC-CUBE 3 のユーザーページ本文も移す場合は assets_html_*.tar.gz を一緒に準備します。
app/template/user_data など app 側補助ファイルも反映したい場合は assets_app_*.tar.gz を準備します。

現在の運用上の対象は、EC-CUBE 4.3 への移行です。移行元サイトの事前診断や移行先の案内も、EC-CUBE 4.3 への移行を前提に読めば大丈夫です。

4. 移行できるもの・注意が必要なもの

基本的に移行しやすいもの

会員データ
商品データ
カテゴリ
お知らせ
受注データ
支払・配送
税設定
メールテンプレート・履歴
システム設定データ
管理者データ
EC-CUBE 3 のユーザーページ
EC-CUBE 3 のカスタムブロック

事前に理解しておきたいこと

dtb_template は移行対象外です。移行先の既存テンプレートを使います。
dtb_plugin 本体情報やプラグインコード / Resource / 公開 assets は自動復元しません。移すのは、移行先で有効な対応プラグインに紐づく plg_* データだけです。
dtb_payment と dtb_delivery は公開状態を維持したまま移行します。移行後に設定内容を確認してください。
同じテーマコードが移行先にある場合は、既存テーマを上書きせず、ジョブID付きのテーマコードで新規作成します。切替は移行後にテンプレート設定で行います。
EC-CUBE 3 のユーザーページ本文は assets_html に含まれます。未指定の場合は移行先に仮テンプレートを作成します。
EC-CUBE 3 から generic に移すのはユーザーページとカスタムブロックです。プラグインが生成したページやレイアウトは移行先側の状態を優先します。
EC-CUBE 3 のページレイアウト編集やブロック配置は、EC-CUBE 4.3 へ 1:1 では再現しません。ユーザーページやカスタムブロックは移行後に配置確認を行ってください。
テーマ内で必要なプラグインが移行先で有効でない場合は、要確認 として詳細表示されます。必要なプラグインを移行先で有効化してから進めてください。

連携プラグインについて

移行元サイトで使っているプラグインが有料か無料かは、このプラグインの判定基準ではありません。重要なのは、移行先にも対応するプラグインがあり、ステップ2で「移行可」になるかどうかです。ここでの「移行可」は プラグインデータ（plg_*）を取り込める という意味で、プラグイン本体をバックアップから自動配置する意味ではありません。

移行可: プラグインデータも一緒に移せます。
移行可(有効化が必要): 移行先でそのプラグインを有効化してから進めます。
移行対象外: そのプラグインデータはこのプラグインでは移せません。コアデータの移行自体は進められます。

代表例としては、商品レビュー管理プラグイン、クーポンプラグイン、 ポイントプラグイン、メルマガ関連プラグイン、 会員カスタム項目系プラグイン などがあります。移行先にも対応プラグインが導入されていれば、 多くの一般的なプラグインデータを一緒に確認・移行できます。

5. 全体の流れ

移行元サイトで最新のバックアッププラグインを使ってバックアップを作成します。
data_migration_backup_XXXXXX.tar.gz を移行先サイトに用意します。
画像・公開ファイルを移す場合は assets_html_XXXXXX.tar.gz、app 側補助ファイルを移す場合は assets_app_XXXXXX.tar.gz も用意します。
移行先サイトでデータ移行アシスタントを開きます。
ステップ1でバックアップを読み込みます。アップロード完了後は自動でステップ2へ進みます。
ステップ2で、移行するデータ・実行オプション・連携プラグイン・テーマ依存・会員パスワード互換を確認します。
ステップ3でプレビューと追加ファイルを確認し、移行を実行します。
移行ジョブで結果、アセット履歴、競合ログを確認し、必要なら再実行や復元を行います。

6. 画面1: ステップ1でバックアップを読み込む

ステップ1では、移行元サイトで作成したメインバックアップ を読み込みます。

この画面でやること

data_migration_backup_XXXXXX.tar.gz を選んでアップロードする
読み込んだバックアップが、どの EC-CUBE バージョンのものかを確認する
アップロード完了後に自動でステップ2へ進む

メインバックアップファイルを選びます。
アップロードが終わると、移行元サイトの情報が読み込まれます。
ここではまず、「正しいサイトのバックアップを選んでいるか」を確認すれば十分です。

次へボタンは残っていますが、アップロードが正常完了すると自動でステップ2へ遷移します。

まだバックアップが無い場合

この画面には、移行元サイトでバックアップ生成プラグインを入れてバックアップを作る手順も表示できます。先に移行元サイトへ戻ってバックアップを作ってから、もう一度この画面に戻ってきてください。

7. 画面2: ステップ2で移行対象と実行条件を確認する

ステップ2は、どのデータをどういう条件で移すかを決める画面です。この画面で、対象データだけでなく、実行オプション、連携プラグイン、テーマ依存、会員パスワード互換まで確認します。

サイト情報

移行元サイトと移行先サイトの EC-CUBE バージョン、PHP バージョン、データベース種別が表示されます。まずは「違うバックアップを読んでいないか」をここで確認します。

移行対象データの選択

会員データ、商品データ、受注データなど、まとまりごとに移行対象を確認します。特別な理由がなければ、最初は初期選択のまま進めて問題ありません。

実行オプション

実行前バックアップ: 移行前の DB を保存し、ジョブ詳細から復元できるようにします。
メンテナンスモード: 実行中だけ移行先をメンテナンスにします。
移行元の登録日・更新日の保持: 既定値は ON です。登録日・更新日をそのまま引き継ぎます。
競合時の扱い、対象テーブルのクリア、外部キー制約の扱いもこの画面で決めます。

テーマ移行・連携プラグイン・会員パスワード互換

テーマも移したいときは有効にします。
同じテーマコードが移行先にある場合は、ジョブID付きの新規テーマとして取り込みます。
テーマ内で必要なプラグインが移行先で有効でない場合は、要確認 と 詳細を見る が表示されます。
連携プラグインが 移行可 でも、移るのは対応する plg_* データです。プラグイン本体は移行先へ事前導入しておきます。
会員パスワード互換情報がバックアップに含まれていれば、移行元のパスワードでもログインでき、初回ログイン成功時に移行先方式へ自動更新します。

まず、初期選択されているデータを確認します。
移したくないものだけチェックを外します。
✓ / ⚠ アイコンを押すと、対象テーブルの詳細を確認できます。
必要に応じて、実行前バックアップ・メンテナンスモード・登録日/更新日の保持を決めます。
プラグインデータも移したい場合は、連携プラグインデータを ON にして一覧を確認します。
テーマを移す場合は、テーマ依存の要確認表示と会員パスワード互換の表示も確認します。
問題がなければ次へ進みます。

画面内の補足表示は、そのまま失敗を意味するものではありません。多くは「この組み合わせなら確認しておくと安全」という案内です。

3.0 サイトで標準以外のプラグインを使っている場合も、 この画面で「移行可」になれば一緒に移行可能です。逆に、ここで 「移行対象外」 と出るプラグインは、コアデータとは別に個別対応が必要です。

8. 画面3: ステップ3でプレビュー確認と追加ファイルの指定を行う

ステップ3では、この内容で実行してよいかを最終確認します。ここで見ておきたいのは、対象件数、実データのプレビュー、追加で使うファイル、そしてステップ2で決めた設定の確認です。

テーブル別結果と移行データプレビュー

どのデータがどのくらい対象になっているかを確認します。
実際のデータを一部確認できます。
商品名、会員名、受注情報など、見覚えのあるデータが出ているかを確認します。

画像・公開ファイル・app 側補助ファイルの取込み

商品画像や公開ファイル、EC-CUBE 3 のユーザーページ本文も移したい場合は assets_html_ で始まるファイルを指定します。
app/template/user_data などの補助ファイルも移したい場合は assets_app_ で始まるファイルを指定します。
指定できる形式は .tar / .tar.gz / .zip です。ファイル名の接頭辞もチェックされます。

ステップ2で決めた内容の最終確認

実行前バックアップ、メンテナンスモード、登録日/更新日の保持はここでは表示確認のみです。
テーマ移行や連携プラグインの選択結果もここで確認できます。
アセットはジョブ詳細待ちではなく、step3 の実行フローの中で適用されます。

実務上のポイント

EC-CUBE 3 のユーザーページ本文を反映したい場合は、assets_html を忘れないでください。
テーマを移行する場合でも、切替は移行後にテンプレート設定で行います。
空き容量チェックに通らない場合は、不要ファイルを削除してから再実行してください。

テーブル別結果とプレビューを確認します。
必要なら assets_html と assets_app を指定します。
ステップ2で選んだオプションとテーマ/プラグインの状態を最終確認します。
補足メモが表示されても、そのまま失敗を意味するわけではありません。実行条件の説明として確認します。
問題がなければ実行します。

9. 画面4: 移行ジョブで結果・再実行・復元を確認する

実行後は 「移行ジョブ」 で結果を確認します。ここは「終わったかどうか」だけでなく、何が追加され、何が更新され、何がスキップされたか、 アセットでどのファイルが追加・スキップ・エラーになったか、 ユーザーページ競合やカスタムブロック移行がどう処理されたか を確認する画面です。

この画面で確認すること

ステータスが完了しているか
テーブル別結果で追加・更新・スキップ・エラー件数
スキップログ、エラーログ、アセット履歴の詳細
ユーザーページ競合ログ、カスタムブロック移行ログの有無
実行ログの内容

復元と再実行について

ステップ2で 実行前バックアップ を ON にしていた場合は、ジョブ詳細に 「移行前データを復元」 が表示されます。

移行結果を元に戻したいとき
もう一度やり直したいとき
同じ条件で再テストしたいとき

再実行 は最初の本実行と同じパイプラインで動作します。元のバックアップ、選択モジュール、実行オプション、テーマ移行、追加アセット設定を引き継いで再実行します。

スキップがある = 失敗 とは限りません。既存データの扱い、管理者データやシステムマスタの扱い、テーマやプラグインの依存関係によってスキップが発生することがあります。まずは件数と対象データを見て、「想定どおりのスキップか」を確認してください。

10. よくある質問

Q. 3.x 系のサイトからでも移行できますか？

A. はい。EC-CUBE 3.x は対応範囲に含まれています。このガイドは 3.0.18-p7 から 4.3.1-p1 へのデモをもとにしており、プラグイン自体も EC-CUBE 4.3 への移行を想定しています。まずは移行元サイトで最新のバックアッププラグインを使ってバックアップを作成し、ステップ1で読み込んでください。

Q. どのファイルをアップロードすれば移行を始められますか？

A. まずは、移行元サイトのバックアップ生成プラグインで作成した data_migration_backup_*.tar.gz をステップ1で読み込みます。商品画像や公開ファイルも移す場合は同じプラグインが出力する assets_html_*.tar.gz を、app 側補助ファイルも必要な場合は assets_app_*.tar.gz をステップ3で追加します。

Q. 3.0 で使っている有料プラグインや無料プラグインも移行できますか？

A. 料金ではなく、移行先にも対応プラグインがあり、ステップ2の連携プラグイン状態で「移行可」になるか が基準です。移行可なら一緒に移せます。移行対象外なら、そのプラグインデータはこのプラグインでは取り込みません。

Q. 移行先に同じプラグインを入れていないとだめですか？

A. 連携プラグインのデータも移したい場合は、移行先にも対応プラグインを入れて有効化しておくのが前提です。入っていない、または有効化されていない場合は、プラグインデータは移行できません。バックアップからプラグイン本体や Resource を自動配置する仕組みではないため、移行先側で先に導入しておきます。

Q. プラグインデータだけ無理でも、会員や商品などのコアデータは移せますか？

A. はい。連携プラグインデータを OFF にするか、移行対象外のプラグインをそのままスキップして、コアデータだけ先に移行する進め方ができます。

Q. 商品画像や EC-CUBE 3 のユーザーページ本文も一緒に移したいです。

A. ステップ3で assets_html_XXXXXX.tar.gz を指定してください。商品画像や公開ファイルだけでなく、EC-CUBE 3 のユーザーページ本文もこのファイルに含まれます。未指定の場合、ユーザーページ本文は仮テンプレートになります。

Q. どんなプラグインデータが移行しやすいですか？

A. 代表例として、商品レビュー管理プラグイン、クーポンプラグイン、ポイントプラグイン、メルマガ関連プラグイン、会員カスタム項目系プラグインなどがあります。移行先にも対応プラグインが導入・有効化されていれば、多くの一般的なプラグインデータを対象として確認できます。

Q. テーマも一緒に移したいです。

A. テーマ本体の archive はメインバックアップに同梱されます。ステップ2でテーマ移行を確認し、必要ならステップ3で assets_app_XXXXXX.tar.gz も指定してください。同じテーマコードが既にある場合は、ジョブID付きの新規テーマコードで取り込み、切替は移行後にテンプレート設定で行います。

Q. 会員パスワードはそのまま使えますか？

A. 最新のバックアッププラグインで作成したバックアップであれば、会員パスワード互換情報も含まれます。ステップ2で互換対応が表示されていれば、移行元のパスワードでログインでき、初回ログイン成功時に移行先方式へ自動更新します。

Q. テーマ依存の要確認表示が出た場合はどうすればよいですか？

A. テーマ内で利用しているプラグインが移行先で有効でない可能性があります。まず 詳細を見る で対象 Twig を確認し、移行先サイトで必要なプラグインをインストール・有効化してください。必要なら移行元で Twig を修正してからバックアップを再作成してください。

Q. 実行前バックアップは使ったほうがよいですか？

A. はい。特に本番に近い環境では ON をおすすめします。問題があったときにジョブ詳細から 移行前データを復元 できます。

Q. メンテナンスモードは必要ですか？

A. テスト環境では必須ではありませんが、運用中サイトで実行するなら ON をおすすめします。移行中の変更が入りにくくなり、安全です。

Q. 再実行は最初の実行と同じ内容で動きますか？

A. はい。再実行は、元のバックアップ、選択モジュール、実行オプション、テーマ移行、追加アセット設定を引き継いで、最初の実行と同じパイプラインで動きます。

Q. EC-CUBE 3 のカスタムブロックはどうなりますか？

A. カスタムブロックは移行対象です。ブロック定義とテンプレートを取り込み、競合時はファイル名を変更して登録します。どのブロックが追加・更新・リネームされたかは、ジョブ詳細の カスタムブロック移行ログ で確認できます。ただし、EC-CUBE 3 のレイアウト上の配置は EC-CUBE 4.3 にそのまま再現されないため、移行後に配置確認を行ってください。

Q. なぜスキップが出るのですか？

A. 既存データを保持する設定、管理者データの扱い、システムマスタの扱い、または移行対象外の項目によってスキップが出ます。まずはジョブ詳細の スキップログ を確認してください。

Q. カスタムテーブルや独自改修のデータも全部移りますか？

A. このプラグインは標準テーブル中心の移行支援です。独自のカスタムテーブルや独自実装のデータは、別対応が必要になる場合があります。

目次