EC-CUBEバージョンアップの費用と進め方｜改修・データ移行・業者依頼の確認点

ECサイト

最終更新日：2026年10月14日

この記事の監修者

齊藤真也

株式会社ファーストネットジャパン代表取締役

1998 年創業時からアプリ開発・Web マーケティング・フルリモート SES・ホームページ制作・翻訳・グラフィックデザインなど幅広い IT／クリエイティブ領域を手がけ、4,000 件超のプロジェクトを統括。セキュリティ対策・SEO・システム開発から中小企業のWeb戦略支援まで、技術とデザインの両面でクライアントの課題解決を27年以上にわたり支援してきた。
大阪本社・東京オフィスの2拠点体制で、全国の企業のデジタル化をサポート。
高松市出身。座右の銘は「圧倒的努力」。

EC-CUBEのバージョンアップは、本体を更新するだけでなく、導入プラグイン、独自機能、決済、サーバー環境をあわせて確認する作業です。異なる系統への移行では、データと機能の作り直しを含む計画が必要になる場合があります。

更新費用は現行環境・改修内容・移行データ・テスト範囲の確認後に見積もります。新たなECサイトとして再構築する場合、FNJのEC制作は150万円〜が目安で、要件・規模により変動します。更新だけの案件に同じ最低価格を当てはめず、調査・改修・公開後対応を分けてください。

この記事では、EC-CUBEを運用する企業向けに、更新の見積もり、互換性調査、データ移行、注文を扱う切り替えと業者依頼の確認点を整理します。

ECサイト制作・ネットショップ構築
をご検討されていますか？

ファーストネットジャパンでは、1998年の創業から培ってきた知見・経験をもとに、Shopify・EC-CUBE・独自開発まで、事業内容や必要な機能に合わせたECサイト制作を支援します。構築から公開後の集客・運用改善まで、まずはお気軽にご相談ください。

ECサイト制作サービスを
詳しく見る

同じ系統の更新か、別の系統への移行かを確認する

EC-CUBEの公式更新資料は、対象バージョンに応じた作業を案内しています。現在の構成に合う手順を選び、別バージョン向けの操作をそのまま本番へ適用しないことが基本です。

確認項目	調べる内容
本体・実行環境	現行バージョン、PHP・データベース・サーバー条件
プラグイン	対象バージョンへの対応、更新・代替の必要性
独自機能	変更箇所、連携、管理画面、業務ルール
データ	商品・会員・注文・ポイント等の引き継ぎ条件
公開条件	受付を止める時間、最終同期、復旧方法

「最新版へ上げたい」だけでは作業範囲が決まりません。現在の機能をすべて残すのか、使わない機能を整理するのかを、運営・受注・出荷担当と確認します。

EC-CUBE更新費用の見積もりは、調査と改修を分ける

区分	見積もりで確認する内容
事前調査	構成、カスタマイズ、更新方針、未確認事項
更新・改修	本体、プラグイン、独自コード、管理画面
移行	項目対応、変換、件数照合、移せない情報
テスト	注文・決済・取消・メール・配送・連携
切り替え・保守	最終同期、復旧待機、監視、追加修正条件

ソースや変更履歴が残っていない場合は、調査の比重が大きくなります。調査後に開発見積もりを確定する進め方も選択肢です。見積書では調査で分かること、追加費用になる条件、第三者プラグイン等の契約費を確認してください。

更新・移行はテスト環境で順に進める

現行環境をバックアップし、復元できる条件を確かめる。
複製したテスト環境で更新・移行の方式を検証する。
商品・会員・注文の項目対応を決め、試験移行する。
独自機能、決済、配送、連携を確認して修正する。
運営担当が注文から取消・出荷まで試す。
最終同期、受付停止、切り替え、戻す判断を承認する。

期間は改修規模とプラグイン・決済提供元の確認、試験移行の結果で変わります。工程表には現行調査、試験移行、外部サービス調整、受入確認、切り替えを独立して記載し、必要資料と承認日を決めます。

ECサイト制作・ネットショップ構築
をご検討されていますか？

ECサイト制作サービスを
詳しく見る

データ移行と注文差分は、照合方法を先に決める

商品件数が一致していても、規格、価格、配送条件、会員区分が変わると業務に影響します。会員の認証情報や決済契約情報が同じ形で移せるとは限らないため、対応可否と再設定の要否を確認します。

対象	照合する例
商品	品番・規格・税区分・価格・公開状態
会員	会員区分・住所・ログイン方法
注文	受付番号・金額・決済・発送状態
在庫	SKU別数量・引当・連携の管理元
切り替え中の差分	最終移行後の注文・変更・取消

戻す場合も新環境で受けた注文をどう扱うか決めます。データベースを戻すだけでは、決済済みの注文や送信済みメールとの不一致が残ることがあります。決済・注文・連携の照合担当を指定してください。

業者へ渡す資料と、納品時の受入チェック

本体・サーバー・プラグインの一覧と契約状況。
独自機能の説明、現行業務、困っている動作。
商品・会員・注文の件数と試験用データの条件。
決済・配送・外部連携の窓口とテスト環境。
公開可能日、停止条件、保守担当、復旧の判断者。

制作実務で注意したいのは、トップページの表示だけで更新完了とすることです。通常注文に加え、決済失敗・注文取消・返金の連絡・在庫切れ・メール・出荷連携を運営担当が確認し、結果を記録します。

更新後の合否記録を、決済・受注・出荷で残す

受入テストは操作した人、日時、注文番号、期待結果、実際の結果を残します。画面上の「注文完了」と決済側の結果、管理画面の受注状態を照合し、その後の出荷担当が引き継げるか確認します。実際の本番決済を試す場合の方法・金額・取消等は、決済提供元と運営担当の条件に従って決めてください。

確認する状態	合否の例
決済成功	注文番号と決済結果が対応する
決済失敗	支払い済み・出荷可能として扱われない
メール	受付内容と通知先・本文が正しい
管理・出荷	注文の検索、状態変更、連携先への伝達ができる
復旧	戻す場合の注文と決済の照合方法が決まっている

未対応のプラグインがある場合は、公開を延期する、代替機能へ切り替える、対象機能の利用を一時停止する等の判断が必要です。「とりあえず更新して後から直す」では注文受付に影響し得ます。更新で解消する問題、残る制約、保守で対応する事項を一覧化し、運営側が承認してから切り替えます。バックアップは保存の有無だけでなく、戻す手順と担当まで確認します。