EC-CUBE2系から4系へ移行するには？データ・機能・決済の確認点と進め方

「今の会員はそのままログインできるのか」「独自の注文方法を残せるのか」「営業を続けながら移行できるのか」。2系から4系への移行では、バージョンの数字だけでなく、日々の受注業務をどう引き継ぐかが重要です。

本記事は、主にダウンロード版のEC-CUBE2系から4系へ移行する場合を扱います。更新が必要か、いつ実施するかという全体的な判断は、EC-CUBEのバージョンアップの費用・実施時期・依頼先の選び方をご覧ください。

2系から4系への移行は、データと機能を分けて考える

2系のプログラムやテンプレートを、そのまま4系で動かす前提にはできません。一方で、商品情報や会員情報など、調査と変換を行って引き継げるデータもあります。「すべてを作り直す」「ツールだけで丸ごと移せる」のどちらかで判断せず、対象ごとに確認します。

EC-CUBE公式のバージョンアップ案内でも、2系・3系向けにデータ移行プラグインなどの利用を案内しています。ただし、移行先のすべての4系バージョンや、独自カスタマイズまで対応するという意味ではありません。

• データ：何を、どの項目・形式に変換して移すか
• 機能：4系の標準機能・対応プラグイン・個別開発のどれで実現するか
• 画面：現在の見た目と操作方法をどこまで引き継ぐか
• 運用：注文処理、決済、出荷、連携、保守を誰が担当するか

移行先は「4系」で一括りにせず、本体の詳細バージョン、PHP・データベース、決済、プラグインの対応条件をそろえて選びます。4系内でも対応範囲は異なります。

まず現行サイトの状態と移行の目的を整理する

現在の本体バージョンに加え、PHP・データベース、サーバー契約、適用済みの修正、決済モジュール、独自改修を一覧にします。2系という名称だけで現在の保守状況は判断できません。利用中の構成について、各提供元の情報と保守契約を確認してください。

本体の確認方法は、EC-CUBEのバージョンを確認する方法を参照してください。セキュリティ情報は、EC-CUBE公式のセキュリティ情報と利用環境を照合します。

目的は「古いから更新する」だけでなく、保守できる環境への移行、スマートフォンでの注文のしやすさ、手作業の削減など、解決したい課題として整理します。表示や処理に問題がないことだけでは、今後も保守・決済・連携を続けられるかは分かりません。

商品・会員・受注データで確認すること

商品は件数だけでなく、規格・画像・価格条件まで確認する

商品名や価格のほか、商品コード、サイズ・色などの規格、カテゴリ、画像、在庫、公開状態を確認します。独自に追加した項目は、4系側に保存先や表示機能を用意する必要があるかを調べます。

移行テストでは、商品数の一致だけで終わらせず、複数規格の商品、非公開商品、在庫切れ商品などを選んで、画面と注文結果を確認します。取引先別価格がある場合は、会員条件によって正しい価格になるかも対象です。

会員はログイン・住所・ポイントの扱いを確認する

会員情報、配送先、保有ポイント、会員区分など、引き継ぐ項目を決めます。パスワードを継続利用できるかは保存方式と移行方法によって異なります。既存会員のログイン、パスワード再設定、案内メールの送受信をテストしてください。

テスト環境の個人情報は、確認に必要な範囲に絞り、アクセスできる担当者と削除時期を決めます。テストメールが実際の顧客へ送られない設定も確認します。

受注履歴は、移行後に何をしたいかを先に決める

過去の注文を管理画面で参照するだけなのか、会員の購入履歴に表示するのか、再注文や返品対応にも利用するのかで必要な作業が変わります。旧商品の削除や税率・送料ルールの変更がある場合も、過去の注文金額や明細を正しく保持できるかを確認します。

全期間を新サイトへ移す方法のほか、一部を移行し、残りは必要な期間・権限で参照できる形に保存する方法も検討できます。未出荷、入金待ち、キャンセル処理中の注文は、切り替え後にどちらのシステムで処理するかを明確にします。

独自機能・プラグイン・決済の引き継ぎを確認する

今の機能を、そのまま再開発する前に整理する

現在の機能を「公開時に必要」「設定や運用で代替できる」「公開後に追加する」「使っていない」に分けます。2系の独自機能でも、4系の標準設定や対応プラグインで置き換えられる場合があります。逆に、似た名前の機能でも、業務に必要な条件を満たすとは限りません。

プラグインは、移行先バージョンへの対応、他のプラグインとの組み合わせ、保守・更新条件を確認します。新しいプラグインを入れれば、旧プラグインのデータまで自動で移るとは限りません。

決済は対応バージョンと契約・継続処理を確認する

利用中の決済会社へ、移行先で使える決済プラグイン、契約や審査の要否、テスト方法、切り替え手順を確認します。登録済みカードの識別情報や定期購入・継続課金は、商品・会員データとは別に引き継ぎ条件を確認してください。

旧サイトで受けた注文の売上確定・返金などを、切り替え後も処理できるかが重要です。対応プラグインが見つからない場合も、独自開発を前提にせず、決済会社の提供手段と代替案を比較します。

BtoB機能や外部連携は、注文後の処理まで試す

取引先別価格、掛け払い、発注単位、承認、基幹システムへの受注連携などがある場合は、代表的な取引条件で一連の業務を試します。連携方法だけでなく、コードの対応、注文変更、再送、エラー時の担当を確認します。

連携の確認項目は、ECと基幹システムの連携設計で詳しく解説しています。

デザイン変更とURLの引き継ぎを分けて計画する

4系への移行に合わせて画面を見直す場合は、見た目だけでなく、商品検索、規格選択、会員ログイン、購入完了までを確認します。2系のテンプレートをそのまま利用する前提ではなく、残したい表示と改善したい操作を整理します。

