EC-CUBEのサーバー移転手順と注意点｜2系・4系の違いも解説

「サーバーが古くてPHPを上げられない」
「レンタルサーバーのサービス終了が決まった」

EC-CUBEで作ったネットショップを別サーバーへ移すきっかけは、こうした外的な事情であることがほとんどです。

ところが、EC-CUBEはWordPressと違って、バージョン（2系・3系・4系）によって移転の手順も難易度も大きく変わります。

この記事では、サーバー移転を専門に扱うサイト引越し屋さんが、EC-CUBEのサーバー移転で事前に確認すべきこと、4系・2系それぞれの手順、移転後に必ず行うテスト、よくある失敗と対処法を解説します。「自力でやるか、業者に頼むか」の判断材料としてお使いください。

EC-CUBEサーバー移転における5つの確認事項

移転作業に入る前に、次の5点を確認しておくと失敗の大半を防げます。特に「EC-CUBE本体のバージョン」と「移転先サーバーのPHP・データベースの対応状況」は、移転できるかどうかそのものを左右します。

1. EC-CUBE本体のバージョン

管理画面のシステム情報、または設置ファイルから本体バージョンを確認します。2系（2.11〜2.17）、3系、4系（4.0〜4.3）では、設定ファイルの場所も必要なPHPバージョンもまったく違います。「EC-CUBEだから同じ手順」とは考えず、自分のバージョンに合った手順を選んでください。

2. 移転先サーバーのPHP・データベースの対応

EC-CUBEはバージョンごとに動作するPHPの範囲が決まっています。古い2系はPHP 5系〜7系前半でしか動かないものが多く、最近のレンタルサーバーで標準のPHP 8系では動かないケースがあります。

逆に、EC-CUBE 4.2以降ではPHP 8系（PHP 8.1/8.2）の利用が強く推奨され、最新の4.3系ではPHP 8.1〜8.3が必須要件となっています。移転先サーバーで動作対象のPHPバージョンが選択できるか、MySQLまたはPostgreSQLがバージョン要件を満たしているかを事前に確認してください。

参考：システム要件｜EC-CUBE 4 開発者向けドキュメント

3. プラグイン・独自カスタマイズの有無

長く運用しているECサイトほど、制作会社による独自カスタマイズやプラグインが入っています。テンプレートの改修、独自の決済連携、在庫連携などは、サーバー環境が変わると動かなくなることがあります。誰がどこを改修したかの記録が残っているかも確認しておきましょう。

4. 決済・配送など外部サービスとの連携

クレジットカード決済モジュールやコンビニ決済は、EC-CUBE側のURLやIPアドレスを決済代行会社に登録している場合があります。

サーバーが変わるとIPアドレスが変わるため、決済代行会社側の設定変更が必要になることがあります。移転日程を決める前に、利用中の決済サービスの仕様を確認してください。

5. 「移転」と「バージョンアップ」は分けて考える

2系のまま新サーバーへ移すのか、移転と同時に4系へバージョンアップするのかは、まったく別の作業です。同時に行うと、不具合が出たときにサーバーが原因か、バージョンアップが原因かの切り分けができなくなります。

原則は、まず同じバージョンのまま移転し、動作確認後にバージョンアップです。ただし移転先で古いPHPが選べない場合は、バージョンアップが先になります。

＝＝＝

EC-CUBEのサーバー移転は、一般的なCMSと異なり決済・顧客データを扱うためシビアな扱いが求められます。安全・確実な移行計画をお求めの方は、専門エンジニアによる代行サポートをご検討ください。

>>無料ご相談窓口はこちらをクリック

EC-CUBE4系のサーバー移転手順

4系は設定がほぼ.envファイルに集約されており、ドメイン情報がファイルやデータベースにほとんど含まれないため、2系に比べるとサーバー移転しやすい傾向にあります。流れは「ファイル取得→DB移行→.env書き換え→キャッシュ削除→権限調整→公式サイトのURL変更」の6ステップです。

1. 旧サーバーからファイルをダウンロード（varディレクトリは除外）
2. データベースのエクスポートとインポート
3. .envファイル（または.htaccess）の書き換え
4. キャッシュの削除
5. ファイル権限（パーミッション）の調整
6. EC-CUBEメンバーサイトの登録URL変更（ドメインが変わる場合）

ステップ1：旧サーバーからファイルをダウンロード（varディレクトリは除外）

FTPまたはSSHでEC-CUBE一式をダウンロードします。このときvarディレクトリ配下（キャッシュ・ログ・セッション）は除外してください。古いキャッシュをそのまま持ち込むと、新サーバーでサイトが表示されない原因になります。

ステップ2：データベースのエクスポートとインポート

phpMyAdminやコマンドでデータベースを丸ごとエクスポートし、新サーバーに作成したデータベースへインポートします。

受注・会員データが日々増えるECサイトでは、移転作業中に注文が入るとデータがずれるため、メンテナンス表示にしてから取得するか、切替直前にもう一度取り直す段取りが必要です。

ステップ3：.envファイル（または.htaccess）の書き換え

