Shopify移行でデータが失われる理由と売上を守る3つ移行設計とは

福岡ECサイト株式会社
代表 鳥井 敏史

この記事を書いた人

福岡ECサイト株式会社　代表　鳥井 敏史

ECサイト制作・AI検索対策の実務コンサルタント。15年以上にわたりECサイトの売上構造改善と集客設計を支援。売上改善・集客改善の実務支援を中心に企業のECサイト構造の再設計を行う。

専門分野

ECサイト制作 ECサイトリニューアル AI検索対策 SEO / コンテンツ設計

ECサイト改善の主な実績

・ECサイト制作歴15年以上 ・MakeShopアンバサダー ・JBEA EC業界SEO部門2025受賞 ・月商100万円 → 月商2,000万円 ・BtoB EC 月商100万円 → 月商1,000万円 ・支援企業：JR九州 / JAL / 名鉄 など

この記事の監修

福岡ECサイト株式会社　代表　鳥井 敏史

Shopify移行時にデータが消える企業が後を絶たない理由

ECサイトをShopifyに移行したら、顧客データが消えてしまった。商品情報が一部失われた。売上の分析ができなくなった。こうした声は制作現場で珍しくありません。

多くの企業は「Shopifyは高機能だから大丈夫」と考えて移行を進めます。しかし実際には、旧システムのデータ形式とShopifyの仕様が合わずに、重要な情報が欠落することが頻繁に起きています。 ここ、意外と見落とされがちな落とし穴なのです。

問題は、データ移行を単なる「技術的な作業」として捉えてしまうことです。実は、データ損失は移行設計の段階で防ぐことができます。

Shopify移行でデータ損失が発生する理由とは何か

Shopify移行でデータ損失が発生するのは、旧システムのデータ構造とShopifyのデータ構造が根本的に異なり、その差分を設計段階で整理していないからです。

多くの失敗ケースを分析すると、3つの段階でデータが消えています。1つ目は「移行前の整理不足」。2つ目は「変換ロジックの不備」。3つ目は「移行後の検証不足」。この3つは独立した問題ではなく、最初の設計ミスが後続の工程を崩壊させる連鎖になっています。 実際の現場では、このポイントで差がつきます。

福岡ECサイト株式会社が関わった移行案件でも、データロス案件の95%は「移行前にデータ構造を把握していなかった」という共通点がありました。つまり、技術的なエラーではなく、設計の欠落が本当の原因です。

旧システムのデータ構造を把握していない

最初の落とし穴は、既存システムのデータがどういう構造になっているか理解しないままShopifyへの変換作業を始めることです。

例えば、あるMakeShop運用企業のケースでは、カスタム項目で管理していた「顧客の購入傾向」という項目がありました。このデータは営業部門が分析に使っていた重要な情報だったのに、Shopify移行時に「標準項目以外は移行できない」という判断で削除されました。

実際には、このデータは正規表現を使って分析用CSVに変換することで保存可能でした。しかし事前調査がなかったため、消えてしまったのです。

• カスタム項目・カスタムメタフィールドの全リスト化がされていない
• 各項目がどの部門で、どの目的で使われているかの整理がない
• レガシーシステム独自の命名規則が定義されていない
• 関連テーブル間の連携ロジックが明示されていない

データ形式の変換ロジックが不備

2つ目の原因は、データ形式の変換ルールが曖昧なままShopifyへ投入することです。

例えば、旧システムではカテゴリが「雑貨＞季節＞夏」という3階層だったとします。Shopifyでは同じ3階層構造をサポートしていません。移行時に、どのレベルまで移行するか、子カテゴリをタグに変換するか、メタフィールドに保存するかの判断ができていないと、カテゴリ情報が不完全になります。

さらに複雑なのは、顧客データです。顧客の購買金額が旧システムでは「税込・送料込み」で記録されていたのに対し、Shopifyは「商品金額」「税金」「送料」を別項目で管理しています。変換ロジックなしに全て移行したら、売上データが二重計算されるという問題が生じます。

• 形式のマッピング表（旧項目→新項目対応表）が作られていない
• NULL値やブランク項目の処理ルールが決まっていない
• 日付形式・通貨形式などの変換ルールが定義されていない
• 重複排除のロジックが明示されていない

移行後のデータ検証が不十分

3つ目は、Shopifyへの移行が完了した後、「データが本当に正しく移行できたか」を検証していないことです。

多くの企業は「移行作業が終わった＝完了」と判断してしまいます。しかし実際には、レコード数が減っていないか、金額計算が正確か、顧客の関連情報が紐付いているか、といった項目ごとの細かい検証が必要です。

福岡で運営されていた月商5,000万円のアパレルECサイトのケースでは、移行直後の検証で「顧客データは全て移行されたが、購買履歴が旧顧客の30%で紐付いていない」という問題が判明しました。原因は、顧客ID形式の変換で自動採番ロジックが上手く動かず、一部のメールアドレスが重複判定されていたからです。この発見が移行2週間後だったため、対応に苦労しました。

• 移行前後のレコード数比較が行われていない
• 抽出データのサンプル検証（商品50件・顧客100件など）がない
• 関連データの紐付け率が確認されていない
• データの整合性チェックリストが作成されていない

Shopify移行時のデータロスは3つの移行設計で防ぐことができる

