SalesforceからHubSpotへの移行手順｜失敗しない進め方

SalesforceからHubSpotへの移行を検討中の方へ。本ブログでは、移行で何が移せて何を作り直すのかを整理し、失敗しない進め方を7つの手順で解説します。「データを移せば終わり」と考えていた方が、次に何をすればいいかまで分かる内容です。

移行でつまずく最大の原因は、「データを移せば終わり」という思い込みです。レコードそのものは移せても、関連付け・履歴・自動化・レポートは“移す”ものではなく“作り直す”もの。つまり移行の本体は、データの引っ越しではなく業務プロセスをHubSpotで再設計することにあります。そこでこの記事では、自社の資産を「移すもの／作り直すもの／捨てるもの」に仕分けする発想を土台に、検討すべききっかけ、7つの手順、よくある落とし穴、期間の目安、そして「いきなり完全移行しない」という中間解までを順に整理します。Salesforceを否定するのではなく、状況によってはHubSpotが合うケースもある――そんな公平な立場から、次に何をすればいいかが分かるようにお伝えします。

なぜいまSalesforceからHubSpotへの移行が検討されるのか

SalesforceからHubSpotへの移行を考え始めるきっかけには、いくつかの代表的なパターンがあります。

①総コスト（TCO）の増大です。ライセンス費そのものだけでなく、設定変更のたびに発生する運用コストや外部支援費まで含めると、想定以上に膨らんでいた――そんなケースです。Salesforceはエディションとユーザー単位で課金され、利用するクラウドごとに料金が分かれます。そのため、組織が大きくなるほど費用構造は複雑になりがちです。

②現場の利用率（アダプション）の低さです。せっかく導入したのに入力が定着せず、一部の人しか使っていない。データが溜まらないので分析もできない。よくある停滞のかたちです。

③硬直化です。項目をひとつ増やす、自動化を少し直す――そのたびに専任管理者や外部コンサルの手が必要になり、現場が自分で手を入れられない。この「変えたいのに変えられない」状態が、乗り換えの引き金になります。とりわけライセンスの更新時期は、こうした課題をまとめて見直す好機になりやすいタイミングです。

ただし、ここで公平な前提を置いておきます。Salesforceが「高い」「使いにくい」と語られるとき、その原因の多くは製品そのものの欠陥ではありません。作り込み過ぎ・管理体制の不足・アダプション不足といった運用上の問題であることがほとんどです。裏を返せば、同じ設計の姿勢のままHubSpotへ移っても、同じ轍を踏みます。HubSpotに移れば運用負荷がゼロになるわけではなく、「設計を軽く保つ運用ルール」を持てるかどうかが本質です。だからこそ「移すかどうか」を考える前に、「自社の本当の課題は何か」を見極めることが先決なのです。

移行の全体像 ― 移すもの・作り直すもの・捨てるもの

移行を考えるときにまず捨ててほしい思い込みが、「移行＝データの引っ越し」という発想です。移行とは、業務プロセスをHubSpotで再設計することだと捉え直してください。

そのうえで、自社の資産を次の3つに仕分けすると、何ができて何ができないかが一気に見通せます。

ポイントは、すべてを1対1で移そうとしないことです。データは確かに移せます。しかし、レコード同士の関連付けや、活動履歴・アトリビューション（成果に至るまでのタッチポイントの記録）、自動化、レポートは、製品ごとに設計思想が違うため「コピー」できません。これらは移行先で作り直すものです。そして、長く使ううちに誰も見なくなった項目やレポートは、移行を機に「捨てる」と決めるのが賢い進め方。全部を運び込めば、移行先がそのまま“散らかった倉庫”になってしまいます。

データモデルはそのまま写せない（Lead／Accountの壁）

3分類の「作り直すもの」を理解するうえで、避けて通れないのがデータモデルの違いです。

Salesforceは Lead（リード）／Account（アカウント）／Contact（コンタクト）／Opportunity（商談） という4つの階層を持ちます。一方、HubSpotの中心は Contact（コンタクト）／Company（会社）／Deal（取引） の3つです。主要なオブジェクトはおおむね対応していて、Account→会社、Opportunity→取引、Case→チケット、Task／Activity→アクティビティ、と読み替えられます。

