REPLACEMENT GUIDE
ECカートの乗り換えは、何を基準に決めるべきか
判断基準・費用・移行手順を1ページにまとめました。
最終更新 2026年9月15日 ／ 監修：渡邉 章公（株式会社メルカート 代表取締役社長）
4.9万円〜
月額（税別）
0円
受注件数の従量課金
20万PVまで
追加費用なし
233社
導入実績
ECの乗り換え（リプレース）とは、稼働中のECサイトを別のプラットフォームへ移行することです。
ECの乗り換えを判断するサインは「①機能の限界 ②従量課金による月額の増加 ③外部ツールの連携数 ④相談体制 ⑤データの分断」の5つです。このうち2つ以上に当てはまる場合、乗り換えの検討時期に入っていると判断できます。
ECの乗り換えにかかる期間は、要件定義から公開まで最短2〜3か月です。期間も費用も、既存サイトの規模、外部連携の数、移行するデータ量に比例して増えます。
ECカートの乗り換えを検討すべきタイミングはいつか
ECカートの乗り換えを検討すべきタイミングは、以下の5つのうち2つ以上に当てはまったときです。
1. やりたい施策が、カートの仕様で止まる
会員ランク、定期購入の条件分岐、BtoBの取引先別価格。実現したい施策のたびに「カートが対応していない」で止まるなら、機能の天井に達しています。
2. 売上が伸びるほど、月額も上がる
受注件数やPVに応じた従量課金は、事業の成長がそのままコスト増に変わります。年商が伸びる想定なら、3年総額で試算し直すべき段階です。
3. 外部ツールの連携数が10を超えた
MA、CRM、レビュー、在庫。つなぐほど運用と障害対応の手数が増えます。基盤側に取り込めるものがないか見直す時期です。
4. 相談できる相手が、サポート窓口しかいない
施策の壁打ち相手がいない状態では、EC事業そのものが伸びません。構築後の伴走体制は、選定軸に入れるべき項目です。
5. データがサイトごと・ツールごとに分断している
会員・受注・行動データが1か所に集まっていないと、AI活用の前提が成立しません。
移行先を、類型で絞る
いまと同じ類型に移るのか、別の類型に上げるのか。ここが決まると候補が絞れます。製品ごとの費用は、絞ってから見積もりを取って比べてください。
| 移り方 | 向いている状況 | 注意する点 |
|---|---|---|
| ASP型 → クラウドEC型 | 売上は伸びているが、やりたい施策が機能の制約で止まっている | 会員・注文履歴・ポイントが移せるかを先に確かめる |
| ASP型・クラウドEC型 の中で移る | 機能は足りているが、費用構造か支援体制が合っていない | 3年総額で比べる。月額だけでは差が出ない |
| クラウドEC型 → パッケージ型 | 年商が伸び、業務フローに合わせた作り込みが必要になった | 初期費用と保守費、社内に必要な体制がまとめて変わる |
| そのまま使い続ける | 止まっている理由が、基盤ではなく運用体制にある | 移っても解決しない。先に運用の課題を切り分ける |
ECの乗り換え費用はいくらかかり、いつ回収できるのか
ECの乗り換え費用は「構築費・データ移行費・並行運用期間の重複コスト」の3つで構成されます。回収期間は、CVR改善による売上増、運用工数の削減、従量課金の削減分の合計から逆算します。
構築費
要件の複雑さとデザインの作り込みで決まります。既存サイトの再現ではなく、必要な要件に絞ることで抑えられます。
データ移行費
会員・受注・商品・ポイントの量と、移行元の仕様に比例します。設計を後工程に回すと膨らみやすい項目です。
並行運用の重複コスト
新旧2つの環境を同時に維持する期間の費用です。切り替え計画で短縮できます。
補助金については、制度により移行費用が対象となる場合があります。対象範囲と申請時期は年度ごとに変わるため、検討時点の最新要件をご確認ください。
ECの乗り換えはどの順番で進めるのか
ECの乗り換えは「課題の洗い出し → ゴールの設定 → 要件定義 → 設計 → 構築とデータ移行 → テスト → 公開」の7ステップで進めます。全体の目安は最短2〜3か月です。
課題の洗い出し / 現状分析
いま止まっている施策、外部連携、データの所在を洗い出します。使っていない機能をここで特定しておくと、あとの要件が絞れます。
ゴール・目的の設定
乗り換えで何を達成するのかを決めます。ここが曖昧なまま進むと、現行機能の再現だけで終わります。
要件定義
「いまの機能を全部」ではなく、事業成長に必要な要件から書きます。要件が固まったら、3年総額・機能の範囲・サポート体制の3軸で製品を比べます。形態の異なる3社を並べると判断しやすくなります。
設計
サイト全体の情報設計と画面設計に加えて、会員・受注・商品・ポイントを欠損させない引き継ぎ方をここで決めます。移行の設計を構築の後工程に回さないことが重要です。
構築 / データ移行
サイトを構築し、決めたルールで既存データを移します。テスト移行を必ず挟みます。
テスト
並行稼働の期間と、切り替え当日の手順を握ります。公開日だけを固定してテスト期間を圧縮しないようにします。
リニューアルオープン
公開はゴールではありません。運用に入ってからの伴走体制を、選定の時点で確認しておきます。
EC移行でSEOの評価は下がるのか
ECの移行でSEO評価が下がるかどうかは、URL構造の設計と301リダイレクトの実施で決まります。旧URLから新URLへ301リダイレクトを1対1で設定し、内部リンクも新URLへ張り替えれば、評価は引き継げます。
実務上、最も多い失敗は「リダイレクト表の作成を公開直前に回すこと」です。商品ページ・カテゴリページ・記事の全URLを対象に、要件定義の段階でマッピング表を作り始めてください。
移行時のSEOチェック項目
- 旧URLと新URLの1対1マッピング表を作成する
- 301リダイレクトを設定し、リダイレクトチェーンを作らない
- 記事・商品ページ内の内部リンクを新URLへ張り替える
- XMLサイトマップを更新し、Search Consoleへ送信する
- 構造化データ（商品・パンくず・FAQ）を移行先で再実装する
- 公開後1〜3か月は、主要URLの順位とインデックス状況を追う
ECの乗り換えでよくある失敗は何か
ECの乗り換えでよくある失敗は、要件定義の起点を「現行機能の再現」に置いてしまうことです。代表的な4点を挙げます。
- 「いまの機能をすべて再現する」から要件を始めてしまい、使われていない機能まで移植する
- データ移行の設計を、構築の後工程に回してしまう
- 公開日だけを固定して、テスト期間を圧縮してしまう
- 従量課金の増加分を、3年総額に入れずに比較してしまう
よくある質問
ECカートの乗り換えを検討すべきタイミングはいつですか？
実現したい施策がカートの仕様で止まる状態が繰り返されたときです。機能の限界・従量課金による月額の増加・外部ツールの連携数・相談体制・データの分断の5つのうち2つ以上に当てはまる場合、検討時期に入っていると判断できます。
乗り換えにはどのくらい期間がかかりますか？
要件定義から公開まで最短2〜3か月です。既存サイトの規模、外部連携の数、データ移行の複雑さによって変わるため、要件定義の段階で個別にお見積もりします。
会員データやポイントは引き継げますか？
会員・受注・商品・ポイント残高はいずれも移行できます。移行元の仕様により変換設計が必要なため、要件定義の段階で対象データを確定させます。
移行中、既存サイトは止まりますか？
並行稼働の期間を設けるため、営業を止める必要はありません。切り替えは深夜帯に実施するのが一般的です。
移行でSEOの評価は下がりませんか？
URL構造の設計と301リダイレクトを適切に行えば、評価は引き継げます。移行時に最も見落とされやすい工程のため、要件定義に必ず含めてください。
NEXT STEP
自社の場合はどうなるか、
直接ご相談いただけます
いまの構成をお聞きしたうえで、移行の可否・期間・概算費用をその場でお伝えします。