移行を売上維持の観点で設計する必要があります。 データ損失は、移行を技術的な作業として扱うから起きるのです。売上を維持するには、「移行設計」として、事前準備・変換設計・検証設計の3つの構造を作る必要があります。

第1の設計：事前整理設計（移行6週間前から開始）

最初にすべきことは、現在のシステムに「何のデータが、どこに、どの形式で存在するか」を完全に把握することです。これが移行全体の精度を決めます。

具体的には、以下の4つのドキュメントを作成します。

1. 全項目リスト表：現在のシステムで管理されている全項目（標準＋カスタム）をリスト化。各項目の用途部門・用途内容・データ型・使用頻度を記録します。BtoB向けECなら「企業コード」「契約担当者」などカスタム項目が多くなるため、ここの抜け漏れが後で大きな問題になります。
2. データ依存関係図：顧客データ→注文データ→配送データ→請求データというように、各テーブル間の関連性を図解します。Shopifyではこの関連構造が異なるため、事前に把握することが重要です。
3. データボリューム表：顧客数・商品数・注文数などの総件数、過去何年のデータを移行するかを整理します。古いデータほどフォーマットが異なることが多いため、「移行範囲をどこまでにするか」の判断基準になります。
4. 部門別データ利用状況表：営業部門は顧客購買傾向を見ているか、経理部門は何のデータを重視しているか、など部門ごとの利用目的を整理します。これがないと「不要だから削除してもいい」という誤判断が生じます。

この4つのドキュメント作成には3～4週間の時間が必要です。 急いで移行するほど、ここがおろそかになり、後で大きな問題が生じるという逆説があります。 この逆説、まさに移行プロジェクトあるあるですが、重要なポイントです。

第2の設計：変換ロジック設計（移行4週間前から開始）

第1段階で整理したデータを、Shopifyの仕様に合わせてどう変換するかの設計です。この段階が「移行設計」の最も重要な部分です。

以下の3つの変換パターンを用意する必要があります。

1. 1対1変換：旧システムの「商品名」がShopifyの「Title」に、「説明」が「Description」にそのまま対応するケース。これが最もシンプルですが、実際には30%程度しかありません。
2. 結合変換：旧システムの複数項目を組み合わせてShopifyの1項目に変換するケース。例えば「色」「サイズ」「素材」を組み合わせてShopifyのバリエーション情報にする場合です。
3. 分割変換：旧システムの1項目をShopifyの複数項目に分割するケース。例えば「顧客住所」が「番地」まで1つのフィールドなら、Shopifyの「都道府県」「市区町村」「番地」に分割する必要があります。

特に注意が必要なのは「結合変換」と「分割変換」です。ここで変換ロジックをミスると、データが不完全になります。

例えば、ある大手ECサイトの移行では、顧客の「購買金額」が旧システムでは「税込・送料込み」だったのに対し、変換時に単純に全額をShopifyの「total」に移行してしまいました。結果、売上分析が二重計算になり、経営判断に誤りが生じました。

正しくは、移行前に「旧システムの購買金額は何を含んでいるのか」を明確にし、Shopifyの「subtotal」「tax」「shipping」に分割するロジックを用意すべきでした。

この設計段階では、以下を実施します。

• マッピング表（旧項目→Shopify項目）の作成
• データ型の変換ルール定義
• NULL値・空白の処理方法決定
• 日付形式・通貨の統一
• 重複排除ロジックの策定
• データ移行スクリプト（もしくはツール）の仕様書作成

第3の設計：検証・ロールバック設計（移行1週間前から開始）

移行完了後、「データが本当に正しく移行されたか」を複数段階で検証する設計です。ここで問題を発見できれば、旧システムからの再度の移行も可能です。

実施すべき検証は3段階です。

1. 件数検証：顧客数・商品数・注文数が、旧システムと一致しているか確認。差分がある場合は、その理由を明確にします（古いデータを除外した、重複を排除したなど）。目安は、99%以上の一致率を目指します。
2. サンプル検証：商品50件・顧客100件・注文100件など、統計的に有意なサンプルを抽出して、データが正確に移行されているか人手で確認します。特に金額計算・日付・テキストの欠落がないかを見ます。
3. 関連性検証：顧客と注文の紐付け、商品とカテゴリの紐付け、注文と配送の紐付けなど、関連データが正しく連携しているか確認。これが不正確だと、売上分析やカスタマーサポートに支障が出ます。

検証で問題が見つかった場合に備えて、「ロールバック計画」も用意しておく必要があります。つまり、Shopify導入後も旧システムを一定期間保持し、問題発生時に旧データに戻せる体制を作ることです。

福岡ECサイト株式会社が支援した事例では、月商2,000万円の食品ECが移行後にデータロス問題を発見しました。その企業は事前に旧システムのバックアップを保持していたため、3日で復旧できました。一方、バックアップなしで進めた別企業は、1ヶ月かけて手動でデータを復旧する羽目になりました。

Shopify移行設計が成功する企業と失敗する企業の違い

移行設計の成功度は、移行期間の長さで決まります。短い期間で無理に進めると、どの段階でも品質が下がります。

データ損失が起きやすい企業の共通点は「移行を技術的な作業」として捉え、準備期間を最小化しようとすることです。実は、準備期間が長いほど、トラブル時の対応が楽になり、最終的には工期が短くなるという逆説があります。 これも意外ですが、現場で何度も経験する真実です。