BASEからShopifyへ移行する手順と注意点｜タイミング・流れ・つまずきポイント

BASEで運営してきたショップが、Shopifyへの移行を検討するタイミングは、売上・運用・カスタマイズ要件のどれかが現状に追いつかなくなった頃にやってきます。多くの場合、規模よりも、「やりたいことが詰まる」「画面が回らない」といった現場の感覚から動きが始まります。

ただ、いざ動こうとすると、「いつが切り替えどきか」「どんな段取りで進むのか」「途中で何が起きるのか」が見えず、踏み出しきれないケースは少なくありません。

この記事では、BASEとShopifyの違いを押さえた上で、移行を考えるべきサインの見極め方、並行運用しながら切り替える流れ、そしてデータ・SEO・運用切り替えで実際に起きやすいつまずきまでをまとめました。読み終わるころには、自社の状況に当てはめて「今が動くタイミングか、もう少し先か」が判断できるようになっているはずです。

1.BASEとShopifyは、想定しているショップの姿が違う

BASEは、小規模・少人数で軽く始める運営に向いたサービスです。Shopifyは、商品数や運用人数が増えても扱える拡張余地を備えています。前提とする運営像が異なるため、ショップが育つにつれて、それまで使いやすかった側が窮屈になり、もう一方が噛み合ってくる時期が訪れます。

1-1. 料金の仕組み

BASEは売れた分だけサービス利用料が引かれるモデル、Shopifyは月額固定費を払って取引ごとの手数料を抑えるモデルです。月商が小さい段階ではBASEのほうが手元に残るお金が多く、ある月商を境にShopifyのほうが1取引あたりの負担が軽くなる地点に切り替わります。

BASEのスタンダードプランは初期費用も月額もかからない代わりに、商品が売れるたびにサービス利用料と決済手数料が差し引かれます。月商が小さいうちは「売れなければ持ち出しもない」点が安心材料になります。

Shopifyは、毎月の月額料金を払う前提で、決済手数料を抑えた料金体系です。固定費がかかる代わりに、売上が積み上がるほど1取引あたりの負担は軽くなります。

月商が伸びてもBASEを使い続けた場合、引かれる手数料は売上に比例して増え続けます。年単位で見ると、月額固定型のモデルなら抑えられたはずの金額が、毎月の利益から差し引かれていく構造です。

料金の比較は、月額の表面額ではなく、自社の売上カーブと突き合わせて行うものです。今の月商だけでなく、半年・1年後の見通しまで含めて両モデルを並べてみると、月額が安い側を選んだのに途中で利益率が逆転している、という後追いの見直しを避けられます。

1-2. 機能とカスタマイズの自由度

カスタマイズと一口に言っても、BASEで触れる範囲とShopifyで触れる範囲には、開発の自由度として大きな差があります。BASEは出来合いのパーツを組み合わせる仕組み、Shopifyはコードレベルから書き換えられる仕組みのため、同じ「カスタマイズできる」と書かれていても、いじれる範囲のスケールが別物です。

BASEは、デザインテーマと拡張機能(Apps)を組み合わせる方式で、用意された選択肢の中から組み立てます。手早く整ったショップが立ち上がる代わりに、テーマの構造を書き換えるような変更には開かれていません。

Shopifyは、テーマがLiquidというテンプレート言語で記述されていて、開発者であればコードを直接書き換えられます。アプリストアにも1万本を超えるアプリが並んでおり、機能を足す選択肢が広がっています。

「商品詳細ページに、こういう機能を足したい」「会員ランクごとに表示を出し分けたい」。用意されたパーツの組み合わせでは届かない要望が出てきたとき、両者の差が表面化します。BASEは「テーマと拡張機能の組み合わせで実現できる範囲」が決まっており、Shopifyは「コードを書けば、ほぼ何でも作れる」方向に開いています。

「今あるパーツでショップが組めれば十分」ならBASEで足ります。「自分たちのブランドに合わせて作り込みたい」「他店と差別化する売り場を作りたい」という要望が積み上がってきたら、それはShopify側でしか応えられない領域の話です。

1-3. 運用・管理画面の使い勝手

管理画面の使い勝手は、運用人数によって体感がはっきり変わります。1人で回している段階ではBASEのシンプルさが追い風になり、複数人体制に入るとShopifyの画面分離が業務の支えに回ります。1日に何度も触る画面なので、運用規模が合わない側を使い続けると、1作業ずつに余計な手間が積み重なります。商品登録、受注処理、在庫更新。その積み上がりが月末の残業時間に響きます。

