SalesforceからHubSpotへの移行ガイド
判断基準からデータ移行・定着までの進め方

「決して安くない費用を払っているのに、機能のほとんどを活用できていない」
「設定が難しく、使いこなせる人が社内におらず、いつまでたっても定着しない」
「切り替えたい気持ちはある。ただ、これまでのデータが膨大で、移行に踏み切れない」

HubSpotへの移行のご相談で、いちばんよく聞く悩みがこの3つです。

費用に見合う活用ができていない。設定が難しくて、現場に根づかない。それでも、長年ためてきたデータの引っ越しを考えると、なかなか踏み切れない。この3つが重なって、「変えたいのに、動けない」という状態になっている会社が少なくありません。

最初にはっきりお伝えしたいことがあります。

Salesforceが悪いわけではありません。

Salesforceは世界で最も広く使われているCRM（顧客管理の仕組み）のひとつで、大きな組織や複雑な商流を支える力は群を抜いています。問題はツールの優劣ではなく、その費用と設定の難しさに見合う体制が、いまの自社にあるかどうか。服のサイズ選びと同じで、良い服でも体に合わなければ動きづらい、それだけの話です。

この記事では、SalesforceからHubSpotへの移行を検討している方に向けて、移行すべきかの判断基準、移行の全体像（計画→設計→データ移行→定着）、そして「データが膨大で踏み切れない」というためらいの解き方を、支援の現場でくり返し見てきた実感をもとに整理します。

まず考えたい。移行「すべきか」の判断基準

移行の話に入る前に、いちばん大事な問いから始めます。そもそも移行すべきなのか、です。

移行は小さくない仕事です。データの引っ越し、業務の組み替え、現場への説明。それだけの労力をかける価値があるかどうかは、次のような視点で判断できます。

いちばん大きな判断材料は、費用と活用のバランス

移行を検討する理由として、実際にいちばん多いのが費用の話です。ただし、大事なのは「高いか安いか」ではありません。「いま払っている費用に見合う活用が、できているか」です。

Salesforceの費用は、ライセンスのプラン、追加のオプション、ユーザー数、そして設定変更を外部へ依頼する運用費と、使い方に応じて積み上がっていく構造です。フル活用している会社にとっては妥当な投資ですが、次のような状態なら、費用と活用のバランスが崩れているサインです。

• ほとんどログインしていない人の分まで、ライセンス費用を払い続けている
• 上位プランを契約しているのに、使っているのは基本機能だけ
• 小さな設定変更のたびに外部への依頼費用がかかり、運用費が読めない
• 更新のたびに費用は増えるのに、営業の成果や業務の楽さは変わっていない

費用はライセンス料だけでなく、運用の外注費や社内の手間まで含めた「全体の費用」で見てください。そのうえで活用が一部にとどまっているなら、移行を検討する十分な理由になります。

あわせて見たい「合っていない」サイン

• 専任の管理者がいない。設定変更のたびに外部へ依頼が発生し、小さな改善が後回しになっている
• 使っている機能がごく一部。高い費用を払いながら、実際は商談の一覧管理にしか使っていない
• 入力が定着していない。営業の記録が残らず、結局Excelや個人のメモに情報が散らばっている
• レポートを作れる人が限られている。数字を見たいのに、特定の担当者に頼まないと出てこない
• マーケティングとの連携に別ツールの継ぎ足しが増えている。ツール間の連携維持だけで手間がかかっている

逆に、移行を急がなくてよい場合

一方で、次のような状況なら、Salesforceを使い続ける方が合理的なことも多いです。

• 複雑な承認の流れや独自の商流が、深い作り込みによって業務の中核として動いている
• 専任の管理者や開発体制があり、運用がきちんと回っている
• 基幹システムとの連携が広く深く、移行の影響範囲が非常に大きい

移行の全体像。4つの段階で進める

移行すると決めたら、次は進め方です。私たちは移行を「計画」「設計」「データ移行」「定着」の4段階で捉えることをおすすめしています。

いきなりデータの引っ越しから始めたくなりますが、ここはこらえてください。データ移行は4段階のうちの3番目。その前の2段階が、移行の成否をほぼ決めます。

第1段階：計画 ― 何のために移るのかを言葉にする

最初にやるのは、移行の目的をはっきりさせることです。「Salesforceをやめたい」は目的ではありません。「営業全員が自分で入力し、数字を毎週の会議でそのまま使える状態にしたい」のように、移行後にどうなっていたいかを言葉にします。