最も注意すべきは、Leadの扱いです。Salesforceでは Lead と Contact が別オブジェクトとして分かれていますが、HubSpotのネイティブ連携ではLeadもContactもまとめてHubSpotの「コンタクト」に集約されます。HubSpotにも「Leads（リード）」というオブジェクトはありますが、これはSDRのプロスペクティング用の別物。標準的な連携では、Salesforceと同じ意味で「リードとコンタクトを分けて管理する」運用はそのまま持ち込めないため、リード管理の設計そのものを見直す必要があります。

さらに、HubSpotの関連付け（Associations）は双方向・多対多が基本です。Salesforceの参照関係（lookup）や、親を消すと子も消える主従関係（master-detail）のような厳格な親子階層はありません。だからデータモデルは「写経」できず、自社の業務に合わせて作り直す前提になります。なお、カスタムオブジェクトはHubSpotではEnterprise（最上位プラン）でのみ利用できる点も押さえておきましょう。

SalesforceからHubSpotへの移行 7つのステップ

ここからは実際の進め方を、7つのステップに沿って解説します。各ステップでは「ここで事故りやすい」というポイントも先回りしてお伝えします。

STEP1 現状の棚卸し

• やること：いま使っているオブジェクト・項目・自動化・レポートをすべてリストアップし、本当に必要なものだけを残す。

最初の工程は、実は「捨てるものを決める」工程でもあります。Salesforceに作り込まれた項目・自動化・レポートを一覧化し、実際に発火・利用されているものとそうでないものを仕分けます。このとき、おおまかに次の順で絞り込むと判断がぶれません。①現行の資産を一覧化し、②実際に動いている・使われているものだけを残し、③HubSpotの標準機能で代替できるものはそちらに寄せ、④本当に必要なものだけを移行・再構築の対象にする。「念のため作ったが誰も見ていないレポート」「数年前に止まったままの自動化」をそのまま運び込めば、移行先がまた同じように散らかるだけです。ここで思い切って捨てる判断をしておくことが、後工程をぐっと軽くします。なお、移行後にデータが再び形骸化しないための習慣は、HubSpotが「ゴミ箱」化するのを防ぐ5つの習慣も参考になります。

STEP2 HubSpot側の設計（プロパティマッピング・パイプライン設計）

• やること：Salesforceの項目をHubSpotのどのプロパティに対応させるか、マッピング表を作る。取引パイプラインと関連付けも設計する。

まず、項目ごとの対応表（マッピング表）を作ります。このとき注意したいのが型変換です。Salesforceの選択リスト（picklist）はHubSpotのドロップダウンや複数チェックボックスに、テキストは単一行／複数行テキストに、日付はdate、数値や通貨はnumber、チェックボックスは単一チェックボックスに、といった具合に読み替えていきます。

次に、取引のパイプラインとステージを設計し、レコード同士の関連付けも設計し直します。ここでよくある落とし穴が、参照項目がIDのまま入ってしまう問題です。Salesforceで他レコードを参照している項目は、何も考えずにエクスポートすると、人間には読めないID文字列で出てくることがあります。たとえば「担当会社」が会社名ではなく内部IDで吐き出される、といった具合です。エクスポート時に名称が出る設計にしておき、事前のマッピングとテストインポートでの検証を必ず挟みましょう。

STEP3 データ移行（エクスポート→クレンジング→インポート）

• やること：Salesforceからデータをエクスポートし、整形・クレンジングしたうえでHubSpotにインポートする。

データ移行のルートは、大きく2つあります。ひとつはCSVルート（Salesforceでエクスポート→整形・クレンジング→HubSpot標準インポート）で、自社でクレンジングをコントロールしたい場合に向きます。もうひとつはHubSpot-Salesforce公式統合経由で、統合を入れたうえでSalesforceのレコードを直接取り込む、公式サポートの移行パスです。

Salesforce側のエクスポートには、データエクスポートサービス（週次または月次でまとめて生成）や、Data Loader（条件で絞ってCSVに書き出せる）といった手段があります。具体的な操作は、【Salesforce】データのエクスポート方法をわかりやすく紹介で詳しく解説しています。

HubSpot側のインポートで、事故を防ぐためにまず押さえるべき原則は次の3つです。