BASEの管理画面は、開設後すぐに使える前提で組まれています。必要な機能が一画面にまとまっていて、迷わずに商品登録から発送までを進められます。

Shopifyの管理画面は、商品・注文・顧客・分析・アプリと領域ごとに画面が分かれた構造です。担当ごとの権限管理、CSV一括処理、APIによる外部システム連携も標準で備わっており、規模が大きくなっても各機能を独立して動かせます。

商品数が10点でも100点でも、CSV一括更新や担当者ごとの権限分けが要らないうちは、BASEの一画面完結が早道になります。商品数が数百点に近づき、出荷・カスタマー対応・在庫補充が並行で動き始めると、Shopifyの領域分割と権限管理が時短に効いてきます。

プラットフォーム選びは、機能比較表ではなく、自社の運用人数と日々の作業量から逆算したほうが外しません。日々の運用で触る回数が多い画面ほど、合わないツールを使い続けたときのストレスが、そのまま利益率を押し下げる要因になります。

2.「カスタマイズしたい」と感じたら、それが移行のサイン

移行を考え始めたとき、最初に頭に浮かぶのは「売上はどれくらいになったら?」という規模の話です。ただ、実際に判断のスイッチが入るきっかけは、売上数字より先に、運営の現場で感じる引っかかりのほうから訪れます。

2-1. Appsとテーマで詰まる場面が増えたとき

Appsとテーマで実現できる範囲を超える要望が、繰り返し出てくるようになっていれば、Shopifyを検討する理由が立ちます。

BASEの仕組み上、デザインの細部や機能の挙動は「用意された選択肢から選ぶ」形で組み立てるようになっています。Appsで足せる機能には限りがあり、テーマも編集できる範囲が決まっています。

最初は「これで十分」と感じても、ショップが育って独自のブランド表現や売り方の工夫が必要になってくると、用意された範囲では足りなくなります。

具体的にはこういった要望です。

どれも単発なら回避策があります。ただ、こうした要望が「次から次に出てくる」状態が続くと、その都度ぶつかる感覚がじわじわ蓄積します。

売上が伸びているわけでも、運用が回らなくなっているわけでもなく、ただ「やりたいことが詰まる」。この理由だけでShopifyに移る判断は十分成立しますし、伸ばす余地のあるショップほど、このパターンの詰まりが先に出ます。

2-2. 手数料負担が利益に響いてきたとき

売上が一定ラインを超えると、BASEのサービス利用料が、Shopifyの月額固定費を上回る分岐点を通過します。「売上は伸びているのに利益が薄い」と感じたら、まず疑うべきは料金モデルとの噛み合わせです。

BASEは売上に対して一定率の手数料が差し引かれる仕組みのため、月商が大きくなるほど絶対額として引かれる金額も比例して膨らみます。Shopifyは月額固定費がベースなので、売上が増えても固定費は変わらず、決済手数料が上乗せされる構造です。

ここで気を付けたいのは、「移行後の利益増」だけでなく、「移行しなかった場合に失っている利益」も判断材料に入れることです。BASEを続ければ、毎月一定額のサービス利用料が引かれ続けます。

「動かなかった月数 × 失っている利益」として手数料を見直すと、コスト比較で止まりがちな判断軸が一段変わります。移行可否は、毎月のコスト負担額の大小ではなく、月商の伸びと組み合わせて初めて答えが見えてきます。

2-3. 商品数・運用が管理画面で回らなくなったとき

商品数が増えて一括編集が回らない、複数スタッフの権限管理が破綻する、受注処理が手作業で間に合わない。こうした「運用が画面に追いつかない」状態に入っていれば、移行を本格的に動かす理由が出てきています。

BASEの管理画面はシンプルさを優先しているため、商品点数が一定を超えると一覧管理が窮屈になり、CSVでの大量更新やAPI経由の自動化といった「裏で動かす運用」がしづらくなります。

Shopifyは、商品マスター・在庫・顧客・注文・マーケティングが領域ごとに分かれており、多人数で同時に動かす運用を支える構造になっています。担当ごとの権限管理、CSV一括処理、外部システム連携も、選択肢として備わっています。

こんな状況が日常的に起きていれば、業務量に対して管理画面のキャパシティが頭打ちになっているサインです。

「画面が重い」「操作が遅い」と感じるのは、業務量に画面が追いつかなくなってきた合図です。スタッフの作業時間が膨らみ始めたなら、ツール選びより先に、運用の組み立てを見直す必要があります。