商品・カテゴリなどのURLを変更する場合は、旧URLと対応する新URLの一覧を作り、恒久的なリダイレクトを設定します。移行先と内容が対応しているかを確認し、旧URLを一律にトップページへ転送する方法は避けます。

内部リンク、canonical、サイトマップ、検索エンジンへの公開設定も確認します。公開後はSearch Consoleなどでクロールや検索状況を確認してください。移行後に検索順位が一時的に変動する場合があり、移行だけで順位向上や維持を保証することはできません。手順はGoogleのサイト移転ガイドも参考になります。

移行費用と期間は、引き継ぐ範囲によって変わる

費用は、現状調査、要件整理、画面制作、機能開発、データ変換、決済・外部連携、テスト、公開作業に分けて確認します。「移行一式」だけでは、過去の受注履歴や独自項目、切り替え後の対応が含まれるか分かりません。

• 独自改修の内容が分かる資料やソースコードを確認できるか
• データの量・形式と、変換や整理が必要な項目は何か
• 再構築する機能、連携先、決済方法はいくつあるか
• デザイン変更と商品・コンテンツの整理をどこまで行うか
• 移行テスト、業務確認、切り替えリハーサルを誰が担当するか
• 決済審査や連携先の作業に、どのくらいの準備期間が必要か

見積もりでは、調査後に変わる可能性がある項目、対象外の作業、管理費・消費税、公開後の保守を分けて確認します。日程には制作会社の作業だけでなく、自社がテスト結果を確認する時間も含めてください。

サンクユーの対応範囲や構築実績、相談から公開までの進め方は、EC-CUBE構築・カスタマイズサービスをご覧ください。

移行テストから公開切り替えまでの進め方

1. 現状調査と範囲の合意：データ、機能、契約、アクセス権限を確認し、公開時に必要な範囲を決めます。
2. 4系の環境構築：画面・機能・決済・連携を整え、テスト環境で確認できる状態にします。
3. 試験移行と業務テスト：データを移し、件数・内容・ログイン・注文・決済・出荷などを確認します。
4. 切り替えリハーサル：最終データの取得から反映までの所要時間と手順を確認し、停止時間、担当、連絡方法を決めます。
5. 本番切り替え：バックアップ、旧サイトの更新停止、最終移行、公開後の確認を合意した順序で進めます。
6. 公開後の確認と保守：注文・決済・メール・連携・計測を確認し、問い合わせやエラーを監視します。

構築中に旧サイトで増えた注文や会員情報も移行対象です。旧サイトと新サイトの両方に注文が入る時間が生じないか、在庫やポイントの変更を取りこぼさないかを確認します。

公開を延期する条件と、問題が起きた場合の切り戻し条件も事前に決めます。新サイトで注文や決済が発生した後は、単に旧サイトへ戻すだけでは情報が一致しなくなる可能性があります。新たな取引の照合・反映まで含めて手順を用意してください。

4系に移行した後も、更新と動作確認、バックアップ、障害対応は必要です。公開後の担当範囲は、EC-CUBE保守の対応内容と引き継ぎを参考に整理してください。

EC-CUBE2系から4系への移行でよくある質問

EC-CUBE2系から4系へ、そのままアップデートできますか？

2系のプログラムやテンプレートをそのまま4系で使う前提にはできません。4系の環境を用意し、必要な機能を構築したうえでデータを移す計画を立てます。移行ツールを利用できる場合もありますが、対応するバージョン、対象データ、独自項目の扱いを確認する必要があります。

会員のパスワードや登録済みカード情報も移せますか？

会員パスワードを継続利用できるかは、保存方式と移行方法によって確認が必要です。移行後のログインと再設定をテストします。登録済みカードの識別情報や継続課金は、決済会社の契約・仕様によって扱いが異なるため、会員データと同じように移せるとは限りません。

現在のデザインや独自機能は残せますか？

見た目や業務上の要件を引き継ぐことは検討できますが、2系のテンプレートや改修コードをそのまま使えるとは限りません。4系の標準機能、対応プラグイン、個別開発のどれで実現するかを整理し、不要になった機能も見直します。

移行中も注文を受け続けられますか？

新サイトの構築中は旧サイトを運用する進め方があります。ただし、最終データの移行と切り替えでは、注文や会員情報の更新を止める時間が必要かを検討します。停止時間の有無と長さは構成・データ量・移行方式によって異なるため、事前のリハーサルを踏まえて決めます。

4系へ移行すると検索順位や売上は上がりますか？

4系への移行だけで、検索順位や売上が上がるとはいえません。URLが変わる場合は対応表とリダイレクトを用意し、公開後の検索状況を確認します。購入画面や操作性の改善効果も、実際の利用状況を計測して判断します。

仕様書がなくても移行の相談はできますか？

仕様書がない場合でも、サイト、管理画面、ソースコード、データなど、確認できる情報から調査を進められることがあります。調査に必要なアクセス権限と契約上の条件を確認してください。仕様が不明な部分は、調査後に見積もりや日程を調整する可能性があります。

移行の相談前に用意しておく情報

分かる範囲で、次の情報を整理してください。不明な項目は未確認のままでも、調査が必要な範囲から相談できます。

• 現在のサイトURLとEC-CUBEの詳細バージョン
• サーバー・保守・決済の契約先
• プラグインと独自機能の一覧、仕様書の有無
• 商品・会員・受注の件数と、移行したい期間・項目
• 基幹・在庫・配送などの連携先
• 今困っている業務、残したい機能、希望する公開時期と予算

初回の問い合わせには、パスワードや顧客データを添付せず、調査の担当と範囲が決まってから適切な方法で共有してください。