EC-CUBE 4系のデータ移行で失敗しないためのチェックリスト｜受注・会員・商品データの移行漏れを防ぐ
目次
【AIによる要約】
– EC-CUBEのデータ移行で一番怖いのは「画面は動くのに、過去の受注や会員情報が静かに消えている」状態です。
– 移行前の現状把握から受注・会員・商品・プラグインの確認、移行後の件数照合までをフェーズ別に点検します。
– 会員パスワードの初期化連絡設計が必須で、サーバー移管かバージョンアップかで確認手順も変わります。
「サーバーを引っ越したら、商品は表示されているのに過去の受注履歴が消えていた」。私たちは業界歴10年以上で300社以上のWeb・ECサイトを支援してきましたが、EC-CUBEの移行トラブルで最も多いのがこのパターンです。
商品データだけ移っていれば管理者は「移行できた」と感じます。しかし受注や会員のデータが欠けていれば、請求対応も顧客対応もできません。当社も自社でECサイトを運営しているため、この損失の重さは身にしみて分かります。
この記事では、EC-CUBE 4系のデータ移行を「事前確認 → 移行作業 → 移行後検証」の3フェーズに分けたチェックリストを示します。移行を外注する場合でも、確認作業そのものは発注者側にしかできない項目を含めています。
まず整理：データ移行には2種類ある
作業内容が大きく違うため、まず自分のケースを区別してください。
- サーバー移管：EC-CUBEのバージョンはそのまま、サーバーだけ引っ越す。PHPバージョンやDBの互換性確認が中心
- バージョンアップを伴う移行：EC-CUBE 4.0〜4.2→4.3のように本体を更新しながら移す。プラグイン互換性の確認が中心
どちらも作業は似ていますが、チェック項目の重点が違います。バージョンアップの費用感や進め方は、EC-CUBE 4系のバージョンアップが怖くて触れない人へ｜進め方・費用・自社更新か代行かの判断基準で詳しく解説しています。
【フェーズ1】移行前の現状確認チェックリスト
ここを飛ばすと、後の工程で「戻れない」状態になります。移行作業の前に必ず完了させてください。
1. EC-CUBEのバージョンと環境を記録する
- 管理画面「情報」または
composer.jsonでEC-CUBEの正確なバージョンを確認した - PHPのバージョン、DB（MySQL/MariaDB/PostgreSQL）の種類とバージョンを記録した
- 移行先サーバーがそのPHP・DBバージョンに対応しているか確認した
バージョン番号の確認方法は、EC-CUBEのバージョンを確認する方法【2系 3系 4系】に手順をまとめています。
EC-CUBE 4系はPHPバージョンの要件が本体のバージョンによって異なります。移行先のサーバー仕様と合わないと、移行後に画面が動きません（出典：EC-CUBE 4 開発ドキュメント「システム要件」）。
2. 移行対象データの棚卸しをする
- 受注データの件数を控えた（管理画面またはDBの
dtb_orderで件数確認） - 会員データの件数を控えた
- 商品・規格・在庫データの件数を控えた
- 退会済み・仮登録の会員など、状態別の件数も控えた
移行後に「移行前の件数」と「移行後の件数」を照合するための基準が、この棚卸しです。件数が合わなければ移行は完了とは言えません。この照合をしないまま納品する業者は、チェック体制そのものが疑わしいと考えてください。
3. カスタマイズ・プラグイン・テーマを洗い出す
- 導入済みの公式プラグイン・独自プラグインを一覧化した
- 開発元に修正履歴（カスタマイズ）の有無を確認した
- 外部連携（決済、配送、在庫管理、基幹システム）の一覧を作った
ここがEC-CUBE移行最大の落とし穴です。カスタマイズはソースコードに直接手が入っていることが多く、本体を上書きすると消えます。決済モジュールは移行後に「注文は通るのにカード決済だけ失敗する」という形で問題が表面化します。
4. バックアップと切り戻し手段を確保する
- 移行前のファイル一式とDBダンプを保存した
- 古いサーバーを解約せず、一定期間並行稼働させられるか確認した
- 「移行に失敗したら元に戻す」手順を文章化した
バックアップは取るだけでなく、復元できることを確認しておく必要があります。詳しくはバックアップを取っている「つもり」が一番危険！本当にデータ復元できるか確認するポイントで解説しています。
【フェーズ2】移行作業中のチェックリスト
5. データは「DB一式」で移す
- DBのダンプを文字コード込みで取得した（失敗しやすいのは「テーブルの一部だけ」を移す場合）
-
html/upload/配下の画像ファイル（商品画像・会員画像）を一式移した -
.envのDB接続情報やAPP_ENV/APP_DEBUGを移行先環境に合わせて修正した
EC-CUBE 4系は画像ファイルがDBではなくファイルシステムに保存されます。DBだけ移すと商品画像が表示されません。DBとファイルの両方が揃って初めて「データ移行」です。
6. 会員パスワードは持ち越せないことを前提にする
- パスワードは移行できない前提で、再ログイン導線（パスワード初期化）の計画を立てた
- 初回ログイン時にパスワード再設定を案内するメールの文面を用意した
- 会員向け告知（お知らせメールやサイト掲載）の日程を決めた
EC-CUBEではパスワードはハッシュ化して保存されます。ハッシュは「暗号化」ではなく元に戻せない変換のため、移行先のバージョンで方式が変わるとそのまま使えません。ここを事前に設計しておかないと、移行後に「ログインできない」という問い合わせが殺到します。過去の受注履歴と会員情報を残す価値はこの対応の手間を上回りますが、告知設計は必須です。
7. 決済・外部連携を移行先で再設定する
- 決済モジュールの認証キー・契約情報を移行先環境で再設定した
- 配送業者のスクリプト（ヤマトB2や佐川飛伝等）の接続設定を確認した
- メール送信（SMTP）設定を移行先サーバーで動くように変更した
決済モジュールはサーバーIPやドメインと紐づく契約が多く、移行後に本番テストが必要です。ここは移行元の業者情報が必要になることも多く、今の保守会社から乗り換えたい時にサイトを止めない方法｜解約・移管を安全に進める手順と事前準備で解説した「解約前に引き継ぎ資料を確保する」原則がそのまま当てはまります。
8. テスト環境で本番と同じ条件で検証する
- 本番と同じPHP・DBバージョンの環境で動作確認した
- テスト購入を実際に行い、決済まで完走させた
- 会員登録・退会、商品検索、カート、マイページの受注履歴表示を確認した
本番環境で直接作業して事故を起こすパターンは、EC-CUBEに限らず非常によく起きます。検証環境の重要性はテスト環境（検証用サイト）がない本番修正がどれほど危険か、専門家が分かりやすく解説にまとめています。
【フェーズ3】移行後の検証チェックリスト
9. 件数照合を行う
- 受注データの件数が移行前と一致する
- 会員データの件数が一致する（状態別の内訳も照合）
- 商品・規格・在庫の件数が一致する
- 金額の合計（受注金額の総和）が一致する
件数だけでなく金額合計まで見てください。件数が合っていても、金額計算の仕様差で端数がずれるケースがあります。
10. 実運用に近い操作で最終確認する
- 実際の管理者アカウントで受注管理・出荷処理・請求対応を操作した
- テスト環境ではなく本番環境で、テスト決済を1件以上完了させた
- 自動送信メール（注文確認・出荷通知）が正常に届くか確認した
- DNS切り替え後にSSL・ドメインの反映を確認した
- 古いサーバーの解約日を決め、切り戻し期間を明文化した
夜間や週末に本番切り替えをしないことも重要です。問題が起きた時に業者へ連絡が取れないと、ECは売上ゼロの時間だけ損失が積み上がります。当社でも深夜移行の失敗から何度も復旧に立ち会ってきましたが、切り替えは必ず業者の稼働時間内に行うべきです。
自社でできる範囲と、任せるべき範囲の境界
チェックリストを見て分かる通り、件数の棚卸しや「移すべきデータの定義」は発注者側にしかできません。一方、DBダンプの取得から決済モジュールの再設定、本番切り替えまでは、失敗すると売上に直結する領域です。
当社の判断基準はこうです。受注データが日々更新される稼働中のECサイトの移行は、切り戻し手順と件数照合をセットで実施できる体制があるなら外注に任せる。 移行単発で完了せず、移行後の監視まで含めて体制を組めるかを、業者選びの基準にしてください。
カジヤは代理店を挟まない直接取引で、社内の専任エンジニアが移行計画から本番切り替え、移行後の検証まで一貫して対応します。EC-CUBEのサーバー移管やバージョンアップを含む運用全般は、Webサイト保守管理サービスでご相談いただけます。まずは現状のシステム構成の棚卸しからでも、お気軽にご連絡ください。