1. 文字コードはUTF-8にする：日本語などの非ASCII文字を含むファイルは、UTF-8で保存しないと文字化けします（ExcelでうっかりShift-JIS保存しがちなので要注意）。
2. 一意識別子を必ず入れる：重複を防ぐ鍵です。コンタクトはメールアドレス、会社は会社名またはドメイン、取引は「取引名＋パイプライン＋取引ステージ」で識別され、Record IDがあればそれが最優先で効きます。
3. インポート順は「会社→コンタクト→取引」：この順にすると、レコード同士の関連付けが保たれやすくなります。

そのうえで、対応ファイル形式（.csv／.xlsx／.xls）やファイル容量・行数・同時実行数などには、無料／有料プランごとに上限があります。これらの具体値は更新されることがあるため、大量データを一度に流し込む前に、必ず公式の最新仕様を確認してバッチを計画してください。実際のインポート画面の流れは、「【HubSpot】boardからHubSpotへ顧客データのインポート方法」で解説しています。

STEP4 自動化の再構築

• やること：Salesforceの自動化（Flow／プロセスビルダー／ワークフロールール）を、HubSpotの機能であらためて組み立て直す。

ここは特に誤解の多い工程です。自動化はそのまま移行できません。 ロジックの考え方は移植できますが、ツール自体が別物なので、必ず作り直しになります。SalesforceのFlow定義をHubSpotに取り込む標準機能は、存在しません。

機能ごとの対応は、次のように考えます。Flow／プロセスビルダー／ワークフロールールはHubSpotワークフローへ。承認プロセスは取引承認へ。割り当てルールはワークフローの担当者振り分けへ。入力規則は必須／条件付き必須プロパティと作成フォームの設定で代替し、ステージ移動の制御はパイプラインルールで実現します。これらの機能には利用できるプラン（Professional以上、承認は上位プランなど）に条件があり、しかも仕様は変わり得るため、見積りの前に必要なプラン要件を公式で確認しておくと安全です。

ただし、HubSpotワークフローには境界もあります。たとえば保存前（before-save）の同期的なバリデーションはできず、多数のレコードをまとめて反復処理するような動きも想定されていません。Salesforceでできていたことが同じ形では実現できない場合があるので、機能の単純な置き換えではなく「目的の再実現」として設計し直すのが現実的です。

ちなみに、これは移行特有の負担ではありません。Salesforceもワークフロールールとプロセスビルダーの提供を終える方針を示しており、Salesforceを使い続ける場合でもFlowへの作り直しが必要になっていきます。「自動化は作り直すもの」というのは、いまや移行に限った話ではないのです。なお、ここでの絞り込みもSTEP1の棚卸しと同じ要領です。すべてを1対1で作り直そうとせず、本当に動いている自動化だけを対象にしましょう。

STEP5 連携ツールの付け替え

• やること：Zapierや各種API連携など、外部ツールとのつなぎ込みをHubSpot側に付け替える。

Salesforceにぶら下がっていた外部連携も、移し替えが必要です。HubSpotには多数のアプリと連携できるApp Marketplaceがあり、Operations Hub／Data Sync（ノーコードで双方向同期ができ、無料から始められます）を使えば、順次HubSpot側に寄せていけます。

ここでの鉄則は、一気に切り替えないことです。旧来の連携を残したまま新しい連携を並走させ、データが正しく流れているかを検証してから切り替える。この慎重な進め方が、いちばん安全です。

STEP6 ユーザートレーニングと並行運用

• やること：現場が新しいCRMを使えるよう準備し、一定期間は新旧を並行して運用する。

移行で見落とされがちなリスクは、技術ではなく人（定着）にあります。CRM移行プロジェクトがうまくいかない大きな要因のひとつが、機能の問題よりも現場に使われないこと、いわゆる定着の失敗だとされています。

これを防ぐには、まず経営層のスポンサー（後ろ盾）と、各部門で旗振り役になる推進担当（チャンピオン）を立てること。そして設計段階から現場を巻き込み、トレーニングは切り替え直前に駆け込みで行うのではなく、前もって計画的に実施すること。この組み合わせが効きます。

並行運用の進め方には、一斉に切り替えるビッグバン、部門や機能ごとに段階的に移すフェーズド、新旧を同時に動かすパラレルランの3類型があります。並行運用の期間は数週間程度を見込むケースが多いものの、これはあくまで目安。規模や状況によって変わります。