あわせて、関係者と時期の整理もこの段階で行います。契約の更新月、営業の繁忙期、マーケティング施策の予定。切り替えの時期は、これらを避けて選ぶのが基本です。

第2段階：設計 ― 旧環境の再現ではなく、あるべき形を描く

ここがいちばんの分かれ道です。設計とは、HubSpot上でどんな項目を持ち、商談の段階をどう区切り、誰がどこまで見られるようにするかを決める作業です。

やってしまいがちなのが、Salesforceの画面や項目をそのままHubSpotに再現しようとすること。Salesforceに合わなさを感じて移行するのに、その環境を写し取ってしまっては、合わない部分ごと引っ越すことになります。移行は、長年の運用で溜まった複雑さを一度リセットできる貴重な機会です。「今の業務に本当に必要な項目はどれか」からゼロベースで考え直しましょう。

第3段階：データ移行 ― 対応関係を決めて、試してから、本番

設計が固まってはじめて、データの引っ越しに入ります。SalesforceとHubSpotではデータの持ち方（オブジェクトの構造）が違うため、「Salesforceのこのデータを、HubSpotのどこに入れるか」の対応表を作るところから始めます。この対応の考え方は、後の章でくわしく説明します。

大事なのは、いきなり全件を移さないこと。まず一部のデータで試験的に移行し、件数・項目の中身・担当者の紐づきを確認してから本番に進みます。

第4段階：定着 ― 移行の完了は「使われ始めた日」

データが移り、画面が切り替わっても、移行はまだ終わりではありません。営業メンバーが日々の活動を自然にHubSpotへ記録し、会議でHubSpotの数字が使われるようになって、はじめて移行は完了します。

切り替え後の1〜2ヶ月は、質問にすぐ答えられる窓口を用意し、入力ルールを最小限に絞り、小さなつまずきをこまめに拾う。この地道な期間が、その後の何年かを決めます。

「移行しないもの」を決める勇気

データ移行の話になると、多くの方がこう考えます。「せっかく貯めたデータだから、全部持っていきたい」。

気持ちはよく分かります。ただ、支援の現場で見てきた限り、移行がこじれる原因の多くは「全部持っていこうとすること」にあります。

数年分の活動履歴、退職した担当者の古いメモ、一度も更新されていない見込み客の情報。これらをすべて移そうとすると、データの整理・変換の工数がふくらみ、移行後のHubSpotも初日から「よく分からない古いデータ」であふれます。新しい環境の気持ちよさが、最初から損なわれてしまうのです。

持っていくかどうかの判断基準

迷ったら、次の3つの問いで仕分けしてみてください。

1. 直近1〜2年で更新・参照されたか。長く触られていないデータは、移行後も触られない可能性が高い
2. 今後の営業・マーケティング活動に使うか。「いつか使うかも」は、たいてい使いません
3. 契約や法令の関係で保存が必要か。必要なら移行ではなく「保管」で対応できないかを考える

ここで大事なのは、移行しない＝捨てる、ではないということです。Salesforceのデータは一括で書き出せます。移行対象から外したデータも、CSVなどの形で書き出して社内に保管しておけば、必要になったときに参照できます。「HubSpotに入れるもの」と「書き出して保管するもの」の2つに分ける、と考えると気持ちが楽になるはずです。

オブジェクト対応の考え方 ― リードはどこへ行くのか

データ移行でいちばん質問が多いのが、この話です。SalesforceとHubSpotは、データの入れ物（オブジェクト）の構造が少し違います。まず全体の対応関係を見てみましょう。

Salesforce	HubSpot	気をつけたい点
リード	コンタクト	独立したオブジェクトがなく、ライフサイクルステージで表現
取引先責任者	コンタクト	リードと同じ入れ物に統合される
取引先	会社	ほぼそのまま対応
商談	取引	フェーズの区切り方を設計し直す好機
活動（ToDo・行動）	アクティビティ	メモ・通話・会議などの種類に振り分け
ケース	チケット	Service Hubの利用有無を先に確認
カスタムオブジェクト	カスタムオブジェクト	利用プランの確認と、そもそも必要かの見直し

最大のポイントは「リードとコンタクトの統合」

表の中でいちばん大きな構造の違いが、リードの扱いです。

Salesforceでは、見込み段階の相手は「リード」、商談化した相手は「取引先責任者」と、別々のオブジェクトで管理します。一方HubSpotでは、どちらも「コンタクト」というひとつの入れ物で管理し、その人が今どの段階にいるかを「ライフサイクルステージ」という項目で表します。見込み客も既存顧客も同じ場所にいて、札の色だけが違う、というイメージです。

