他カートからShopifyへ移行する方法｜費用・手順・注意点を徹底解説
福岡ECサイト株式会社
代表 鳥井 敏史
福岡ECサイト株式会社 代表 鳥井 敏史
ECサイト制作・AI検索対策の実務コンサルタント。15年以上にわたりECサイトの売上構造改善と集客設計を支援。売上改善・集客改善の実務支援を中心に企業のECサイト構造の再設計を行う。
専門分野
ECサイト制作 ECサイトリニューアル AI検索対策 SEO / コンテンツ設計ECサイト改善の主な実績
この記事の監修
福岡ECサイト株式会社 代表 鳥井 敏史
「他カートからShopifyへの移行」とは、現在利用しているECプラットフォームから商品、顧客、注文などの必要なデータを取り出し、Shopifyの仕様に合わせてデータ、機能、デザイン、決済・配送、外部システムとの連携を再構築することです。
ーー
現在のECカートで機能を拡張しにくい、運用負担が大きい、海外販売へ対応しづらいといった課題から、Shopifyへの移行を検討することがあります。
ただし、ECサイトの移行は、商品データを新しいカートへコピーするだけの作業ではありません。顧客情報や注文履歴、会員制度、決済、配送、SEO、外部システムとの連携まで整理し、Shopifyの仕様に合わせて再構築する必要があります。
準備が不十分なまま進めると、商品情報の欠落、顧客がログインできない、旧URLから新しいページへ移動できない、公開後に注文を受け付けられないといった問題が起こりかねません。
この記事では、他カートからShopifyへ移行する方法を、移行前の調査からデータ移行、サイト公開、公開後の確認まで順を追って解説します。費用・期間の考え方や、移行時に起こりやすい失敗もあわせて紹介します。
この記事でわかること
- Shopifyへ移行できるデータと個別対応が必要なデータ
- CSV、移行アプリ、APIなどの移行方法
- 商品、顧客、注文を移行する際の注意点
- ポイント、定期購入、ドメイン、SEOの対応方法
- 移行に必要な費用・期間と制作会社の選び方
- 公開前後に確認すべき項目
1. 他カートからShopifyへの移行とは
他カートからShopifyへの移行では、現在利用しているECプラットフォームから必要なデータを取り出し、Shopifyのデータ形式と機能に合わせてECサイトを再構築します。
移行元には、EC-CUBE、BASE、STORES、カラーミーショップ、MakeShop、ショップサーブ、futureshop、WooCommerce、Adobe Commerce、独自開発のECシステムなどがあります。
移行作業では、商品や顧客などのデータだけでなく、ポイント、会員ランク、定期購入、予約販売、配送条件、基幹システム連携など、現在のサイトが持つ機能と日々の運用も確認します。現在の仕組みをすべて再現するのではなく、継続する機能、変更する機能、廃止する機能を整理することが重要です。
新規制作との違い
ShopifyでECサイトを新規制作する場合は、商品構成、購入導線、決済、配送、運用方法などをゼロから設計できます。他カートから移行する場合は、既存の顧客や注文を守りながら切り替える必要があり、移行元とShopifyの仕様差を調整する作業が加わります。
ShopifyからShopifyへのリニューアルとの違い
Shopify同士では基本的なデータ構造が共通しますが、他カートからの移行では商品オプション、カテゴリー、顧客情報、注文ステータスなどの形式が異なります。移行元のデータをShopifyで利用できる形に変換することが必要です。
2. Shopifyへの移行を検討する主な理由
現在のECカートでは機能を拡張しにくい
EC事業が成長すると、定期購入、レビュー、レコメンド、会員管理、マーケティング、在庫連携など、必要な機能が増えます。ShopifyはアプリやAPIを利用して機能を拡張できます。ただし、月額費用、アプリ同士の干渉、表示速度、サポート体制を確認し、必要な機能だけを選ぶことが重要です。
デザインや購入導線を改善したい
移行を機にサイト構成やデザインを見直せば、商品を探してから購入するまでの導線を改善できます。既存デザインをそのまま再現するのではなく、アクセス解析や問い合わせを確認し、改善点を整理して設計します。
運用や保守の負担を軽減したい
Shopifyはクラウド型のECプラットフォームで、サーバーの保守や基本的なシステム更新をShopify側が行います。一方、テーマ、独自開発機能、外部連携については公開後も保守が必要です。
海外販売や多言語販売に対応したい
Shopifyでは販売地域に応じた言語、通貨、ドメイン、価格などを管理しやすくなります。ただし、販売地域ごとの法令、税、関税、配送、返品対応まで自動的に解決されるわけではありません。
外部サービスとの連携を強化したい
在庫管理、受注管理、配送、会計、顧客管理、メール配信などを連携できれば、作業時間や入力ミスを減らせます。連携可能なデータ、同期方向、タイミングを事前に確認します。
3. Shopifyへ移行できる主なデータ
移行できるデータは、移行元のカート、保存形式、契約内容、利用する移行方法によって異なります。現行サイトのデータを一覧化し、「移行する」「移行せず旧環境で保管する」「Shopifyで再設定する」に分けます。
商品情報
商品名、説明文、価格、SKU、バーコード、在庫数、重量、商品画像、オプション、バリエーション、公開状態、SEOタイトル、メタディスクリプションなどが主な対象です。商品構造がShopifyの仕様に合うかも確認します。
顧客情報
氏名、メールアドレス、電話番号、住所、顧客タグなどを移行できる可能性があります。一方、既存カートのログインパスワードは原則としてShopifyへ移行できないため、採用する顧客アカウントの仕組みに合わせて、ログイン方法やパスワード設定を案内します。
過去の注文履歴
移行アプリやAPIで移行できる場合がありますが、移行元の注文ステータスや決済情報を完全に同じ状態で再現できるとは限りません。商品、顧客、過去の注文の順で取り込むことで、データを関連付けやすくなります。
カテゴリー、ブログ記事、固定ページ
カテゴリーはShopifyのコレクションとして再設計します。ブログや固定ページでは、本文だけでなく、タイトル、見出し、画像、内部リンク、公開日、URL、メタ情報も確認します。
個別対応が必要になりやすいデータ
- ログインパスワード
- クレジットカード情報
- ポイント残高・会員ランク
- 定期購入契約
- クーポン
- レビュー・お気に入り
- 問い合わせ履歴
- 独自項目
4. Shopifyへの移行方法
手作業で登録する
商品数やページ数が少ない場合に向きます。不要な商品や古い説明文を整理できますが、件数が多いと時間がかかり、入力ミスも起こりやすくなります。
CSVファイルを使う
商品や顧客をまとめて登録できます。ただし、移行元のCSVをそのまま読み込めるとは限りません。項目名、文字コード、日付、商品オプション、画像URLなどをShopifyの形式に変換し、少量でテストします。
移行アプリを利用する
商品、顧客、注文をまとめて移行できる場合がありますが、すべての独自項目に対応するとは限りません。テスト移行を行い、実データの変換結果を確認します。
APIや独自プログラムを利用する
大量・複雑なデータや基幹連携があるサイトに向きます。柔軟な変換ができますが、設計、開発、テストに時間と費用がかかります。
制作会社へ依頼する
会員制度、定期購入、ポイント、外部連携がある場合に適しています。現在のカート名、データ件数、利用機能、外部連携、希望公開日を伝えて作業範囲を整理します。
どの方法を選ぶ場合も、全件移行の前に代表的なデータでテストし、移行結果と所要時間を確認することが重要です。
5. Shopifyへの移行前に確認すること
現行サイトのデータ量
商品、バリエーション、画像、顧客、注文、カテゴリー、記事、レビューなどの件数と構造を確認します。不要なデータを整理してから移行すると、Shopifyで管理しやすくなります。
利用中の機能と外部サービス
レビュー、お気に入り、再入荷通知、ギフト、予約販売、定期購入、会員ランク、ポイント、帳票、メール配信、広告タグなどを一覧化し、Shopifyの標準機能、アプリ、外部サービス、独自開発のどれで実現するか決めます。
決済方法と配送設定
現在の決済手段を継続できるか確認します。配送地域、送料無料条件、重量・サイズ別送料、温度帯、日時指定、複数拠点、海外配送なども整理します。
基幹システムや在庫管理との連携
連携するデータ、流れる方向、タイミング、エラー確認方法、商品コードや顧客IDの一致条件、費用まで調査します。
現行カートの契約とデータ出力期限
旧カートを先に解約すると、必要なデータを取得できないことがあります。契約終了日、解約期限、データ保存期間、ドメイン、メールの管理先を確認し、公開後の確認が終わるまで旧環境を保持します。
6. Shopifyへの移行手順
- 現行サイトを調査する：データ、機能、運用、外部連携、URLを把握します。
- 移行要件を整理する：移行対象、再設定する機能、公開日、担当者を決めます。
- Shopifyストアを開設する：契約名義、ストア情報、管理権限を設定します。
- サイト構成とデザインを設計する：既存サイトの課題を踏まえて、商品を探し購入するまでの導線を見直します。
- 移行データを整理する：重複、欠損、不要なHTML、古い情報を修正します。
- 少量のデータでテスト移行する：通常データだけでなく、複雑な商品・顧客・注文も含めて検証します。
- デザインと必要機能を実装する：テーマ、アプリ、決済、配送、通知、外部連携を設定します。
- 本番データを移行する：商品、顧客、過去の注文の順に取り込み、関連付けを確認します。
- 決済・配送・通知をテストする：実際の購入からキャンセル・返金まで確認します。
- ドメインを切り替えて公開する：差分データを反映し、公開後の実環境でも再確認します。
本番移行後も旧サイトで注文や会員登録が発生する場合は、公開直前に差分データを追加で移行します。誰が、どの時刻のデータを、どの手順で反映するかまで決めておきましょう。
7. 商品データを移行するときのポイント
商品名と説明文を整理する
古いキャンペーン情報、販売終了したサービス、不要な装飾タグを確認します。移行元のHTMLをそのまま取り込むとレイアウトが崩れる場合があります。
SKUと商品コードを統一する
同じSKUの重複、表記ゆれ、空欄を確認します。在庫、倉庫、受注管理と連携する場合は特に重要です。
バリエーションを変換する
サイズ、色、容量などをShopifyの商品オプションとバリエーションに合わせます。価格、SKU、在庫、重量、画像が正しく紐付くか確認します。
商品画像を確認する
欠落、商品との組み合わせ、表示順、画質、不要画像、代替テキストを確認します。URL経由で移行する場合は、元画像にアクセスできる間に作業します。
カテゴリーをコレクションへ再設計する
商品タイプ、ブランド、用途、価格帯など、顧客が探す条件を基準に設計します。自動コレクションを使う場合は、商品タイプやタグの登録ルールを統一します。
8. 顧客情報を移行するときのポイント
移行対象を決める
氏名、メールアドレス、電話番号、住所、会員区分、購入回数、ポイント、メール配信同意などを確認し、標準項目、顧客タグ、メタフィールド、外部アプリのどこで保持するか決めます。
重複や不完全なデータを整理する
同じ顧客の重複、メールアドレスの空欄、住所の表記ゆれを確認します。安易に統合せず、氏名、電話番号、住所、購入履歴も見て判断します。
ログインパスワードの扱いを決める
移行後にアカウント有効化やパスワード設定が必要な場合は、リニューアル日、設定理由、操作方法、案内メールの時期、問い合わせ先を準備します。
メール配信の同意情報を確認する
顧客情報を移行しただけで、すべての顧客へ販促メールを送れるわけではありません。既存サイトで取得した同意状況を適切に引き継ぎます。
個人情報を安全に取り扱う
作業ファイルのアクセス権限、受け渡し方法、保存期間、作業後の削除方法を決めます。移行後は顧客がアカウントを利用できるかまでテストします。
9. 注文履歴を移行するときのポイント
過去の注文履歴は、顧客対応、返品・交換、売上分析、再購入の確認などに使われます。ただし、すべての注文を移行すればよいとは限りません。利用目的と保存期間を整理し、必要な範囲を決めることが重要です。
注文履歴を移行する目的を明確にする
顧客がマイページで過去の購入内容を確認するためなのか、運営側が問い合わせ対応で参照するためなのかによって、必要なデータが変わります。旧カートを参照用に一定期間保持できる場合は、すべての履歴をShopifyへ移さない選択肢もあります。
移行対象期間を決める
長年運営しているECサイトでは、注文件数が非常に多くなることがあります。全期間、直近数年、対応が継続している注文だけなど、業務上必要な範囲を決定します。
商品・顧客との紐付けを確認する
注文履歴を正しく表示するには、注文内の商品と購入者が、Shopifyの商品・顧客データに対応している必要があります。そのため、商品、顧客、過去の注文の順で移行し、SKU、メールアドレス、顧客IDなどの対応関係を確認します。
注文ステータスを変換する
移行元とShopifyでは、入金待ち、発送準備中、発送済み、キャンセルなどのステータス体系が異なる場合があります。移行元の各ステータスをShopifyでどの状態として扱うか、対応表を作成します。
決済情報の扱いに注意する
過去の注文情報を移行できても、決済処理そのものやクレジットカード情報を移せるわけではありません。移行済みの注文に対して返金や追加請求が必要になった場合、旧決済サービス側での対応が必要になることがあります。
移行結果を件数と内容の両方で確認する
移行前後の注文件数や合計金額を照合し、代表的な注文を個別に確認します。商品、数量、価格、割引、送料、税、顧客、注文日時、配送先などが正しく反映されているかを調べます。
10. 会員・ポイント・クーポンの移行
会員制度やポイントは顧客の継続利用に関わるため、移行時の説明不足やデータの不一致が不満につながりやすい部分です。現在の制度をそのまま再現するのか、移行を機に見直すのかを早めに決めます。
会員制度を再設計する
一般会員、優良会員、卸会員などの区分がある場合は、それぞれの条件と特典を整理します。会員限定価格、購入制限、限定商品、送料無料などをShopifyでどのように実現するか検討します。
現在の制度が複雑になりすぎている場合は、移行を機に利用実績の少ない特典や例外処理を整理すると、運用負担を減らせます。
ポイント残高を引き継ぐ
ポイントを移行する場合は、顧客を識別する情報とポイント残高を対応させ、Shopifyで使用するポイントアプリへ登録します。アプリによってデータ形式や登録方法が異なるため、導入前に移行可否を確認します。
移行基準日、移行後の有効期限、端数処理、移行中に付与・利用されたポイントの扱いも決めておきます。本番移行後に発生した差分を反映する手順も必要です。
会員ランクを移行する
会員ランクは、顧客タグや会員管理アプリなどを利用して管理します。ランク名だけでなく、判定期間、購入金額、更新時期、降格条件、特典内容まで整理します。
クーポンを再設定する
利用中のクーポンがある場合は、コード、割引内容、対象商品、利用条件、期限、利用回数を確認します。旧サイトで発行したコードをShopifyでも利用できるようにするのか、新しいコードを発行するのかを決めます。
顧客へ事前に案内する
ポイント、会員ランク、クーポンの条件が変わる場合は、変更内容と適用日を事前に知らせます。案内には、旧サイトでの最終利用日、新サイトの公開日、引き継がれる残高や特典、顧客側で必要な操作、問い合わせ先を記載します。
11. 定期購入を利用しているサイトの移行
定期購入の移行は、通常の商品や顧客データよりも難易度が高くなります。顧客情報だけでなく、契約内容、次回注文日、配送周期、割引、決済情報を継続して管理する必要があるためです。
契約中の定期購入を調査する
契約件数、対象商品、配送周期、数量、割引率、次回注文日、スキップ・休止状況、支払い方法を確認します。解約済みや長期間停止中の契約を移行対象に含めるかも決めます。
Shopifyで利用する定期購入サービスを選ぶ
定期購入アプリごとに、対応する決済方法、マイページ機能、配送周期、商品変更、スキップ、割引、外部連携などが異なります。現在の仕組みを再現できるかだけでなく、公開後の運用やサポートも含めて比較します。
決済情報を引き継げるか確認する
クレジットカード情報は厳重に管理されており、事業者がCSVで出力して自由に移行できるものではありません。利用中の決済サービス、移行先のサービス、契約条件によっては、安全な方法で決済情報を移管できる場合がありますが、個別の確認が必要です。
引き継げない場合は、顧客に新しいサイトで支払い方法を再登録してもらいます。再登録率を高めるため、案内メール、手順ページ、問い合わせ対応を準備します。
移行中の二重注文を防ぐ
旧システムとShopifyの両方で定期注文が生成されると、二重請求や二重発送につながります。旧契約を停止する日時と新システムで開始する日時を契約ごとに管理します。
顧客への影響を最小限にする
配送日、価格、割引、送料、決済日などが変わる場合は、顧客が判断できるように変更点を明確に伝えます。必要に応じて同意の取得や再申込みの手続きを設けます。
少人数で事前テストする
本番移行前に、社内アカウントなどを使って申込み、決済、注文生成、通知、スキップ、商品変更、解約まで確認します。初回注文だけでなく、2回目以降の継続処理もテストすることが重要です。
12. Shopify移行時のSEO対策
他カートからShopifyへ移行すると、URL構造やサイト内部のHTMLが変わります。対策を行わずに公開すると、検索エンジンが旧ページと新ページの関係を判断できず、検索流入が減少する可能性があります。
旧URLと新URLの対応表を作る
現行サイトのURLを一覧化し、Shopifyで対応する新URLを決めます。商品、カテゴリー、固定ページ、ブログ記事だけでなく、検索流入や外部リンクがあるページも対象にします。
301リダイレクトを設定する
URLが変わるページには、旧URLから関連する新URLへの301リダイレクトを設定します。すべてをトップページへ転送するのではなく、原則として内容が最も近いページへ転送します。
販売終了商品に後継商品がある場合は後継商品へ、同じカテゴリーに代替商品がある場合は関連コレクションへ転送するなど、利用者にとって自然な移動先を選びます。
タイトルとメタディスクリプションを引き継ぐ
検索流入のある商品や記事では、既存のタイトル、メタディスクリプション、見出し、本文を確認します。成果が出ている内容を理由なくすべて変更すると、検索結果への影響を判断しにくくなります。
本文、画像、内部リンクを確認する
移行時に本文が欠落していないか、見出し構造が崩れていないか、画像の代替テキストが保持されているかを確認します。内部リンクが旧URLのまま残っている場合は新URLへ修正します。
canonicalとインデックス設定を確認する
Shopifyではcanonicalタグ、XMLサイトマップ、robots.txtなど、複数のSEO要素が自動的に生成されます。ただし、テーマやアプリによる重複出力がないか確認します。公開前のパスワード保護や検索エンジン向けの非表示設定が、公開後も残っていないかも確認しましょう。
サイトマップを送信する
公開後はShopifyが生成するXMLサイトマップをGoogle Search Consoleへ送信し、新しいURL構造を検索エンジンへ伝えます。主要ページがサイトマップに含まれているかも確認します。
公開後の検索状況を監視する
公開後はGoogle Search Consoleやアクセス解析で、インデックス状況、クロールエラー、404エラー、検索表示回数、クリック数、自然検索からの流入数を確認します。
検索順位は公開直後に一時的に変動することがあります。問題を早期に発見できるよう、公開前のデータを保存し、公開後と比較できる状態にしておきます。
13. ドメインとメールの切り替え
現在使用している独自ドメインは、Shopifyへの移行後も継続して利用できます。ただし、ドメインの接続先を変更する際に設定を誤ると、ECサイトへアクセスできなくなったり、同じドメインを使ったメールが受信できなくなったりする可能性があります。
ドメインの管理先を確認する
まず、ドメインを取得・管理している事業者と、DNSを管理しているサービスを確認します。現行カートの運営会社、レンタルサーバー、ドメイン取得サービスなど、契約先と管理先が異なる場合があります。
管理画面のログイン情報が分からない場合は、公開直前ではなく、移行計画の初期段階で確認しておきましょう。
接続と移管の違いを理解する
既存ドメインをShopifyで利用する方法には、主に「接続」と「移管」があります。
接続では、現在のドメイン管理事業者との契約を維持し、DNSレコードを変更してShopifyを表示させます。移管では、ドメインの管理自体を対応するサービスへ移します。どちらを選んでも同じ独自ドメインを利用できますが、更新や請求を管理する場所が異なります。
DNS設定を事前に整理する
DNSには、ウェブサイトだけでなく、メール、ドメイン認証、外部サービスなどの設定が登録されていることがあります。変更前に現在のDNSレコードを保存し、Shopify接続のために変更する項目と、維持する項目を分けます。
既存のメールを継続利用する場合は、MXレコードやメール認証に関するレコードを不用意に削除しないよう注意します。
切り替えの日時と担当者を決める
DNSの変更がインターネット全体へ反映されるまでには時間がかかることがあります。アクセスと注文が比較的少ない時間帯を選び、ドメイン担当者、Shopify担当者、メール担当者が連絡を取れる状態で作業します。
SSLと表示先を確認する
ドメイン接続後は、SSL証明書の状態を確認し、HTTPSで安全にアクセスできるかテストします。wwwあり・なしの両方、主要ページ、カート、チェックアウトまで確認します。
メールの送受信を確認する
サイトが表示されるだけで作業完了と判断せず、同じドメインを使うメールアドレスで送信と受信をテストします。注文通知、問い合わせ、顧客への自動メールに使用する送信元アドレスも確認します。
14. 移行中の注文停止時間を短くする方法
ECサイトを長時間停止すると、売上機会を失うだけでなく、顧客に不安を与える可能性があります。一方、旧サイトと新サイトを同時に動かしたまま切り替えると、注文や在庫の差分が生じます。停止時間を短くするには、事前準備と差分管理が重要です。
テスト移行と本番移行を分ける
公開直前に初めてデータを移行すると、エラーの修正に時間がかかります。事前に同じ手順でテスト移行を行い、変換ルール、処理時間、確認方法を確定しておきます。
本番では検証済みの手順を再実行することで、作業時間とトラブルを減らせます。
事前に移せるデータを移行する
商品説明、過去のブログ記事、固定ページなど、公開直前まで変化しにくいデータは先に移行できます。公開直前には、在庫、顧客、未処理注文など、変動するデータへ作業を集中させます。
差分データの移行方法を決める
最初のデータ出力後に、旧サイトで新しい注文、顧客登録、商品更新が発生します。この差分をどの日時から抽出し、誰が、どの方法でShopifyへ反映するか決めておきます。
注文番号、更新日時、顧客IDなど、差分を識別できる項目を事前に確認します。
注文受付を停止するか判断する
差分を自動または確実に移行できない場合は、短時間だけ旧サイトの注文受付を停止する方法があります。停止中は、メンテナンス中であること、再開予定時刻、問い合わせ先を表示します。
在庫の基準時刻を決める
複数の販売チャネルや実店舗で在庫を共有している場合、どの時点の在庫をShopifyへ反映するかを決めます。切り替え直前に在庫を確定し、公開後に受注できる数量と実在庫が一致するようにします。
旧サイトをすぐに削除しない
公開後に注文や顧客情報の確認が必要になることがあります。旧サイトは一般公開を停止しても、管理者が参照できる状態で一定期間保持すると、問い合わせや移行漏れへ対応しやすくなります。
公開当日の確認表を用意する
担当者、開始時刻、作業順序、確認項目、問題発生時の連絡先、切り戻しの判断基準をまとめます。作業を記憶に頼らず、確認結果を記録しながら進めることが重要です。
15. Shopify移行で起こりやすい失敗
Shopifyへの移行で起こる問題の多くは、作業そのものよりも、事前調査や確認範囲の不足から発生します。代表的な失敗を知り、計画段階で対策しましょう。
移行対象データを把握していない
商品と顧客だけを想定していたものの、制作開始後にポイント、レビュー、定期購入、独自項目などの存在が判明するケースです。追加のアプリや開発が必要になり、費用と期間が増えます。
現行サイトの管理画面だけでなく、運用担当者への聞き取りを行い、表から見えない業務も確認します。
現在のサイトをそのまま再現しようとする
移行元とShopifyでは機能やデータ構造が異なります。細かな仕様まで完全に再現しようとすると、過剰なカスタマイズによって費用と保守負担が大きくなることがあります。
機能の目的を確認し、Shopifyに適した方法へ置き換えられないか検討します。
必要な機能を後から追加する
デザインが完成してから、定期購入、ギフト、複雑な送料、基幹連携などを追加すると、画面やデータ設計のやり直しが発生する場合があります。事業上欠かせない機能は、サイト構成を決める前に確定します。
顧客パスワードをそのまま移行できると思っている
顧客情報が移行できても、既存パスワードをそのまま利用できるとは限りません。案内を準備せずに公開すると、ログインできないという問い合わせが集中します。
SEOの対応を公開直前に始める
旧URLを取得できない、対応する新ページが決まっていない、タイトルや本文が欠落していると、適切なリダイレクトを設定できません。旧URLの収集と新URLの設計は、制作初期から進めます。
ポイントや定期購入を後回しにする
ポイント残高や定期契約は、顧客の権利や継続的な決済に関わります。移行可否の確認に時間がかかることもあるため、早い段階で利用サービスへ問い合わせます。
公開前のテストが不足している
トップページや商品表示だけを確認し、決済、送料、税、メール、在庫、キャンセル、返金までテストしていないケースがあります。通常注文だけでなく、割引、会員、複数配送条件なども確認します。
旧カートを早く解約してしまう
公開直後に過去の注文や設定を確認する必要が生じても、解約後は管理画面へ入れないことがあります。データの確認と移行後の運用が安定してから解約します。
16. Shopifyへの移行にかかる費用
Shopifyへの移行費用は、データ件数だけでなく、デザイン、必要機能、外部システム、移行元のデータ品質によって変わります。そのため、「商品数が同じなら同じ費用」とは限りません。
データ調査・要件整理費
現行サイトのデータ、機能、運用、外部連携を調査し、移行範囲と方法を決めるための費用です。複雑なサイトほど調査項目が増えますが、この工程を省くと後の追加費用につながりやすくなります。
データ移行費
商品、顧客、注文、記事などの出力、整形、変換、インポート、検証にかかる費用です。件数に加え、バリエーション、独自項目、画像、文字化け、重複データなどによって作業量が変わります。
デザイン・テーマ制作費
既製テーマを設定する方法、テーマをカスタマイズする方法、独自デザインを実装する方法で費用が異なります。ページ数や商品ページの構成、スマートフォン対応、更新しやすさも費用に影響します。
機能実装・アプリ設定費
レビュー、ポイント、定期購入、ギフト、検索、会員限定機能などの導入費です。アプリの設定だけでなく、デザイン調整、データ移行、動作確認が必要になる場合があります。
外部システム連携費
在庫、受注、倉庫、会計、顧客管理などとの連携にかかる費用です。既存の連携サービスを使える場合と、独自開発が必要な場合では費用が大きく異なります。
SEO・リダイレクト対応費
旧URLの取得、新URLとの対応表作成、301リダイレクト、メタ情報の移行、公開後の監視などにかかる費用です。ページ数やURL構造が複雑なほど作業が増えます。
Shopifyとアプリの利用料金
制作費とは別に、Shopifyのプラン料金、アプリ料金、決済や外部サービスの利用料金が継続して発生します。初期費用だけでなく、月額・年額の運用費を一覧にして比較します。
公開後の保守・運用費
テーマやアプリの更新確認、機能改修、不具合対応、アクセス分析、販促支援などを依頼する場合は、公開後の費用も必要です。
正確な見積もりに必要な情報
- 現在利用しているECカート
- 商品・顧客・注文・記事の件数
- 移行したいデータの範囲
- 利用中の機能と外部サービス
- 定期購入、ポイント、会員ランクの有無
- 希望するデザインとページ数
- 基幹・在庫・倉庫システムとの連携
- 希望公開日
- 公開後の運用体制
制作会社へ見積もりを依頼する際は、価格だけでなく、移行対象、検証範囲、公開後の対応、別途発生する費用まで確認しましょう。
17. Shopifyへの移行にかかる期間
Shopifyへの移行期間は、サイトの規模、移行するデータ、デザイン、必要な機能、外部システムとの連携によって変わります。商品数が少なくても、定期購入や独自の会員制度があれば、調査とテストに時間が必要です。以下は一般的な制作工程を想定した目安であり、実際の期間は要件確認後に決まります。
小規模サイトの期間目安
商品数とページ数が少なく、既製テーマを活用し、複雑なデータや外部連携がない場合は、2〜3か月程度が一つの目安です。
ただし、商品画像や原稿が揃っていない場合、決済審査や社内確認に時間がかかる場合は、さらに期間が必要になります。
中規模サイトの期間目安
商品・顧客・注文データが多く、オリジナルデザイン、アプリ設定、ポイント移行などを含む場合は、3〜6か月程度が目安になります。
テスト移行を行い、データの変換ルールを修正してから本番移行へ進むため、デザイン制作とは別に検証期間を確保します。
大規模・複雑なサイトの期間目安
大量の商品・注文データ、定期購入、複雑な会員制度、複数倉庫、基幹システム連携、海外販売などを含む場合は、6か月以上かかることがあります。
要件によっては1年以上の計画になる場合もあるため、先に調査・要件定義を実施し、実現方法と段階的な公開の可否を検討します。
スケジュールに影響する主な要素
- 移行元から必要なデータを出力できるか
- データの欠損や重複がどの程度あるか
- 商品原稿や画像が揃っているか
- デザインの確認と承認にかかる時間
- 利用するアプリや外部サービスの選定
- 決済サービスの申込みと審査
- 独自機能やシステム連携の開発
- テスト結果の修正回数
- 社内担当者の確認時間
繁忙期から逆算して計画する
年末商戦、セール、新商品発売など、売上が大きくなる時期の直前に移行すると、問題発生時の影響が大きくなります。繁忙期より前に公開し、安定運用を確認できる期間を設けます。
公開希望日だけを先に決めるのではなく、テスト移行、社内確認、顧客案内、差分移行に必要な期間から逆算してスケジュールを作成しましょう。
18. Shopifyへの移行を自社で行うか制作会社へ依頼するか
Shopifyへの移行は、自社で進めることも、制作会社へ依頼することもできます。重要なのは、費用だけで判断せず、データの重要性、必要な技術、社内で確保できる時間を考慮することです。
自社での移行に向いているケース
- 商品、顧客、ページ数が少ない
- 過去の注文履歴を移行しない
- 定期購入やポイント制度がない
- 既製テーマを中心に構築する
- 複雑な送料や外部連携がない
- CSVやHTMLを扱える担当者がいる
- 移行作業とテストに十分な時間を確保できる
自社で進める場合も、最初に少量のデータでテストし、問題がないことを確認してから全件を移行します。
制作会社への依頼に向いているケース
- 商品、顧客、注文のデータ量が多い
- データ構造が複雑または不明
- 定期購入、ポイント、会員ランクがある
- オリジナルデザインが必要
- 基幹、在庫、倉庫などの外部システムと連携する
- SEOによる流入や売上への影響が大きい
- 停止時間を短くする必要がある
- 社内に移行を管理できる担当者がいない
制作会社を選ぶときの確認事項
Shopifyサイトの制作実績だけでなく、他カートからのデータ移行経験を確認します。新規制作と移行では、必要な調査やリスク管理が異なるためです。
- 同じ移行元カートの対応経験があるか
- データ調査とテスト移行を行うか
- 移行できないデータを事前に説明するか
- SEOと301リダイレクトに対応するか
- 決済、配送、通知までテストするか
- 外部システムの連携に対応できるか
- 公開当日の対応範囲はどこまでか
- 公開後の不具合や運用を相談できるか
見積もり時に伝える情報
現在のサイトURL、ECカート名、データ件数、利用機能、外部サービス、希望するデザイン、予算、公開希望日を伝えます。管理画面や出力データの確認が必要な場合は、個人情報や機密情報を安全に共有できる方法も確認します。
複数社の見積もりを比較する際は、総額だけでなく、移行対象、テスト範囲、SEO対応、アプリ料金、保守費用が同じ条件になっているかを確認しましょう。
19. Shopifyへの移行後に確認すること
ドメインを切り替えて新サイトが表示されても、移行作業は終わりではありません。公開後の実環境で、注文、通知、検索エンジン、外部システムの動作を確認します。
商品、価格、在庫
- 公開対象の商品が表示されているか
- 価格、割引、税の表示が正しいか
- バリエーションを選択できるか
- 在庫数と販売可否が正しいか
- 商品画像や説明文が欠けていないか
顧客アカウント
- 顧客がアカウントを有効化できるか
- ログインとパスワード再設定ができるか
- 住所や会員情報が正しいか
- 会員限定機能やポイントを利用できるか
- 案内メールが正しく届くか
カートと決済
複数の商品、割引、会員、配送地域、決済方法を組み合わせて注文します。決済完了後は、在庫、注文情報、自動メール、外部システムへの連携まで確認します。
配送料と税
送料無料条件、地域別送料、重量やサイズ、温度帯、離島、海外配送などを確認します。想定外の組み合わせで送料が無料になったり、購入できなくなったりしていないかを調べます。
注文・発送通知
注文確認、入金、発送、キャンセル、返金などの通知内容を確認します。旧サイト名、テスト用の文章、誤ったURLが残っていないかもチェックします。
スマートフォン表示
実際のスマートフォンで、メニュー、商品検索、商品選択、カート、チェックアウト、会員ページを確認します。画面幅だけでなく、タップしやすさや入力のしやすさも重要です。
アクセス解析と広告計測
アクセス解析、広告タグ、コンバージョン計測が公開環境で動いているか確認します。二重計測や計測漏れがないか、実際のテスト注文を使って確認します。
リダイレクトと検索エラー
主要な旧URLへアクセスし、適切な新ページへ移動するか確認します。Google Search Consoleとアクセスログで404エラーを確認し、必要なリダイレクトを追加します。
外部システムとの連携
商品、在庫、注文、発送、顧客などのデータが予定した方向とタイミングで連携されるか確認します。連携エラーが起きた場合の通知先と復旧手順も確認します。
旧カートの解約
新サイトの運用が安定し、必要なデータを保存できたことを確認してから旧カートを解約します。ドメイン、メール、決済、外部サービスが旧契約に含まれていないかも確認しましょう。
20. まとめ
他カートからShopifyへの移行は、データを移すだけではなく、現在のECサイトが持つ機能、業務、顧客体験をShopify上で再設計する取り組みです。
まず、商品、顧客、注文、ポイント、定期購入、外部システムなどを調査し、移行するものと再設定するものを整理します。そのうえで少量のデータによるテスト移行を行い、問題を修正してから本番データを移行します。
特に、顧客パスワード、決済情報、ポイント、定期購入、URLは、単純にコピーできない可能性があります。公開直前に問題が判明しないよう、早い段階で移行方法を確認することが重要です。
また、公開日をゴールにせず、公開後の注文確認、SEOの監視、外部連携、顧客対応まで含めて計画しましょう。
自社だけで判断することが難しい場合は、現在のECサイトの調査からShopifyの構築、データ移行、公開後の運用まで相談できる制作会社へ早めに相談しましょう。現行サイトのURL、利用中のカート、データ件数、必要な機能、希望公開日を整理しておくと、移行可否と見積もりを確認しやすくなります。
Shopifyへの移行に関するよくある質問
他カートの商品データはShopifyへ移行できますか？
商品名、説明文、価格、SKU、在庫、画像などは、CSV、移行アプリ、APIなどを使って移行できる場合があります。ただし、商品オプションや独自項目はShopifyの仕様に合わせた変換が必要です。
顧客のログインパスワードも移行できますか？
既存カートのログインパスワードは原則としてShopifyへ移行できません。採用する顧客アカウントの仕組みに合わせて、移行後のログイン方法やパスワード設定を顧客へ案内します。
過去の注文履歴は引き継げますか？
移行アプリやAPIによって引き継げる場合があります。ただし、注文ステータス、決済情報、顧客との紐付けを完全に再現できるとは限らないため、テスト移行が必要です。
ポイントや会員ランクは移行できますか？
利用するポイント・会員管理アプリの仕様に合わせて移行できる場合があります。顧客と残高・ランクの対応、移行基準日、有効期限、差分データの処理方法を決める必要があります。
移行中にECサイトを停止する必要はありますか？
必ずしも長時間停止する必要はありません。事前移行と差分移行を組み合わせることで停止時間を短縮できます。ただし、差分を正確に移せない場合は、短時間だけ注文受付を停止することがあります。
現在のドメインはそのまま使えますか？
既存の独自ドメインをShopifyへ接続して継続利用できます。切り替え時は、ウェブサイト用のDNS設定だけでなく、メールに関する設定を維持する必要があります。
Shopifyへの移行で検索順位は下がりますか？
URLやサイト構造が変わるため、一時的に変動する可能性があります。旧URLから新URLへの301リダイレクト、コンテンツとメタ情報の移行、サイトマップ送信、公開後の監視を行うことが重要です。
Shopifyへの移行にはどのくらいの費用と期間がかかりますか？
データ件数、デザイン、機能、外部連携によって異なります。一般的な制作工程では、小規模サイトで2〜3か月、中規模サイトで3〜6か月、大規模・複雑なサイトでは6か月以上が一つの目安です。正確な費用と期間を算出するには、現行サイトのデータと機能の調査が必要です。