STEP7 切り替え・旧環境の停止

• やること：切り替え日を境に新規データは新CRMへ。旧Salesforceはすぐ消さず、検証後に停止する。

カットオーバー（切り替え）日以降、新規のレコードはすべて新しいCRMに入れます。旧レコードは並行して移行し、旧システムは原則read-only（閲覧のみ）にしておきます。

ここで重要なのが、旧Salesforceをすぐに解約・削除しないことです。go-live（本稼働開始）直後、特に最初のしばらくは、想定外の欠損や不整合が見つかりやすい時期。契約期間やデータ保全の観点からも、フルエクスポートを保管したうえで旧環境をしばらく残し、新環境が問題なく回ることを検証してから停止・解約するのが安全です。

移行でよくある落とし穴と対策

手順どおり進めても、事故は起きます。どこで・なぜ壊れるのかを、先回りで知っておきましょう。

特に壊れやすいのは、データそのものよりも「関連付け」と「履歴」です。レコードは確かに存在するのに、レコード同士の紐づきが切れている――この事故は起きやすく、しかも移行直後はパッと見では気づきにくい。そこが厄介な点です。

主な失敗パターンと対策を整理します。

特に⑦のアトリビューション履歴は要注意です。過去のタッチポイント（その成果がどの施策から生まれたか、という収益の根拠）は、意図して設計しないと移行で消えてしまいます。go-liveの時点では見えないため、見落とされやすいポイントです。何を残すかを、移行前に決めておきましょう。

そしてレポートとダッシュボードは、データと違って「移行」できず、こちらも作り直しです。SalesforceとHubSpotでは設計思想が違うため、見た目をそっくり再現しようとすると破綻します。本番化の前に作成し、Salesforceの数値と一致するかをgo-live前に検証しておく。これが、移行後の「数字が合わない」という混乱を防ぎます。

いきなり完全移行しない選択肢 ― 連携併用という中間解

ここまで読んで「移行は大変そうだ」と感じた方に、ぜひ知っておいてほしい選択肢があります。それは、いきなり完全移行しなくてもいいということです。

HubSpotは公式に、Salesforceとのネイティブ統合（双方向同期）を提供しています。実際、HubSpotは「マーケティングはHubSpot／営業はSalesforce」という併用を、主要なユースケースのひとつとして打ち出しています。つまり、完全移行を急がず、まず連携から始める進め方も成り立つわけです。

この統合では、コンタクト・会社・取引などを双方向に同期し（突合はメールアドレスで行います）、フィールド単位で同期の方向を設定したり、対象を絞った選択的な同期を行ったりできます。利用にはプラン要件（HubSpot側は有料プラン、Salesforce側はAPIアクセスと管理者権限など）があり、こちらも仕様が変わり得るため、検討時に公式で確認してください。

完全移行か連携併用かは、次のような軸で判断します。

• 営業がSalesforceの高度なカスタマイズに深く依存している → 連携併用寄り
• マーケティングを早く強化したいが、営業は当面Salesforceを続けたい → まずマーケだけHubSpotに
• ライセンスの二重負担を解消し、運用をシンプルにしたい → 完全移行
• 段階的に移してリスクを抑えたい → 連携で並走させ、徐々にHubSpotへ寄せる

ただし、連携併用には大きなトレードオフがあります。それがコストの二重化です。両方のライセンス費が継続して発生するため、「シンプルにしたい・コストを下げたい」が主目的なら、いずれは完全移行を見据える必要があります。

移行にかかる期間の目安と、内製かパートナーか

「結局どのくらいかかるのか」は誰もが気になるところです。けれども、期間は断定できません。規模、データ量、自動化の複雑さ、連携の数によって、大きく変わるからです。

あくまで目安として、小規模なら数週間、中〜大規模なら2〜3ヶ月以上を見込むケースが多い。その程度に捉えてください。これも確定的なものではなく、ケース次第です。特に、専任のオーナーが不在のまま社内のDIYで進めると、判断が滞って長期化しやすい傾向があります。

内製か、パートナーに頼むか。この判断軸は「移行できるかどうか」ではありません。「移行後に、自社で運用し続けられる人員がいるかどうか」です。移行はゴールではなくスタート。その後ずっと運用していくものだからです。運用を担える人がいないのであれば、伴走してくれるパートナーを検討すべきでしょう。