移行の際は、Salesforceのリードを「ライフサイクルステージ＝リード」のコンタクトとして、取引先責任者をより進んだ段階のコンタクトとして取り込む、という対応づけが基本形になります。このとき、リードと取引先責任者に同じ人が重複して存在していないかの確認も忘れずに。統合される分、重複がそのまま持ち込まれやすいのです。

カスタム項目は「全部作り直す」前提で棚卸しを

長く使ったSalesforce環境には、カスタム項目が数百個あることも珍しくありません。これを機械的に全部HubSpotへ作ると、設計の章で触れた「旧環境の再現」に逆戻りします。項目ごとに「最後に入力されたのはいつか」「レポートで使われているか」を確認し、生きている項目だけを移す。地味ですが、ここで手を抜かないことが移行後の使いやすさに直結します。

並行稼働期間をどう設計するか

データを移したら、すぐSalesforceを解約してよいのでしょうか。ここも相談の多いところです。

結論から言うと、一定の並行稼働期間を置くのが安全です。切り替え直後は、「あの案件のデータが見当たらない」「この数字、前と合っているか」といった確認が必ず発生します。旧環境が参照できる状態にあると、こうした確認がすぐでき、現場の不安もやわらぎます。

並行稼働の期間と役割分担

期間は、組織の規模やデータ量によりますが、数週間から1〜2ヶ月程度の幅で設定する例が多いです。大事なのは長さそのものより、期間中のルールをはっきり決めることです。

• 新しい入力はHubSpotのみ。両方に入力する「二重入力」は原則やらない
• Salesforceは参照専用。過去データの確認のためだけに残す
• 終了日をあらかじめ決めて全員に伝える。「いつまでか分からない並行稼働」は疲弊のもと

逆に、並行稼働が長すぎるのも考えものです。二重入力が常態化すると現場の負担が倍になり、「どちらが正しいデータか分からない」状態が生まれます。両方の利用料を払い続ける負担もあります。並行稼働は橋であって、住む場所ではない。渡り終えたら、決めた日に旧環境の利用を終える。この区切りが定着への一歩になります。

スイッチング期間全体の目安

並行稼働を含めた、Salesforceからの切り替え（スイッチング）全体にかかる期間も、ここで押さえておきましょう。内訳の目安は次の通りです。

• 計画・設計：1〜2ヶ月。移行の目的整理と、パイプライン・項目のあるべき形の設計
• データ移行：2週間〜1ヶ月。対応表づくり→試験移行での検証→本番移行の順で進める
• 並行稼働：数週間〜1、2ヶ月。旧環境は参照専用で残し、終了日を決めて締める

合計すると通常3〜4ヶ月程度、利用規模が大きい場合やカスタム項目・連携が多い場合は半年程度を見込んでおくのが現実的です。

なお、Salesforceの契約更新日から逆算して移行計画を立てると、並行稼働の費用を最小限にできます。更新日の3〜6ヶ月前に計画を始めるのが理想です。計画段階で契約条件を確認しておきましょう。

費用は「何を・どこまでやるか」で決まる

移行にいくらかかるのか。いちばん気になるところだと思います。まず押さえていただきたいのは、移行にかかる費用が大きく2つに分かれることです。

1. ツールの利用費用。HubSpot自体のプラン利用料です。選ぶプランと利用人数によって月々の金額が決まり、移行後も継続的にかかります
2. 初期構築費用。Salesforceから移管するための作業費用です。データ移行、オブジェクトの対応設計、項目の作り直し、連携のつなぎ直しなど、切り替えを成立させるための一時的な費用です

HubSpotの月額だけを比べてしまうと、初期構築費用が抜け落ちて、あとで想定外に感じることになります。見積もりは必ずこの2つをセットで確認してください。

初期構築費用を左右する4つの要素

ツールの利用費用がプランと人数でほぼ決まる一方、初期構築費用は一律の相場を示すのが難しい費用です。金額を決めるのは、次の4つの要素です。

1. データの量と種類。コンタクトと会社だけを移すのか、商談・活動履歴・カスタムオブジェクトまで含めるのかで、作業量は大きく変わります
2. 旧環境の作り込みの深さ。カスタム項目や自動化の数が多いほど、棚卸しと設計に時間がかかります
3. 連携するシステムの数。会計ソフト、名刺管理、メール配信など、つなぎ直す先が多いほど工数が増えます
4. 自社でやる範囲と、外部に任せる範囲。ここがいちばん金額を動かします