新サーバーのデータベース接続情報（ホスト・DB名・ユーザー・パスワード）に合わせて.envを書き換えます。本番環境ではデバッグモードがオフになっていること、強制SSLの設定が意図どおりになっていることも確認してください。

ステップ4：キャッシュの削除

var/cache配下を空にします。コマンドが使える環境ならbin/console cache:clearで削除できます。移転後に画面が真っ白になる、古い設定が残るといった症状の多くはキャッシュが原因です。

ステップ5：ファイル権限（パーミッション）の調整

サーバーによって必要な権限が異なり、移転直後に「書き込みできません」系のエラーが出ることがあります。公式の開発者ドキュメントにあるパーミッション設定を参考に、var・html/upload・app/config配下を中心に調整してください。

ステップ6：EC-CUBEメンバーサイトの登録URL変更（ドメインが変わる場合）

ドメインも変える場合は、EC-CUBEオーナーズストアに登録しているサイトURLを変更します。忘れるとプラグインの更新や認証が通らなくなります。ドメイン変更しない場合は当作業は不要です。

EC-CUBE2系のサーバー移転手順

2系は設定がconfig.php・.htaccess・define.phpなど複数ファイルに分散しており、ドメインやディレクトリパスがファイル内に直接書かれています。そのぶん4系より触る箇所が多く、1つ見落とすと表示崩れや管理画面に入れない症状が出ます。手順は6ステップです。

1. ファイル一式のダウンロード
2. データベースのエクスポートとインポート
3. /data/config/config.phpの編集
4. .htaccessの編集
5. define.phpの編集（dataディレクトリのパスが変わる場合）
6. Smartyキャッシュの削除とAUTH_MAGICの確認

ステップ1：ファイル一式のダウンロード

html・data両ディレクトリを丸ごとダウンロードします。2系はdataディレクトリを公開領域の外に置く構成が推奨されているため、移転先でも同じ階層関係を再現できるか先に確認してください。

ステップ2：データベースのエクスポートとインポート

4系と同様にデータベースを移します。2系はPostgreSQLで運用されているケースもあり、移転先がMySQLしか使えない場合は単純なインポートができません。データベースの種類が同じサーバーを選ぶのが前提です。

ステップ3：/data/config/config.phpの編集

データベース接続情報、サイトURL（HTTP_URL・HTTPS_URL）、ルートディレクトリのパスを新サーバーに合わせて書き換えます。ここに書かれたURLが古いままだと、全リンクが旧サーバーを向いてしまいます。

ステップ4：.htaccessの編集

RewriteBaseやPHP設定の記述がサーバー固有になっている場合があります。移転先のサーバー仕様に合わせて修正してください。旧サーバー向けのphp_value指定が残っていると500エラーの原因になります。

ステップ5：define.phpの編集（dataディレクトリのパスが変わる場合）

html/define.phpにはdataディレクトリへの相対パスが書かれています。移転先でディレクトリ構成が変わる場合はここも修正が必要です。

ステップ6：Smartyキャッシュの削除とAUTH_MAGICの確認

/data/Smarty/templates_c配下のキャッシュファイルを削除します。また、config.php内のAUTH_MAGIC（認証用の秘密鍵）が旧サーバーと同じ値で引き継がれているか確認してください。この値が変わると、会員のパスワード認証が一切通らなくなります。

＝＝＝

ECサイト移転で最も避けるべきは「決済連携の不備」や「注文確認メールの不達」による売上機会の損失です。販売停止時間を最小限に抑え、顧客対応に支障を出さずに切り替えたい方は、サイト引越し屋さんへご相談ください。

>>無料ご相談窓口はこちらをクリック

移転後に必ずテストする項目

ECサイトの移転ではトップページが表示されただけでは完了とは言えません。購入導線と管理機能を一通り動かして初めて検証完了です。できれば本番切替の前に、テスト環境またはhostsファイルで新サーバーを向けた状態で次の項目を確認してください。

確認項目	見るポイント
商品一覧・商品詳細	画像表示、価格、在庫表示、カテゴリ絞り込み
カート〜注文完了	テスト注文で最後まで進めるか、送料・税の計算
会員登録・ログイン	既存会員でログインできるか（AUTH_MAGIC確認）
決済	決済代行のテストモードで決済完了・キャンセルが通るか
注文完了メール・問い合わせメール	送信される・迷惑メール扱いにならない（SPF等）
管理画面	ログイン、受注一覧、商品登録、CSV出力
SSL	全ページhttps、混在コンテンツ警告が出ない
表示速度	旧サーバーと比べて極端に遅くなっていないか

特に決済の確認は必ず行ってください。決済代行会社によっては、サーバーのIPアドレスを登録制にしているため、移転後に本番決済だけが失敗するケースがあります。

EC-CUBEサーバー移転でよくある失敗と対処法

移転後のトラブルは原因がある程度決まっています。症状から原因を逆引きできるよう、よくある5つを整理しました。

