他のカートからShopifyへ移行する前に、商品・顧客・注文を「移す」「旧環境や別の保管先に残す」「形式を変えて移す」に分けます。あわせて対象期間、件数、担当者、取り込めない例外を決めておくと、移行方法と切り替え当日の作業を具体化できます。
移行の完了はファイルを読み込めた時点ではありません。商品を販売でき、必要な顧客情報を参照でき、旧注文の問い合わせにも答えられる状態を目指します。本稿では、他カートからのデータ移行でEC担当者が先に決めておきたいことを整理します。
全部を移す前に、必要な範囲を分ける
まず、移行後にどこで何をしたいかを決めます。「過去の注文を接客で確認したい」と「お客様がマイページで注文履歴を見られるようにしたい」では、必要な移行範囲が異なります。
| 扱い | 対象の例 | 決めること |
|---|---|---|
| 移す | 販売を続ける商品、必要な顧客情報、選んだ期間の注文 | 移行後の担当業務で使う項目と対象期間 |
| 残す | 旧注文の原本、過去の対応記録、元の書き出しデータ | 保管先、閲覧できる人、検索方法、保管期限 |
| 形式を変える | 商品分類、住所・電話番号の表記、会員区分 | 旧項目と新項目の対応、変換ルール、判断できない値の扱い |
「残す」は旧カートを契約したままにすることだけを意味しません。必要な情報を取り出し、権限を管理した保管先で参照する方法もあります。「形式を変える」に分けたデータは、変換後にShopifyへ移すものを含みます。
担当者・期間・件数・例外を一覧にする
移行対象の一覧にはデータを用意する人と、移行後の内容を確かめる人を記入します。作業を外部に依頼する場合でも、廃番商品を残すか、同じメールアドレスの会員をどう扱うかは、店舗側の判断が必要です。
| データ | 確認する担当の例 | 対象期間・時点 | 数える単位と例外の例 |
|---|---|---|---|
| 商品・在庫 | EC運営、商品管理 | 販売を続ける商品。価格・在庫は取得時刻も記録 | 商品数とバリエーション数。品番重複、画像不足、廃番商品 |
| 顧客 | CRM、カスタマーサポート | 移す顧客の条件と、書き出した時刻 | 顧客件数。重複、メール未登録、配信同意が不明な記録 |
| 注文 | 受注、出荷、経理 | 移す注文の開始日・終了日 | 注文件数と明細数。未出荷、返品・返金途中、キャンセル |
件数は元データの総数だけでなく「移す予定」「対象外」「判断待ち」に分けます。取り込み後は予定件数と結果を照合し、除外した理由を残します。商品数とバリエーション数、注文件数と明細数を混ぜて比較しないことも大切です。
たとえば、旧カートの商品分類をShopify向けに整理するなら、分類の対応表を作ります。行き先が決まらない商品を仮の分類へまとめるのか、担当者が確認するまで保留するのかを、変換前に決めておきます。
商品・顧客・注文で移し方は異なる
Shopifyは、商品、顧客、過去注文の順で取り込むよう案内しています。注文を商品や顧客と関連付けるためです。標準CSVですべてのデータが移るわけではなく、過去注文には移行アプリやAPIを使う方法が案内されています。ここでいうAPIはシステム同士でデータを渡す仕組みです。(Shopify公式の移行ガイド)
商品：項目を合わせてから取り込む
旧カートから書き出したCSVは、Shopifyの形式に合わせる必要があります。商品名だけでなく、品番、色・サイズ、価格、画像、在庫を対応付けます。旧データの原本を残し、変換用と取り込み用を分けておくと、元の値を確認できます。(商品のCSVインポート)
特に、移行後も在庫を更新するシステムがある場合は、どのシステムの値を正とするか決めます。商品の取り込みに成功しても、販売先への公開状態や在庫の設定が目的どおりかは別に確認します。(公式の移行チェックリスト)
顧客：会員情報とログイン方法を分ける
顧客CSVでは旧カートのパスワードや注文情報を引き継げません。累計購入金額・注文件数の欄もそのまま取り込まれる項目ではありません。顧客の基本情報を移す作業と、過去の購入実績を扱う作業を分けてください。配信同意も元の状態を確認し、移行を機に全員を購読者へ変更しないようにします。(顧客CSVの仕様)
一方、新しいお客様アカウントの標準方式はメールの確認コードでログインするため、パスワードは不要です。顧客プロフィールがあれば、そこに登録されたメールアドレスで利用できます。一律に「会員の再登録が必要」と案内せず、採用する方式に合わせて説明します。(現在のアカウント仕様) Shopify内の方式の違いは、お客様アカウントの移行ガイドで解説しています。
注文：参照用の過去注文と、処理途中の注文を分ける
過去注文は何年分をどの画面で参照したいかから範囲を決めます。採用する移行方法で、旧注文番号、顧客との関連、金額、入金・出荷・返金の状態をどう扱えるか確認します。旧注文番号から問い合わせ対象を探せる対応表も用意します。
未出荷や返金途中の注文は、切り替え後に誰がどのシステムで処理するかを個別に決めます。また、Shopifyは過去注文の取り込みでスタッフ向け新規注文メールが送られる点に注意を促しています。移行担当者は通知設定を確認し、出荷連携や顧客向け通知への影響も、採用する方法ごとに確かめます。(過去注文の取り込みと通知)
少量で試し、例外を含めて照合する
全件を扱う前に、通常の商品・顧客・注文と、例外を含む小さな組み合わせで試します。色違いの商品、メール未登録の顧客、割引や一部返金を含む注文など、実際の運用で迷いそうなものを選ぶと判断しやすくなります。
件数に加え、価格、注文金額、顧客との関連、問い合わせ時の検索、販売画面の表示を確認します。うまく取り込めなかったものは「元データを直す」「変換方法を変える」「今回は移さない」に分け、判断する担当者を決めます。
追加と上書きも別々に確認してください。商品CSVの上書きでは、含まれている任意項目の空欄が既存値を消す場合があります。再実行しても重複や意図しない上書きが起きないか、全件を扱う前に確認します。(商品データの上書き条件)
初回移行後の差分と、最後に止める時間を決める
旧ストアで営業を続ける間は、初回の書き出し後にも注文、在庫、顧客情報が変わります。その間の追加・変更分を後から反映する作業が「差分移行」です。以下は作業計画の例で、Shopifyが自動でこの流れを実行するという意味ではありません。
- 初回移行の基準時刻を残す。 いつ取得したデータか、対象期間とタイムゾーンも記録します。
- 差分の集め方を決める。 新規注文だけでなく、既存注文のキャンセル・返金、住所変更、在庫更新も対象かを決めます。追加分と更新分を見分け、同じ注文の二重取り込みを防ぐ方法を確認します。
- 最終作業の時間帯と再開条件を決める。 旧ストアの注文受付やデータ更新をいつ止めるか、最後の差分を誰が反映するか、在庫と未処理注文を誰が確認するかを決めます。
停止時間は件数と移行方法、試行時の作業時間をもとに組みます。未解決の例外が残った場合の延期判断者も決めておけば、切り替え直前に判断が止まりにくくなります。停止・再開の案内を出す担当者と問い合わせ窓口も、作業計画に含めてください。
切り替え後も旧注文を探せるようにする
問い合わせ担当者には「移行前の注文をどこで検索するか」「返金や返品はどこで処理するか」「ログインできない場合に何を確認するか」を共有します。マイページに表示する注文の範囲が変わるなら、お客様への案内も用意します。
旧データは保管する人、閲覧できる人、保管期限を決めます。旧カートを解約する前に、必要な記録が読めることを確かめてください。商品や案内ページのURLが変わる場合は、重要な旧URLと新URLの対応表を作り、転送を準備します。(移行チェックリスト)
自社で決めることと、相談が必要なこと
EC担当者が先に進められるのは、移す目的、対象期間、件数、担当者、例外、旧記録の参照方法の整理です。実データを扱う前に、この一覧を関係者で共有します。
項目の変換が複雑、処理途中の注文が多い、複数システムで在庫を更新している、営業を続けながら差分を反映したい場合は、移行方法と切り替え手順を一緒に検討する必要があります。移行元のカート名と、移したいデータの種類・おおよその件数が分かれば相談を始められます。Shopifyへのデータ移行を相談する。
