EC-CUBE3から4.3.1へバージョンアップ（移行）手順

EC-CUBE3系を長く運用していると、「PHP更新の案内が来た」「決済・セキュリティの要件が厳しくなった」「改修のたびに影響範囲が読めない」といった不安が増えてきます。
そこで本記事では、EC-CUBE3系からEC-CUBE4.3.1へ移行（バージョンアップ）する際の考え方・進め方・落とし穴を、実務目線でまとめます。

EC-CUBE4.3/4.3.1の位置づけ（何が変わる？）

EC-CUBE4.3は、PHPやミドルウェア側の世代更新に対応しており、要件が明確に整理されています。
また4.3.1では、公式決済モジュール（例：Amazon Pay / EC-CUBE Payment Plus等）を標準バンドルする変更が入っています。

参考：
https://doc4.ec-cube.net/quickstart/requirement
https://github.com/EC-CUBE/ec-cube/releases

「3→4」は単なるアップデートではなく“移行プロジェクト”です

EC-CUBE3系から4系は、内部構造・仕組みが大きく変わるため、WordPressのように「上書きで更新して完了」とはなりにくいです。
基本方針は次のいずれかになります。

• 新規で4.3.1環境を構築 → データ移行 → 機能移植（推奨）
• 既存資産に強く依存している場合は、段階的に要件を整理して「移行設計」を固めてから進める

「どの方式が最短で安全か」は、カスタマイズ量・プラグイン構成・決済/外部連携で変わります。

バージョンアップで得られる主なメリット

1）サーバー/ミドルウェア更新に追従しやすくなる

EC-CUBE4.3は要件（PHP/DB）が明確で、保守運用の“詰み”を避けやすいです。

2）決済導入のスムーズ化（4.3.1）

4.3.1では公式決済モジュールのバンドルにより、初期状態から主要決済を試しやすい設計になっています。

3）セキュリティ・運用の不安を減らしやすい

公式側も4.3リリースでセキュリティ強化に触れており、長期運用の観点で「更新し続けられる土台」を作りやすいです。

参考：
https://www.ec-cube.net/news/detail.php?news_id=464
https://www.ec-cube.net/download/archive/

失敗しないための全体フロー（実務の進め方）

フェーズ0：現状棚卸し（ここで8割決まる）

• EC-CUBE3のバージョン
• 独自改修（どのファイル/どの機能に手が入っているか）
• プラグイン一覧（決済・受注・会員・メール・CSV・ポイント等）
• 外部連携（WMS/基幹/MA/レコメンド/配送、API、バッチ）
• SEO影響（URL、構造、テンプレ、リダイレクト要否）

棚卸しが曖昧なまま着手すると「想定外の追加費用・追加期間」が発生しやすいです。

フェーズ1：4.3.1の新環境を構築（検証環境）

• 4.3系の要件に合わせてPHP/DB/ミドルウェアを準備
• 本番と同等のメール・決済・バッチ実行環境を再現
• Git運用/デプロイ手順/バックアップ復元手順も同時に整備

フェーズ2：機能移植（3の要件を4へ再実装）

• テンプレート（デザイン）移植：Twig構造の違いを前提に作り直しが発生しがち
• 受注/会員/商品/CSV：業務フローの再現テストが必須
• プラグイン：4.3対応版があるか、代替可能か、独自開発が必要かを判定

フェーズ3：データ移行（設計→移行→照合）

• 移行対象：会員、受注、商品、カテゴリ、在庫、ポイント、定期（ある場合）、レビュー等
• 照合：件数一致だけでなく、金額計算・税・ポイント残・ステータス遷移まで確認

フェーズ4：総合テスト→切替

• 決済（与信/取消/返品/再オーソリ）
• メール（注文、発送、問い合わせ、ステータス変更）
• SEO（URL、canonical、noindex、サイトマップ）
• リダイレクト設計（旧URLが多い場合は最重要）

よくある失敗例と回避策

失敗例1：プラグインが4.3未対応で、代替がなく詰む

回避策：
事前に「必須機能」と「代替可能」を分け、代替案（別プラグイン/独自開発/運用変更）まで設計します。

失敗例2：URL変更で自然検索が落ちる

回避策：
旧URL一覧を抽出し、301リダイレクトと内部リンク整合、Search Consoleでの監視を事前計画します。

失敗例3：決済のテストが甘く、本番切替後に受注停止

回避策：
決済会社のテスト手順を含め、返金/取消/再与信まで業務シナリオで試験します。

期間と費用がブレるポイント（見積もりの前提になる項目）

• 独自改修の量（商品・受注・会員の改造が多いほど増）
• 決済の種類（複数決済・後払い・定期・外部与信連携など）
• 外部連携（WMS/基幹/配送の自動連携、バッチの数）
• SEO要件（URL維持、カテゴリ構造、構造化データなど）
• プラグイン本数と置き換え可否

まとめ：EC-CUBE3のまま「だましだまし運用」する前に、移行設計から始めましょう

EC-CUBE3→4.3.1は、単純なアップデートではなく「将来も運用し続けられるEC基盤を作る」ための移行です。
だからこそ、最初に棚卸し→移行方針→テスト計画を固めることで、費用も納期も安定し、切替後のトラブルも大きく減らせます。

お問い合わせ

EC-CUBE3系から4.3.1への移行は、カスタマイズやプラグイン構成によって最適ルートが大きく変わります。
弊社では、現在のEC-CUBE3環境を確認したうえで、以下を整理し、無料でお見積もりをご提示しています。

• 移行方式（作り直し/段階移行）
• 必要な改修範囲
• 決済・外部連携の対応方針
• SEO影響とリダイレクト方針
• 概算費用と納期目安

「今のサイトがどれだけ改修されているか分からない」「プラグインが多くて不安」「切替で売上を止めたくない」——そんな場合も大丈夫です。
まずはお気軽にお問い合わせください。現状を確認し、最短・安全な移行プランをご提案します。