症状	主な原因	対処
画面が真っ白、または500エラー	PHPバージョン不一致、.htaccessの旧サーバー向け記述、キャッシュ残り	PHPバージョンを要件に合わせる、.htaccessを見直す、var/cache・templates_cを削除
「書き込みできません」エラー	ファイル・ディレクトリのパーミッション	var・upload配下の権限を公式ドキュメントの推奨値に調整
会員がログインできない	AUTH_MAGICの値が旧サーバーと異なる	旧サーバーのconfig.php／.envから同じ値を設定
注文完了メールが届かない	新サーバーのメール送信設定、SPF／DKIM未設定	サーバーのSMTP設定を確認し、DNSにSPFレコードを追加
決済だけ失敗する	決済代行側のIPアドレス制限、コールバックURLの未変更	決済代行会社に新サーバーのIPを登録、管理画面のURL設定を更新

もう一つ多いのが、「移転中に入った注文が消えた」ケースです。データベースを取得した後に注文が入ると、新サーバーにはその注文が存在しません。切替前にメンテナンス表示にする、または切替直前に受注・会員テーブルだけ再度取り込む手順を必ず組んでください。

＝＝＝

新環境への移行直後に発生しやすい決済プラグインの動作不良やカスタマイズ機能の不整合は、原因究明に多大な時間と復旧コストがかかります。万全の体制でリスクなく移行を完了させたい方は、専任チームにお任せください。

>>無料ご相談窓口はこちらをクリック

EC-CUBE2系のまま移転しても大丈夫？PHP脆弱性との関係

「とりあえず2系のまま新サーバーへ」という移転は可能ですが、おすすめはしていません。

2系が動作するPHP 5.x〜7.xは公式のセキュリティサポートがすでに終了しており、過去に発見された重大なリモートコード実行の脆弱性（CVE-2024-4577等）のように、OSやPHPコアの脆弱性に対する公式パッチが提供されません。

参考：phpサポートバージョンについて

どうしても現行の2系のままサーバー移転を行う場合は、レンタルサーバー側で独自に旧PHPバージョン（PHP 5.x / 7.x）向けにセキュリティパッチやWAFを適用・保守しているレンタルサーバーを選定することが必須条件となります。

弊社でも「サブドメインに設置したEC-CUBEが、PHPの脆弱性の影響を受けないか」というご相談を受けています。EC-CUBEもWordPressと同様に、本体・プラグイン・PHPそれぞれのバージョンでリスクが変わります。確認の順番は次のとおりです。

1. サーバーのPHPバージョンを確認する
2. 利用中のPHPが脆弱性の対象なら、修正版への更新を検討する
3. EC-CUBE本体・プラグイン・独自カスタマイズとの互換性を確認する
4. 更新後に商品ページ、カート、注文処理、決済機能をテストする

使っていないEC-CUBEを安全に置いておく方法

「今はショップを休止しているが、いつか再開するかもしれない」というケースも多くあります。メンテナンスモードにしているだけでは、PHPファイルはサーバー上で動く状態のままで、攻撃対象として残ります。

再開予定が未定なら、ファイルとデータベースをバックアップしたうえで、サーバーの公開領域から完全に外すのが最も安全で費用もかかりません。再開時にバックアップから復元すればよく、その間はサーバー上に攻撃される入口がなくなります。

自力でやるか業者に頼むか｜判断の目安と費用

4系で独自カスタマイズがなく、同じドメインのままサーバーだけ移す場合は、手順どおりに進めれば自力でも対応できます。一方、次のいずれかに当てはまる場合は、業者への依頼をおすすめします。

• 2系・3系で、設定ファイルの場所や中身が分からない
• 制作会社のカスタマイズが入っているが、その会社と連絡が取れない
• 決済モジュールを利用しており、移転時の設定変更に不安がある
• 日々注文が入っており、データのずれや停止時間を最小にしたい
• 移転と同時にPHP・EC-CUBEのバージョンアップが必要

費用は、EC-CUBEのバージョン・カスタマイズの量・データ量・バージョンアップの有無で大きく変わります。

2系のまま同一ドメインで移転であればWordPress移転と近い価格帯で収まることもありますが、4系へのバージョンアップを伴う場合はサイトの再構築に近い工数になる点に注意してください。

弊社では、事前調査でEC-CUBEのバージョン・PHP・カスタマイズ状況を確認したうえで、「移転のみ」「移転＋バージョンアップ」の両方の見積りを提示し、比較してご判断いただいています。

まとめ：EC-CUBEの移転はバージョン確認から

EC-CUBEのサーバー移転は、本体バージョンによって手順も難易度も変わります。4系は.envとキャッシュを押さえれば比較的スムーズですが、2系はconfig.php・.htaccess・define.php・AUTH_MAGICと確認箇所が多く、さらにPHPのサポート終了という問題も抱えています。

移転前には「本体バージョン」「移転先のPHP・DB対応」「カスタマイズの有無」「決済連携」「移転のみで済むのか」の5点を確認し、移転とバージョンアップは分けて進めてください。移転後は商品・カート・会員ログイン・決済・メールまで一通りテストして初めて完了です。

「自分のEC-CUBEが移転できるか分からない」という段階からで構いません。サイト引越し屋さんでは、事前調査から移転・バージョンアップ・移転後の保守まで、ECサイトの状況に合わせてご提案しています。お気軽にご相談ください。