2-4. サインが出ていないなら、BASEを続けるほうが合理的

売上が伸びている途中、運用が回っている、特別な機能要望もない。この状態でBASEから動く理由はありません。Shopifyに移れば利益が増えるとも限らないため、現状のままがいちばん合理的なケースは確かにあります。

Shopifyは月額固定費がかかる前提のサービスです。売上規模が小さい段階で移ると、固定費の負担が利益を圧迫します。

また、移行作業にも、要件定義・データ移行・テーマ構築・テスト・本番切り替えと、それなりの時間と労力がかかります。これを抱えるだけの体制が組めていない時期に動かすと、目の前の運営が止まってしまうリスクのほうが大きくなります。

たとえばこういう状態です。

この4つに当てはまるなら、無理に動かなくても問題ありません。むしろ、BASEで売上と運用ノウハウを積み上げる時間にしたほうが、後々Shopifyに移ったときに動かしやすくなります。

「みんなShopifyに移っているから」という理由だけで動くと、メリットを得る前にコストだけが先に来ます。3つのサインのどれにも当てはまらないなら、移行はまだ自社の優先課題ではありません。

3.BASEを止めずに、Shopifyへ移し替えるまでの道のり

Shopifyへの移行は、BASEを止めて一気にShopifyに切り替えるのではなく、Shopifyを別環境として並行で立ち上げ、準備が整った時点で公開ドメインだけを切り替えるのが標準的な進め方です。並行立ち上げを採るのは、BASEで動いているショップの売上を一切止めずに、別環境で構築・テスト・データ移行を完了させてから本番切り替えに移れるためです。

全体の進行は4つのフェーズに分かれます。最初の要件定義をどこまで作り込めるかで、後半フェーズの手戻り量に大きな差がつきます。

3-1. フェーズ1:移行範囲と要件を固める

フェーズ1で決めるのは「BASEで動いているもののうち、何をそのまま移し、何を作り直し、何を捨てるか」です。ここを曖昧にして進むと、後半のフェーズで手戻りが連鎖します。

BASEで運用してきた中身は、商品データや顧客データだけではありません。導入してきたApps、独自に設定してきた配送・決済ルール、運用フロー、外部サービスとの連携。こうした要素のひとつひとつに、Shopifyでの引き継ぎ方の判断が要ります。

「BASEで使っていたAppsと同等の機能を、Shopifyではどう実現するか」「移行を機にやめるオペレーションはどれか」。この棚卸しが、後のフェーズの土台になります。

このフェーズで決めておきたい主な項目は次の通りです。

要件定義は地味な工程ですが、移行プロジェクト全体の手戻りリスクをここで吸収しておく工程です。現状の延長で組むより、「Shopifyに移ったあとの理想の運用」から逆算して項目を埋めていくほうが、要件の網が広く張れます。

3-2. フェーズ2:Shopifyテーマと初期設定を組む

要件が固まったら、Shopify側に器を組みます。テーマ選び、基本設定、必要なアプリの導入までを、BASEを動かしたまま並行で進めるのがこのフェーズです。

Shopifyのテーマは、無料・有料合わせて選択肢が広く、構築の出発点として「自社の業態に近いテーマ」が見つかれば、後のカスタマイズ工数を大きく圧縮できます。テーマを決めたら、ストア名・通貨・税率・配送設定・決済プロバイダといった基本設定を順に入れます。

ここで気を付けたいのは、BASEで動いているショップに一切手を入れないことです。Shopify側はあくまで「開発環境」として並行で立ち上げ、表に出るのは最後のドメイン切り替えのタイミングです。

このフェーズで主に進む作業はこのあたりです。

日本国内のECで欠かせない送り状発行、コンビニ決済・後払い決済、領収書同梱の3つは、Shopifyの標準機能には含まれず、アプリや外部の決済プロバイダで補完するのが一般的です。BASEで「最初から動いていた」感覚で進めると、このフェーズで作業量を見誤ります。要件定義で洗い出した必須アプリを、ここで実装に落とし込みます。

Shopify側の器ができれば、次フェーズのデータ移行を受け止める準備が整います。テーマと初期設定が甘い状態でデータを入れると、「テーマと噛み合わない」「設定がズレている」という手戻りが発生するため、テーマ→データの順序は崩しません。

3-3. フェーズ3:商品・顧客・注文データを移す