もし「社内リソースだけでは不安だ」「技術的な壁で行き詰まりそうだ」と感じられたら、ぜひ私たち株式会社ハレフルにご相談ください。

ハレフルはHubSpot認定パートナーであり、SalesforceとHubSpot双方の認定資格を持つコンサルタントが在籍しています。SHANON・Pardot・Marketoなど他社MAからの移行実績があり、データ移行だけでなく業務ロジックの再構築やカスタムコード開発・API連携まで、自社エンジニアが一貫して対応します。HubSpot社からも技術面で評価をいただいているパートナーです。

私たちが大切にしているのは、言われた通りに設定を移すのではなく、お客様が本当に実現したいことを丁寧にくみ取り、移行後の業務プロセスまで含めて最適解を提案すること。お客様が「自走」できる状態になるその日まで、プロジェクトの「成功請負人」として伴走いたします。

まず無料で相談する

逆に、HubSpotへの移行を見送るべきケース

すべての企業にHubSpotが合うわけではなく、Salesforceを使い続けることが正解の場合もあります。

次のような場合は、Salesforceの継続、あるいはHubSpotからSalesforceへの移行が向いています。複雑なCPQ（見積構成）、多段階の承認、テリトリー管理、Apex級の独自ロジックといった高度なカスタマイズや複雑な業務プロセスが必要なケース。独自オブジェクトを多数使うケース。大規模・多部門の組織や、厳格な規制業種。そして、すでにSalesforceに大きな作り込み資産を持っているケースです。

HubSpotからSalesforceへの移行が視野に入るのは、成長によって業務が複雑化し、権限の細かさ、レポートの深さ、ロジックの自由度、カスタムオブジェクトの要件などが、HubSpotの天井に当たったときです。

結局のところ、移行は「どちらが優れているか」を競うものではありません。「いまの自社にどちらが合うか」で決めるものです。

よくある質問（FAQ）

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

  規模やデータ量、自動化の複雑さによって大きく変わるため、一概には言えません。目安は本文「移行にかかる期間の目安」をご覧ください。専任オーナーの有無でも変わります。

• Q. Salesforceの自動化はそのまま移行できますか？

  できません。Flowやプロセスビルダーの定義をHubSpotに取り込む機能はなく、HubSpotワークフローなどで作り直しになります。考え方（ロジック）は移植できますが、ツールは別物です。

• Q. レポートやダッシュボードは移行できますか？

  これも移行できず、作り直しになります。設計思想が違うため見た目の再現は狙わず、本番化前に作成して、Salesforceの数値と一致するかをgo-live前に検証してください。

• Q. SalesforceのリードはHubSpotではどうなりますか？

  ネイティブ連携では、LeadもContactもまとめてHubSpotの「コンタクト」に集約されます。HubSpotにも「Leads」オブジェクトはありますが、Salesforce連携の同期先ではない別物です。リード管理の設計は見直しが前提になります。

• Q. 旧Salesforceはいつ解約していいですか？

  go-live直後は不整合が見つかりやすいため、すぐには解約しないでください。フルエクスポートを保管し、read-onlyで残したうえで、新環境を検証してから停止・解約するのが安全です。

• Q. 必ず完全移行しないといけませんか？

  いいえ。HubSpot公式のSalesforceネイティブ統合を使い、「マーケはHubSpot／営業はSalesforce」のように連携併用から始める進め方もあります。ただしライセンスが二重に発生する点には注意してください。

まとめ

最後に、要点を振り返ります。移行は「データの引っ越し」ではなく業務プロセスの再設計です。自社の資産を「移すもの／作り直すもの／捨てるもの」に仕分けし、関連付け・履歴・自動化・レポートは作り直すものと心得る。完全移行か連携併用かは自社の状況で選べばよく、Salesforceを使い続けるという選択も、立派な正解のひとつです。

株式会社ハレフルは、SalesforceとHubSpotの両方の認定パートナーとして、どちらが自社に合うか・どう移行すべきかを、片方に偏らず公平な視点でご相談に乗ることができます。私たちが目指すのは、移行後にお客様自身で運用・拡張できる「自走できる状態」です。無料で相談を受け付けておりますので、もし自社の進め方に迷われたら、お気軽にお問い合わせください。

まずは無料で相談する