自社でやれること、任せた方がよいこと

すべてを外部に任せる必要はありません。たとえば、移行するデータの仕分け（第3章の「持っていくかどうか」の判断)や、営業フェーズの定義の議論は、業務を知る自社メンバーにしかできない仕事です。

一方、オブジェクトの対応設計や重複データの処理、試験移行での検証といった技術的な部分は、経験の差が結果に出やすい領域です。HubSpot自体にもSalesforceからのデータ連携・取り込みの仕組みが用意されているため、シンプルな構成なら自社主導で進められることもあります。作り込みが深い場合は、設計部分だけ外部の知見を借りる、という組み合わせも現実的です。

よくあるつまずきと、その避け方

最後に、移行の現場でくり返し見てきたつまずきを4つ挙げておきます。どれも事前に知っていれば避けられるものです。

1. 旧環境の再現がゴールになってしまう

いちばん多いつまずきです。項目も画面も自動化も、前と同じに。そう進めた結果、合わなさの原因ごと引っ越してしまう。移行の目的は環境の複製ではなく、業務に合う形への作り直しです。設計の議論では「それは今も使っていますか？」と問い続けてください。

2. データを全部持っていこうとする

第3章で述べた通りです。仕分けの手間を惜しむと、移行の工数がふくらみ、移行後の環境も濁ります。「移すもの」と「書き出して保管するもの」に分けましょう。

3. 現場への説明が切り替え直前になる

ある日突然「来週からHubSpotです」と告げられれば、誰でも戸惑います。CRMの切り替えは、道具の変更であると同時に、現場の習慣の変更です。設計の段階から現場の代表者に入ってもらい、「なぜ移るのか」「何が良くなるのか」を早めに、くり返し伝える。定着の成否は、切り替えのずっと前から始まっています。

4. 移行後の責任者が決まっていない

移行プロジェクトが終わると、チームは解散します。その後、HubSpotの項目を整え、質問に答え、運用を改善していくのは誰か。ここが空席のままだと、どんなツールでも徐々に使われなくなっていきます。専任でなくて構いません。「困ったらこの人」が決まっているだけで、定着の速度は大きく変わります。

よくある質問（FAQ）

Q. 移行にはどれくらいの期間がかかりますか？

通常は3〜4ヶ月程度が目安です。利用規模が大きい場合や、カスタムオブジェクト・連携が多い場合は、3ヶ月〜半年程度を見込んでおくのが最適です。データの量、旧環境の作り込みの深さ、社内の意思決定の速さによっても変わるため、計画段階で移行の範囲を決めてから期間を確定させましょう。

Q. Salesforceのデータはすべて移せますか？

コンタクト・会社・商談・活動履歴といった主要なデータは移行できます。ただし、オブジェクト構造の違いから、そのままの形ではなく対応づけ（マッピング）が必要です。また「移せるか」と「移すべきか」は別の問いです。使っていないデータまで移すと移行後の環境が使いづらくなるため、仕分けをおすすめします。

Q. 移行中、営業活動は止まりますか？

止めずに進めるのが基本です。旧環境で通常業務を続けながら裏側で設計と試験移行を進め、切り替えのタイミングだけを短く区切ります。切り替え時期を繁忙期や大型案件の山場から外すことで、影響はさらに小さくできます。

Q. 自社だけで移行できますか？

データの構成がシンプルで、HubSpot標準の取り込み機能で対応できる範囲なら、自社主導で進めることは十分可能です。一方、カスタム項目が多い、連携システムが多い、重複データが多いといった場合は、設計と検証の部分だけでも経験者の知見を借りると、手戻りをかなり減らせます。

まとめ ― 移行は「引っ越し」ではなく「住み替え」

ここまでの内容を整理します。

移行を家の引っ越しにたとえるなら、大事なのは荷物を運ぶトラックの手配ではなく、「新しい家でどう暮らしたいか」を描くことです。全部の荷物を段ボールに詰めるのではなく、新しい暮らしに必要なものだけを選んで持っていく。それが、移行をやってよかったと言える結果につながります。

私たちは元HubSpot社員を中心とするチームとして、Salesforceからの移行のご相談を数多くお受けしてきました。「そもそも移行すべきか迷っている」という段階のご相談も歓迎です。自社の状況ならどう進めるべきか、一度整理してみたいという方は、お気軽にお声がけください。