Shopify側の器ができたら、BASEに蓄積されているデータを移します。すべてが綺麗に移るわけではなく、「移せるもの」「手間をかければ移せるもの」「諦めるしかないもの」が分かれます。

BASEとShopifyはデータ構造が異なるため、CSVでそのまま吸い上げて流し込めるとは限りません。商品データのように比較的移しやすいものから、顧客のパスワードのようにそもそも移行不可のものまで、データ種別ごとに方法と限界が違います。

データ種別ごとの大まかな扱いは次のようになります。

データ種別ごとに「どこまで残せるか、何をショップのお客様に伝えるか」までセットで設計しておくと、移行後の混乱を抑えられます。

データ移行は「すべてを移す」ではなく、「事業継続に必要なものを確実に移す」が出発点です。何を諦め、その代わりに何を再構築するか。この判断を要件定義に立ち返って整理しておくと、フェーズ3全体のボリュームが見通せます。

3-4. フェーズ4:ドメイン切り替えとリダイレクト設計

最後のフェーズは、本番切り替え当日に向けた準備です。Shopify環境での動作確認、リダイレクト設計、そしてドメイン切り替え。この3つの段取りを、当日と前後の数日まで含めて組みます。

ドメイン切り替えはDNS設定の変更で完了しますが、各地のリゾルバキャッシュに新しい設定が行き渡るまで数時間〜数日かかります(DNS伝播)。当日になってから「決済が通らない」「URLが404を返している」では手遅れになるため、「テスト」と「リダイレクト設計」はこの手前で完了させておく前提です。

具体的にはこの順序で進みます。

切り替え当日は、決済・在庫・通知メール・トラッキングタグの動作を、リアル環境で再確認する時間も組み込んでおきます。

テスト工程は、フェーズ4の中で削りやすい工程に見えがちです。ただ、切り詰めた分のしわ寄せは、本番切り替え後のトラブル対応に集約してかかってきます。万一に備えて、切り替え前に「戻せるバックアップ」を確保しておくと、当日の判断にも余裕が出ます。

4.データ・SEO・運用切り替えで起こりがちな落とし穴

移行で本当に痛手になるのは、手順ではなく、手順を追っていても見落としやすい設計判断です。データ、SEO、運用のいずれかでつまずくと、リカバリーにかかる時間はプロジェクト本体より長くなります。

4-1. データ移行で失われやすいもの

データ移行で最初に意識しておきたいのは、技術的にも構造的にも「移せないもの」「再構築が要るもの」が一定量必ず出ることです。BASEとShopifyは、データの保管形式・保管項目・連携仕様が違うため、CSVでそのまま流し込めるとは限りません。Apps固有のデータも、移行先で同等のアプリが提供されていなければ、そのまま運べません。

実際に「失われやすい」「再投入が要る」代表例を挙げます。

5項目のうち、優先度が高いのはパスワードとポイント残高の2つです。パスワードは再設定しなければ既存顧客がログインに戻れず、ポイント残高は顧客の購買行動に直結します。お知らせメールや切り替え案内の文面も、この2つを軸に組み立てるとブレません。

データ移行は「100点を取りに行く工程」ではなく、「失う要素を事前に把握し、ショップのお客様への伝え方まで含めて設計する工程」です。「何が変わり、何をしてもらう必要があるか」をお知らせメールで先回りすると、切り替え直後の問い合わせ件数の山がなだらかになります。

4-2. リダイレクト設計を誤ると、SEO評価が引き継がれない

BASEで積み上げてきたSEO評価は、放置すると移行と同時に大きく落ちます。原因は、URL構造が変わるのに、旧URLから新URLへの誘導(301リダイレクト)を設計していないことです。

検索エンジンは、各URLにそれまでの評価(被リンクや滞在指標)を紐付けています。ドメインが同じでも、URLの中身が変われば、検索エンジンから見ると「別ページ」として扱われます。旧URLから新URLへの転送が設定されていないと、検索流入が新ページに引き継がれず、過去の検索順位もそのまま失われます。

実務上は、BASEで使っていた独自ドメインをShopifyに向け替えたあと、Shopifyの管理画面のURLリダイレクト機能で旧URLパスから新URLへの301を設定する流れになります。

リダイレクト設計でよく踏むつまずきは、次のパターンです。

切り替え後しばらくは、Search Consoleでクロールエラーの発生状況をモニタリングし、不足分のリダイレクトを追加していく運用が要ります。

