「Salesforceを使っているが、ライセンス費用に見合った効果が得られていない」「機能は豊富だが、現場に定着しない」。こうした理由からHubSpotへの乗り換えを検討する中堅BtoB企業からの相談を、私たちは継続的に受けています。どちらのツールを選ぶべきかという前段の論点は別稿「HubSpotとSalesforce、中堅BtoBはどちらを選ぶべきか」で扱っており、本稿は「乗り換えることをすでに決めた、あるいは検討が固まりつつある」企業を対象に、移行前に決めておくべきことから、実際の移行ステップ、つまずきやすいポイント、移行後に運用を定着させる方法までを実務的に整理します。両方のツールを併用しながら連携させたい場合は、移行ではなく別稿「HubSpot Salesforce連携の構造と設定を、公式ドキュメントから読み解く」が対象になりますので、先に目的を切り分けてから読み進めることをおすすめします。本稿の内容は2026年8月時点の情報です。最新の仕様は必ず各社の公式情報でご確認ください。
〔関連資料〕移行の費用・期間・体制を着手前に固めたい方には、「HubSpot導入プロジェクト計画テンプレート（無料DL）」もあわせてご活用いただけます。
なぜ今、SalesforceからHubSpotへの移行を検討するのか
相談の内容を分解すると、動機はおおむね3つに集約されます。1つ目はコストです。Salesforceは機能を拡張するほど追加ライセンスやアドオンが積み上がりやすく、契約更新のタイミングで総額を見直した結果、想定より高くなっていることに気づくケースが少なくありません。実際に、歯科医院向けソフトウェアを開発するデンタルシステムズ株式会社は、年間2,500万円を超えるSalesforceのライセンス費用に対して「社内で定着せず、費用に見合った効果が得られていない」という課題を抱え、HubSpotへの移行によって年間2,000万円以上のコスト削減を実現したと公表しています（参照：出典「SalesforceからHubSpotへの移行で年間2,000万円以上のコスト削減事例」(2026年8月時点)）。2つ目は定着です。カスタマイズの自由度が高い分、設定や画面が複雑になりやすく、営業担当者が入力を後回しにしてデータが更新されないという声もよく聞きます。3つ目はマーケティングとの一体運用です。SalesforceはSFA・CRMとしての機能が中心で、マーケティングオートメーションは別製品との組み合わせが前提になるのに対し、HubSpotはマーケ・営業・カスタマーサービスを1つのデータ基盤で扱う設計になっています。
乗り換えた企業側の実感値としては、HubSpotが自社の比較ページで、Salesforceから乗り換えたユーザーの85%が生産性の向上を、75%がデータ管理・連携にかける時間の削減を、72%がツールの利用定着（アダプション）の向上を、それぞれ社内調査で回答したと公表しています（参照：出典「HubSpot vs Salesforce」(2026年8月時点)）。これはHubSpot自身の調査であり中立的な数値ではない点は差し引いて読む必要がありますが、「複雑さゆえに定着しない」という課題感は、私たちが現場で聞く声とも一致します。なお、HubSpotは自社顧客全般の実績として、導入から1年でリード獲得数が平均129%、成約数が平均36%、チケットのクローズ率が37%それぞれ向上したというデータも公開していますが、こちらはSalesforceからの乗り換え企業に限定した数値ではない点に注意してください（参照：出典「Switching from Salesforce to HubSpot」(2026年8月時点)）。
移行前に決めておくべきこと
移行プロジェクトが迷走する最大の原因は、着手後に「決めるべきだったこと」が次々と発覚することです。ツールの操作を覚える前に、次の4点を関係者で合意しておくと手戻りが大きく減ります。
対象データの範囲
Salesforce内の全レコードを移すのではなく、「直近◯年以内に活動があった取引先・商談のみ」「休眠から一定期間を過ぎたリードは除外」のように、移行対象を先に絞り込みます。汚れたデータをそのまま新環境に持ち込むと、HubSpot移行後も同じ問題を引きずることになります。これは連携ではなく移行そのものを扱う本稿の論点ですが、データの汚れが移行後にどう表面化するかは別稿「ツールを乗り換えても、データの汚れはついてくる。HubSpot移行で起きること」で詳しく扱っています。
オブジェクトの対応関係
SalesforceとHubSpotはオブジェクトの構造が異なるため、単純に同じ名前のもの同士を対応させるだけでは済みません。特につまずきやすいのが、Salesforceには「リード」と「コンタクト」という商談化前後の区別があるのに対し、HubSpotには単一の「コンタクト」オブジェクトしかない点です。移行前に、Salesforce側のどの状態のリード・コンタクトをHubSpotのどのライフサイクルステージに割り当てるかを決めておく必要があります。主要なオブジェクトの対応関係を整理すると、次のようになります。
| Salesforce | HubSpot | 移行時の主な論点 |
|---|---|---|
| リード（Lead） | コンタクト（未商談化） | ライフサイクルステージへの割り当て基準を決める |
| コンタクト（Contact） | コンタクト | リードと同じオブジェクトに集約されるため重複排除が必要 |
| 取引先（Account） | 会社（Company） | 親子関係（企業グループ）の扱いを決める |
| 商談（Opportunity） | 取引（Deal） | ステージ名・確度・パイプライン構成を再設計する |
| ケース（Case） | チケット（Ticket） | 基本的なチケット管理は無料でも利用可。SLAや自動ルーティング等の高度機能はService Hub有料プランが必要 |
| カスタムオブジェクト | カスタムオブジェクト | 作成にはいずれかのHubでEnterpriseプランが必要。項目定義から再設計 |
なお、カスタムオブジェクトの作成にはいずれかのHubでEnterpriseプランへの加入が必要で、Professional以下のプランでは利用できません（参照：出典「Create custom objects」(2026年8月時点)）。Salesforceでカスタムオブジェクトを多用していた企業は、移行前にプラン要件を確認しておく必要があります。
権限とデータガバナンス
Salesforceのプロファイル・権限セットの設計をそのままHubSpotのユーザー権限に置き換えることはできません。HubSpotはチーム単位・オブジェクト単位での権限管理が中心になるため、誰がどのレコードを閲覧・編集・削除できるかを、旧環境の設計を参考にしつつ新規に設計し直す前提で進めます。
移行のタイミング
Salesforceの契約更新日から逆算してスケジュールを引くのが基本です。更新月の直前に着手すると、データクレンジングやテストの時間が確保できないまま本番切り替えを迎えることになります。契約解約の通知期限も併せて確認し、移行が完了するまでは旧環境を並行稼働できる猶予を持たせておくと安全です。
移行の進め方（5ステップ）
私たちが移行プロジェクトを設計する際は、次の5ステップで進めます。
ステップ1. 棚卸し
Salesforce側の全オブジェクト・全項目を洗い出し、実際に使われている項目と、過去に作られて使われなくなった項目を仕分けます。この段階で「移行しない」と決めた項目は、後工程の作業量を大きく減らします。
ステップ2. マッピング
ソース項目・移行先プロパティ・データ型・変換ルール・担当者を一覧にした項目対応表を作成します。特にSalesforceの選択リスト（値の一覧）とHubSpotのプロパティ選択肢は完全一致しないことが多く、値の変換ルールを事前に決めておかないと、移行後に「その他」だらけのプロパティができあがります。
ステップ3. 移行の実行
HubSpotのインポートツールは、コンタクト・会社・取引・チケットなど主要オブジェクトのCSV/Excelインポートに対応しており、スプレッドシートの列をHubSpotのプロパティにマッピングして新規作成・既存更新・重複判定ができます。レコード間の関連付け（会社と取引の紐づけなど）は、インポート時の関連付け列で維持する仕組みが用意されています（参照：出典「Understand the import tool」(2026年8月時点)）。実行順序は、会社の後にコンタクト、続いて取引、カスタムオブジェクト、最後に活動履歴という順序にするのが基本です。取引をコンタクトより先に入れると、紐づけ先が存在せず関連付けが失敗するためです。
〔関連資料〕移行プロジェクトの体制・費用感を事前に固めたい場合は「HubSpot導入プロジェクト計画テンプレート（無料DL）」もご参照ください。
ステップ4. 検証
本番データを全量移行する前に、少量サンプルで移行後のレコード件数・必須項目の欠落・関連付けの正しさを確認します。特に商談金額や成約日など、レポートの集計に直結する項目は、旧環境の集計結果と新環境の集計結果を突き合わせて一致することを確認しておくと、切り替え後の「数字が合わない」という混乱を防げます。
ステップ5. 定着
移行が完了した時点はゴールではなくスタートです。旧環境のショートカットや古い操作習慣が残ったままだと、せっかく整えたデータも早期に汚れていきます。次章で運用面の定着策を扱います。
つまずきやすいポイントと対策
- リードとコンタクトの重複統合。Salesforceで別オブジェクトだったリードとコンタクトが、HubSpotでは同一人物として重複登録されやすくなります。メールアドレスをキーにした重複排除ルールを移行前に決めておきます。
- ワークフロー・自動化ロジックの再現もれ。Salesforceの承認プロセスやフローで実装していた自動化を、移行後にHubSpotのワークフローで作り直すのを忘れると、通知や自動割り当てが止まったまま気づかないことがあります。既存の自動化を一覧化してから移行に入ります。
- レポート・ダッシュボードの作り直し。集計の元になるプロパティ名やパイプラインのステージ構成が変わるため、旧環境のレポートをそのまま複製することはできません。経営会議で使う主要指標から優先的に作り直します。
- 営業担当者の抵抗。使い慣れたツールが変わること自体への心理的な抵抗は避けられません。移行の目的とメリットを事前に共有し、移行直後の一定期間は入力サポートを手厚くする体制を用意します。
- 並行稼働期間の設計不足。旧環境を即日で止めると、移行漏れに気づいた時点で確認する手段がなくなります。一定期間は旧環境を参照専用で残しておくと安全です。
移行後に効かせる運用
移行直後にHubSpotの基本機能を一通り理解できたとしても、それだけでは定着しません。実務で効かせるためには、次の3点を運用に組み込みます。
1つ目は、入力必須項目を最小限に絞ることです。Salesforceで積み上がった項目をそのまま全部必須化すると、営業担当者の入力負荷が上がり、結局入力されなくなります。経営判断とレポートに直結する項目だけを必須にします。2つ目は、ライフサイクルステージとパイプラインステージの定義を全社で統一し、マーケティングと営業の間で「どの状態がどのステージか」の解釈がずれないようにすることです。3つ目は、四半期に一度データの健全性を棚卸しする定例を作ることです。移行時にきれいにしたデータも、運用を重ねるうちに重複や欠落が発生します。HubSpotの基本的な機能構成や無料でできる範囲を改めて把握しておきたい場合は、別稿「HubSpotとは。CRM・各Hub・無料機能・料金を一気に整理」も参考になります。
まとめ。移行は「引っ越し」ではなく「作り直し」
SalesforceからHubSpotへの移行は、データをそのまま運び込む「引っ越し」ではなく、オブジェクトの対応関係・権限・ワークフロー・レポートを含めて「作り直す」プロジェクトです。本稿の要点を整理します。
- 移行の動機は、コスト・定着・マーケとの一体運用の3つに集約されることが多い
- 着手前に、対象データの範囲・オブジェクトの対応関係・権限設計・タイミングの4点を決めておく
- 移行は、棚卸し、マッピング、実行、検証、定着という5つのステップで進めます。実行順序は会社の後にコンタクト、続いて取引、カスタムオブジェクト、最後に活動履歴という順序です
- リードとコンタクトの重複、自動化ロジックの再現もれ、レポートの作り直しが特につまずきやすい
- 移行後は、必須項目の絞り込み、ステージ定義の全社統一、定期的なデータ健全性の棚卸しで定着させる
移行プロジェクトを自社の体制だけで進めるべきか、外部の実装パートナーに依頼すべきかで迷う場合は、判断軸を別稿「HubSpot導入支援パートナーの選び方。Tierではなく適合度で決める5つの判断軸」に整理していますので、あわせてご参照ください。Respectifyでは、SalesforceからHubSpotへの移行を検討する中堅BtoB企業に対して、データ棚卸しから項目マッピング、移行後の定着設計までを含めてHubSpotの導入・定着支援として伴走しています。自社の環境でどこまでの移行が必要か、概算の費用感を含めて相談したい場合は無料相談からお気軽にお寄せください。
移行プロジェクトの体制・費用・期間を着手前に固めたい方には、「HubSpot導入プロジェクト計画テンプレート（無料DL）」もご用意しています。