SEOの被害は、検索結果に再評価が反映されるまでの期間を経て、検索流入の減少という形で遅れて顕在化します。事後に気づいてからの対応は、設計時点で予防するより手間も時間もかかります。フェーズ4の工数配分では、リダイレクト設計に最も厚みを置きます。

4-3. 切り替え直後に起こりがちなトラブル

切り替え前に念入りにテストしても、本番環境の切り替え直後には、想定外の現象が起きることがあります。「起きる前提」で備えておくと、対応コストも顧客への影響も小さくできます。

ステージング環境と本番環境では、ドメイン設定・決済プロバイダの本番モード切り替え・外部システムとの連携・キャッシュ挙動などが微妙に違います。テストで問題なかった項目でも、本番ドメインに切り替わった瞬間に動作が変わるケースがあります。

切り替え直後に踏みやすいトラブルは、次のものです。

切り替え後の48〜72時間は、運用担当が即対応できる体制を敷いておきます。問い合わせフォーム経由の連絡や、SNS・レビューでのお客様の声も、平時より丁寧にモニタリングする時間帯です。

切り替え直後のトラブル対応は、事前の予防と発生時の即応の両輪で成り立ちます。テストでカバーできる範囲には限界があり、想定外をゼロにはできません。テスト精度を上げる作業と、当日の対応体制を組む作業は、別タスクとして並行で動かしておきます。

5.よくある質問(FAQ)

移行を実際に動き出そうとしたタイミングで湧きやすい質問を、5つ取り上げます。

5-1. Q1:BASEからShopifyへの移行期間はどれくらいかかりますか?

規模やデータ量、カスタマイズ要件によって幅があるため、案件ごとの個別見積もりが前提です。要件定義に時間をかけたほうが後工程の手戻り量が減るため、トータルの所要期間は最初のフェーズの厚さに左右されます。

5-2. Q2:制作会社に依頼する場合の費用相場は?

移行範囲・データ量・テーマカスタマイズの程度で変動するため、一律の金額は出しにくい領域です。テーマカスタマイズの範囲、移行するデータの種別と量、外部連携の有無の3点を整理してから相談すると、見積もりのブレも抑えられます。

5-3. Q3:BASEとShopifyを同時に運営する並行期間は必要ですか?

ドメイン切り替え前の検証期間として、別ドメイン(例:development.〇〇.com)でShopifyを並行運用する期間は必要です。本番ドメインの切り替え自体はDNS設定の変更で完了しますが、DNS伝播の完了までは数時間〜数日かかります。「2つのショップを長期間並行運営する」必要は基本的にありません。

5-4. Q4:スタッフのShopify操作教育はどう進めればいいですか?

構築フェーズの後半から、操作マニュアル作成と並行してテスト操作の時間を取るのが無理のない進め方です。Shopifyは画面の構成がBASEと異なるため、商品登録・受注処理・在庫管理など、日常業務単位で「BASEとShopifyのどこを触るか」をまとめた対応表があると、現場が切り替え直後から手を動かせる状態になります。

5-5. Q5:移行中にBASE側の売上が落ちることはありますか?

並行期間中はBASEで通常運営を続けるため、移行作業でBASEの売上が落ちる構造はありません。気を付けたいのは、ドメイン切り替え直後の数日〜数週間で、新Shopify側でのトラブルや表示遅延が一時的な離脱を生むケースです。切り替え直後の運用体制と、想定外への備えのほうが、売上影響の主要因になります。

6.まとめ

BASEからShopifyへの移行で結果を分けるのは、構築技術よりも「事前にどこまで設計しきれたか」です。判断のきっかけになるサインは、3つの異なるレイヤーから出てきます。ブランド表現や売り方の幅といった「やりたいこと」の側、売上が伸びるほど重くなる手数料という「利益構造」の側、商品数や運用人数が増えて管理画面で捌ききれなくなる「運用基盤」の側。このどれかに、もしくは複数に当たっているなら、Shopifyへの切り替えを具体的に検討する時期です。

動くと決めたあとは、何を移し、何を諦め、何を再構築するかを早い段階で固めることが、後の手戻りを最小化します。リダイレクト設計と切り替え直後の運用体制は、データ移行と並んでプロジェクト後半の負荷を左右する分岐点です。

自社だけで論点を整理しきれない、あるいは要件の優先順位がつかない状況であれば、Shopify移行の実績がある制作会社に状況を持ち込んで整理してもらうのが、検討を前に進める実用的な選択肢になります。