SalesforceとHubSpotの連携・併用では、機能を比較する前に業務とデータの境界を決めます。段階的に移すか、一括で切り替えるかは、データの正本、同期方向、業務テストの結果で判断します。
SalesforceとHubSpotの連携・併用では、機能を比較する前に業務とデータの境界を決めます。段階的に移すか、一括で切り替えるかは、データの正本、同期方向、業務テストの結果で判断します。
ブログ目次
SalesforceとHubSpotの連携・併用では、機能を比較する前に業務とデータの境界を決めます。段階的に移すか、一括で切り替えるかは、データの正本、同期方向、業務テストの結果で判断します。
「マーケティング業務からHubSpotへ移したい」「切り替えで営業を止めたくない」「併用すると顧客データが重複しないか不安」。こうした課題がある場合、最初に確かめたいのは、両システムで誰がどの情報を更新しているかです。
SalesforceとHubSpotの連携・併用とは、両方のCRMで担当する業務を分け、必要なデータを同期しながら運用する方法です。現在の業務、データ、外部連携を棚卸しし、更新先を決められない領域は範囲を絞って検証します。切り替え対象の業務を移行先で実行でき、問題発生時の復旧手順も確認できたら、一括移行の判定へ進みます。
この記事では、連携対象の整理から移行方式の選択、併用中の同期設計、切り替え後の確認までを順に解説します。各段階で比較するものと、次へ進む条件を確認してください。本記事はHubSpotゴールドパートナーのStartLinkの「HubSpot完全ガイド」関連記事です。
連携するデータとその正本を整理したうえで、段階的移行と一括移行を比較します。併用中の重複・競合に備える方法や、切り替え後に業務が成立しているかを確かめる手順も扱います。想定している読者は、Salesforceを使っている営業企画・情報システム・マーケティングの担当者で、HubSpotへの移行を検討している方です。読み終えると、自社が段階的移行と一括移行のどちらに近いかを、判断表と設定名で整理できます。
SalesforceとHubSpotの連携を検討するときは、顧客情報や営業情報のうち、どのデータを両システムで使う必要があるかを先に決めます。連携を設定するだけでは、更新先や値の優先順位は定まりません。業務ごとに作成・更新するシステムと採用する値を決め、テストレコードで意図した結果になることを確かめてから対象を広げます。
最初に、連携したい業務とデータを対応させます。次の表は、連携可否を確認する対象の一覧です。各行について、利用環境で対象を選べるか、必要な値と関連付けを渡せるかを実際のレコードで確認します。対象を選べない場合は、そのデータが業務上必要かを確かめ、連携範囲か運用手順を見直します。
| 連携機能 | 内容 |
|---|---|
| コンタクト同期 | HubSpotコンタクトとSalesforceリード・取引先責任者の対応を確認する |
| 企業同期 | HubSpot企業とSalesforceアカウントの対応を確認する |
| 取引同期 | HubSpot取引とSalesforce商談の対応を確認する |
| アクティビティ同期 | メール開封・クリック・フォーム送信など、業務で使う履歴の反映を確認する |
| リードスコア同期 | HubSpot側のスコアをSalesforce側で使う場合、受け渡す項目と値を確認する |
| キャンペーン連携 | HubSpot側の対象者情報をSalesforceキャンペーンで使う場合、対応関係を確認する |
Salesforce経験者は、オブジェクトの対応関係から整理するとHubSpot側の構造を把握しやすくなります。ただし、名称が似ていても業務上の意味まで同じとは限りません。利用者が各画面で何を入力し、その情報を次の担当者がどう使うかまで確認します。
| Salesforce | HubSpot | 主な役割 |
|---|---|---|
| リード、取引先責任者 | コンタクト | 個人の連絡先や活動履歴を扱う業務 |
| アカウント | 会社 | 企業単位の属性や関連情報を扱う業務 |
| 商談 | 取引 | 営業案件、金額、ステージを扱う業務 |
| キャンペーンメンバー | リスト、キャンペーン関連情報 | マーケティング施策の対象や反応を扱う業務 |
| カスタムフィールド | カスタムプロパティ | 自社固有の情報を保持する業務 |
コンタクトから会社、取引、顧客化後の対応まで、必要な関連付けをたどれるかも確認します。関連付けを再現できないデータがあれば、同期範囲を広げる前に識別子とレコード作成手順を見直します。
同期方向は、HubSpotからSalesforceへ反映する項目、SalesforceからHubSpotへ反映する項目、双方で更新する項目に分けて検討します。双方で更新する項目は、競合時に採用する値と修正担当を決めてからテストします。決められなければ、更新先を片方に寄せるか、同期対象から外すかを検討します。
フィールドマッピングでは、名称、データ型、選択肢、必須条件、更新権限を対応表に記録します。例えば、同じ「業種」でも片方が自由記述、もう片方が選択式なら、値の変換方法を先に決める必要があります。変換ルールを定義できればテストし、定義できなければ入力方法か同期範囲を見直します。
次の表を使い、正本、更新担当、例外条件まで記入します。空欄が残る項目は設定へ進めず、実際の更新経路を担当部門に確認してください。
| 確認項目 | 記載する内容 |
|---|---|
| Salesforce側の項目 | オブジェクト名、フィールド名、型 |
| HubSpot側の項目 | オブジェクト名、プロパティ名、型 |
| データの正本 | どちらのシステムで更新するか |
| 同期方向 | 片方向か双方向か |
| 更新担当 | どの部門や業務が値を更新するか |
| 例外条件 | 同期しない値やレコードの条件 |
| 利用目的 | レポート、自動化、検索などの用途 |
連携前には、Salesforce側のAPI利用状況、HubSpot側の同期結果、対象オブジェクトや項目の権限を確認します。APIの割り当ては契約や設定に応じて異なるため、既存連携を含む使用状況とテスト時の変化を比較します。確認項目はAPI Request Limits and Allocationsを参照し、実際の組織に表示される値を判断材料にしてください。
更新直後の反映が必要な承認や担当者通知は、同期結果を確認してから次の処理へ進む手順にします。テストレコードが業務上必要な時点で反映されなければ、同期履歴で原因を調べます。Import and sync Salesforce recordsも確認し、必要なタイミングを満たせない業務は処理の進め方を再検討します。
カスタムオブジェクトや特殊な項目は、利用環境で対象を選択できるか、接続ユーザーに必要な権限があるかを確認します。計算結果を参照する項目は、値をどこで計算し、どこで使うかを分けて設計します。テストレコードの値が受信側に意図どおり保存されれば対象を広げ、エラーになればマッピング、入力規則、権限を確認します。
すべての機能を移行先で再現する前に、利用部門、使う業務、参照するレポートを記録します。必要な処理は入力から出力まで検証し、使われていない処理は移行対象に含める理由を確認します。
HubSpotの公式Salesforce連携は、HubSpotの上部ナビゲーションバーのMarketplaceアイコンから「HubSpot Marketplace」を開き、「Salesforce」を検索して「Install」から接続します。接続後の設定は、設定(歯車)>「Integrations」>「Connected Apps」>「Salesforce」にあります。対象は、Marketing Hub、Sales Hub、Service Hub、Data Hub、Content Hub、Smart CRMのProfessionalまたはEnterpriseです(出典:HubSpotナレッジ「Install the HubSpot-Salesforce integration」)。
接続の前に、次の3点を確認します。
設定画面の各タブと同期ルールの名称は、HubSpot Salesforce連携ガイドで詳しく整理しています。連携方式全体の位置づけはHubSpot連携ガイドが入口です。
併用か移行かで、使う機能が変わります。公式ナレッジでは、移行後もSalesforceを使い続ける場合は、Smart Transferではなく公式のSalesforce連携を使うよう案内されています。両者でレコードを照合する一意の識別子が異なるため、同時に使うとHubSpotとSalesforceの両方でレコードが重複するためです(出典:HubSpotナレッジ「Smart Transfer」)。
| 機能 | 向く状況 | 注意点 |
|---|---|---|
| Salesforce連携(継続同期) | Salesforceを営業管理に残したまま、HubSpotと双方向でデータをそろえる併用期間 | 包含リスト、同期ルール、接続ユーザーの権限を設計してから接続します |
| Smart Transfer | Salesforceから HubSpotへ、一度だけ移す移行 | Super Adminだけが実行できます。Salesforce連携と同時に使うと重複します。Smart Transferの同期接続はオフにします |
| Salesforceレコードのインポート | 特定のオブジェクトやレコードだけを取り込む | リード・コンタクトは、インポート時点ではメールアドレスだけが同期されます |
Smart Transferは、公式ナレッジでは次の4つのステップとして説明されています。入口は、メニューの「More」から「Data Management」>「Data Integration」を開き、「Transfer data」で移行元を選ぶ流れです。
この4ステップは、段階的移行と一括移行のどちらにも使えます。違うのは、段階的移行では、移行元のSalesforceを残して連携で併用する範囲が長くなる点です。移行しないと決めた領域は、Smart Transferの対象に含めず、連携で扱います。
併用中は、メール、通話、ミーティングなどの履歴をどちらで見るかも決めます。公式ナレッジには、2つの方式があります(出典:HubSpotナレッジ「Sync activities and tasks」)。
| 項目 | タイムライン同期 | アクティビティ同期 |
|---|---|---|
| 方向 | HubSpotからSalesforceへの一方向(Salesforceのタスクとして作成) | 双方向 |
| 対象 | フォーム送信、メールの送信・開封・クリック、ミーティング、通話、メモなど | タスク、営業メール、通話、ミーティング |
| 制御できる項目 | 種類ごとのオン・オフと、Salesforceのタスク種別 | 重複排除、競合解決ルール、選択同期、項目マッピング、関連付けの同期方向 |
同じ種類のイベントで両方をオンにすると、アクティビティ同期の設定が優先され、タイムライン同期は無効になります。注意点は3つあります。タイムライン同期では、マーケティングメールの開封・クリックがSalesforceのタスクとして複数作成されることがあります。Einstein Activity Captureで作られたメールは同期されません。非アクティブなユーザーに割り当てられたアクティビティはエラーになります。
段階的移行は業務や部門を区切って検証する方法です。一括移行は切り替え前に広い範囲を確認し、業務全体を移す方法です。比較するときは、移行作業に加え、併用中に生じる入力と管理、切り替え後の運用をそれぞれ確認します。
段階的移行では、先にHubSpotで扱う業務とSalesforceに残す業務を決めます。例えばマーケティング業務を先に移すなら、リードの作成・更新先、営業へ引き渡す条件、引き渡し後に修正する担当を明文化します。
次の表は、作業順序を検討するための工程例です。各工程で業務テスト、同期確認、担当者の操作確認を行い、終了条件を満たしてから次へ進みます。日程は対象範囲とテスト結果に基づいて決めてください。
| 順序 | フェーズ | 主な作業 |
|---|---|---|
| 最初 | マーケティング業務の準備 | HubSpot Marketing Hubで扱う業務の整理、Salesforceとの連携設定の検証 |
| 次 | マーケティング業務の運用確認 | リードの登録、引き渡し、リードナーチャリングの業務テスト |
| 続いて | 営業業務の準備 | HubSpot Sales Hubで扱う業務の整理、パイプライン設計 |
| 営業の一部を移す前 | 営業業務の運用確認 | インサイドセールスの操作、引き継ぎ、同期結果の確認 |
| 営業全体を移す前 | 残る営業業務の準備 | フィールドセールスの手順確認、残存データの移行テスト |
| 最後 | 移行完了の判定 | 全社の業務結果を確認し、Salesforceの利用範囲と契約を判断 |
業務の分担も工程と合わせて見直します。次の表の各行について、入力画面、更新担当、同期する項目、例外時の連絡先を決めます。ある部門の作業が完了しても、次の部門が必要な情報を受け取れなければ移行範囲を広げません。
| 段階 | HubSpotで扱う業務 | Salesforceで継続する業務 |
|---|---|---|
| マーケティング移行 | フォーム、メール、リード管理 | 商談、受注情報の管理 |
| 営業の一部移行 | 初期対応、取引作成、活動記録 | 後工程の商談管理 |
| 営業全体の移行 | パイプライン、レポート、顧客対応 | 移行確認中の参照 |
| 移行完了 | 顧客業務の一元管理 | 利用停止に向けた確認 |
対象部門が手順に沿って登録、更新、検索、引き継ぎを実行でき、発生した同期エラーを解消できれば次の部門へ進みます。完了できない操作があれば、入力先、同期ルール、利用者向けの手順を確認します。
一括移行では、切り替え前にデータ移行、業務に必要な設定、外部連携、利用者の操作確認を済ませます。切り替え時期を先に固定せず、現行業務を移行先で実行できることを完了条件にします。
テスト移行では、対象と取込結果を照合し、コンタクトと会社、取引と担当者の関連付けを業務シナリオからたどります。登録から受注後の処理まで完了でき、差異の理由も説明できれば切り替え判定へ進みます。必要な業務が止まる場合や関連先が不明な場合は、原因を修正して同じ手順で再確認します。
次の表は、どちらの方式で検証を進めるかを考えるためのものです。各行を自社の業務に当てはめ、業務を区切れるか、切り替え対象を事前に検証できるかを確認します。現場が登録・更新・引き継ぎを完了でき、管理者が必要な指標を再現できる状態を選択の条件にしてください。
| 比較項目 | 段階的移行 | 一括移行 |
|---|---|---|
| 切り替え時の影響 | 区切った業務ごとに確認する | 対象業務全体を事前に確認する |
| 併用期間 | 両システムを使う業務を管理する | 切り替え前後の入力先を明確にする |
| 同期設計 | 併用するデータの正本と同期方向を決める | 移行前後の差分データの扱いを決める |
| 現場教育 | 部門ごとの引き継ぎを確認する | 切り替え対象の利用者全体を確認する |
| データ管理 | 併用中の更新経路を追跡する | 取込結果と関連付けを切り替え前に照合する |
| 向いている状況 | 業務を区切れ、各段階の終了条件を決められる | 対象業務を事前に検証し、切り替え条件をそろえられる |
移行方式は利用者数だけでは決められません。カスタマイズ、外部連携、データ品質、部門間の業務の切れ目を調べ、移行後も必要な業務を基準に判断します。企業様によって最適な形は異なります。
次の表は人数や件数による判定表ではありません。各項目について、対象業務との依存関係、未解決の問題、テスト結果を記録します。依存関係を切り分けられる範囲は段階的に検証し、切り替え対象の業務を事前に確認できる範囲は一括移行の判定へ進めます。
| 判断項目 | 段階的移行向き | 一括移行向き |
|---|---|---|
| Salesforce利用者数 | 部門ごとに業務と利用者を区切れる | 対象利用者が切り替え前に操作を確認できる |
| カスタムオブジェクト数 | 独自データの用途や関連付けに未確認の点がある | 必要なデータと関連付けを検証済み |
| Apexコード | 必要な処理や例外対応に未確認の点がある | 必要な業務結果を移行先で確認済み |
| 外部システム連携 | 接続先ごとに検証を進める必要がある | 接続先と処理結果を切り替え前に確認済み |
| 移行予算 | 併用中の契約と管理作業を確保できる | 切り替え前の検証と利用者支援を確保できる |
| 移行期限 | 段階ごとの終了条件を契約期限と照合できる | 必要な検証を期限前に完了できる |
| マーケMA先行導入 | マーケティング業務を営業業務から区切れる | 関連する業務をまとめて切り替えられる |
Salesforceで使うオブジェクト、カスタムフィールド、自動化、Apexコード、Visualforceページ、外部連携を棚卸しします。各設定について、利用部門、実行される業務、参照先、停止時の影響を記載します。必要性を説明できる設定は移行検証へ進め、利用実態が不明な設定は担当部門に確認します。
機能名だけで代替できると判断せず、処理中に使うデータや例外対応も確認してください。次の表は、現行機能とHubSpot側で調べる対象を対応させるものです。表の組み合わせは機能の同等性を保証しません。利用環境で設定できる内容を確かめ、現行と同じ入力・分岐・出力を業務シナリオで比較します。
| Salesforce機能 | HubSpot側の確認対象 | 備考 |
|---|---|---|
| Apex コード | ワークフロー、カスタムコード | 読み書きするデータ、分岐、失敗時の処理を洗い出し、必要な業務結果を再現できるか確認する |
| Visualforce | Content Hub、カスタムモジュール | 現行画面で利用者が行う入力・参照・更新を整理し、必要な操作を検証する |
| Process Builder | ワークフロー | 実行条件、分岐、更新対象、失敗時の処理を現行設定と照合する |
| CPQ | HubSpot見積もりツール | 見積条件、承認、出力内容を確認し、必要な処理を利用環境で検証する |
| レポート・ダッシュボード | HubSpotレポート | 対象データ、計算条件、フィルター、利用者が必要とする表示を照合する |
| AppExchange連携 | HubSpotアプリマーケットプレイス | 利用する接続先ごとに対象データ、更新方向、認証、エラー時の復旧方法を確認する |
Process Builderの行では、実行条件、分岐、更新対象、失敗時の処理を現行設定から書き出し、移行先で同じ業務結果を得られるかテストします。AppExchange連携の行では、実際に利用する接続先ごとにデータの受け渡しと復旧手順を確認します。他の行も、必要な機能を利用環境で確認したうえで、入力から出力までの業務結果を比較します。再現できない処理があれば、その業務をSalesforceに残して段階的に検証するか、運用方法を見直します。
取引データを移す前に、営業パイプラインを整理します。ステージ名だけでなく、ステージが変わる条件、入力担当、次の工程で必要な情報を確認します。
| 設計要素 | 確認する内容 |
|---|---|
| 取引ステージ | 営業活動のどの変化を区切りとするか |
| 受注確度 | 見込み金額をどの基準で評価するか |
| ステージ定義 | 誰が見ても同じ状態を判断できるか |
| 必須プロパティ | 次の工程やレポートに必要な情報は何か |
現行のステージ名をそのまま移す前に、現場の行動と管理者の判断に使える定義かを確かめます。入力条件を設定する場合は、担当者が必要な情報を取得できる場面で求めているかを試します。入力できない場面があれば、必須条件か業務手順を修正し、次の工程への引き継ぎを再確認します。
次の表について、現状だけでなく根拠となる設定、業務手順、テスト結果を記録します。カスタマイズ、外部連携、データ品質、業務停止リスクのいずれかに未検証の依存関係があれば、対象を限定して検証します。切り替え対象の業務について担当者、切り替え手順、復旧手順を確定できれば、一括移行の判定へ進みます。
| 判断項目 | 段階的移行を検討しやすい状態 | 一括移行を検討しやすい状態 |
|---|---|---|
| カスタマイズ | 独自処理への依存が強い | 標準機能中心 |
| 外部連携 | 複数の業務システムと接続 | 接続先と用途が整理済み |
| 部門構成 | 部門ごとに業務を分けられる | 共通プロセスで運用している |
| データ品質 | 重複や欠損の整理に時間が必要 | 移行対象を確定できている |
| 教育体制 | 部門単位で支援したい | 全体研修をまとめて実施できる |
| 契約条件 | 併用期間を確保できる | 早期の切り替えが必要 |
| 業務停止リスク | 対象を限定して検証したい | 切り替え準備を集中できる |
段階的移行では、各部門の終了条件を決め、二重管理が続く業務とデータを明確にします。一括移行では、必要な業務を先に成立させ、設定の拡張は利用状況を確認してから判断します。
併用中に重要なのは、データが存在する場所よりも、どこで更新し、どの値を正しい情報として扱うかです。正本が曖昧な項目は同期設定へ進めず、利用部門と更新経路を確認します。
次の表は、営業工程で正本を分ける設計例です。同じ分担を採用する前に、工程が変わる時点、更新権限、引き継ぐ項目を決めてください。同じレコード・項目に異なる更新元を指定していないかも確認します。
| データ種別 | マスターシステム | 同期方向 |
|---|---|---|
| リード・コンタクト | HubSpot | HubSpot → Salesforce |
| 取引パイプライン初期段階 | HubSpot | HubSpot → Salesforce |
| 取引パイプライン後期段階 | Salesforce | Salesforce → HubSpot |
| 受注・売上データ | Salesforce | Salesforce → HubSpot |
データ種別ごとに、主な更新システムと同期方向を記入します。マーケティングを先にHubSpotへ移す場合でも、商談や受注をどちらで更新するかは現行業務から判断します。
| データ種別 | 主な更新システム | 主な同期方向 |
|---|---|---|
| リード、コンタクト | HubSpot | HubSpotからSalesforce |
| 会社、取引先 | 業務担当側のCRM | 定義した正本から片方向 |
| 商談、取引 | SalesforceまたはHubSpot | 担当工程に応じて設定 |
| マーケティング活動 | HubSpot | HubSpotからSalesforce |
| 受注情報 | 受注業務を管理するシステム | 正本から参照先へ同期 |
営業の途中で正本を切り替えるなら、切り替わるステージ、切り替えを実行する担当者、その後に更新できるシステムを明記します。両方の画面で同じ項目を更新する必要がある場合は、競合時の優先ルールと復旧手順をテストしてから運用します。
正本を決めたら、項目ごとの同期ルールに落とし込みます。HubSpotの公式ナレッジでは、同期ルールが4種類あります(出典:HubSpotナレッジ「Map HubSpot properties to Salesforce fields」)。マーケティングを先にHubSpotへ移す段階的移行を例に、次のように割り当てます。名称は例ですので、自社の項目名に置き換えてください。
| 項目の例 | 正本 | 同期ルール |
|---|---|---|
| メールアドレス、氏名 | HubSpot(フォームで取得) | Two-way(両方で更新されるため、最新の値で上書き) |
| 電話番号 | Salesforce | Prefer Salesforce unless blank(Salesforceが空のときだけHubSpotの値を送る) |
| 商談のフェーズ、受注金額 | Salesforce(営業が移行するまで) | Always use Salesforce(HubSpotからは送らない) |
| メール配信の停止状況 | HubSpot | Salesforceへ渡す必要がなければ Don't sync |
| 所有者 | どちらかに決める | 名前とメールアドレスが、アクティブなSalesforceユーザーと一致している必要があります |
数値と制約として、マッピングは1オブジェクトあたり500件まで、標準マッピングは削除できず、止めるには「Don't sync」にします。HubSpotは約15分ごとに両システムの更新を確認するため、保存した直後の反映は保証されません。
コンタクトの照合にはメールアドレスなどの識別子を検討します。ただし、共有アドレスや欠損があるレコードは別途確認が必要です。会社は社名の表記揺れや同名企業を考慮し、会社ドメイン名や既存の識別子を含めて照合方法を決めます。
同期対象は業務上必要なレコードに絞ります。対象に入れる条件を決めたら、条件を満たすレコードと満たさないレコードを使い、意図どおりに同期されるか確認します。スプレッドシートなど別の場所でも同じ顧客情報を更新している場合は、その入力経路を整理してから正本を確定します。
双方向で同じ項目を更新する場合は、どちらの値を優先するかを業務ごとに決めます。競合が起きたら、両側の更新者、更新時刻、値、設定済みの同期方向を並べ、正本の定義と照合します。
エラーは原因別に切り分けます。次の表を使い、修正後のテストレコードが再同期できれば対象を広げます。同じ原因が続く場合はレコードの追加を止め、マッピングまたは入力経路を修正します。
| エラーの原因 | 確認する内容 | 対応の方向性 |
|---|---|---|
| 必須項目の未入力 | 受信側で求められる項目 | 同期前の入力条件を整える |
| 選択肢の不一致 | 両システムの選択肢 | 値の対応表を統一する |
| 権限不足 | 接続ユーザーの権限 | 必要な範囲へ権限を見直す |
| 入力規則への抵触 | Salesforce側の条件 | 同期データを条件に合わせる |
| APIコール制限 | 同期量と処理頻度 | 対象や実行方法を見直す |
原因、修正方法、再発防止策は記録します。担当者が変わっても、どのレコードから確認し、いつ同期を再開するか判断できる状態にします。AIを使ってエラー記録や項目対応表の確認を補助する場合も、正本の決定と設定変更は業務担当者が元データに照らして確認します。
CRM移行では、コンタクトの獲得、取引の作成、顧客化、受注後の請求やサポートまで、各工程で使うシステムを整理します。外部サービスとの連携がある場合は、レコード画面に何が表示されるかに加え、作成・更新・削除をどこで行うかを確認します。
以下の画面は、HubSpotの会社レコード上に外部サービスの取引先カードと関連コンタクトが表示されている例です。画面に見える情報と、実際に更新できる情報を分けて確認する際の参考にしてください。

画面に情報が表示されることだけで、正本や同期方向は判断できません。連携ごとに更新元、表示先、失敗時の確認場所を記入します。担当者がレコードをたどって更新結果を確認できれば、次の工程へ進みます。
移行計画では、日程を埋める前に完了条件を決めます。データの取込結果、現場の日常操作、管理者のレポート、外部連携の処理をそれぞれ確認し、切り替え後の業務が成立するかを判断します。
次の表は一括移行の作業を並べた計画例です。各工程の開始日は、契約条件、作業範囲、前工程のテスト結果から決めます。作業が未完了なら、次の工程の開始条件と日程を見直します。
| 順序 | フェーズ | 主な作業 |
|---|---|---|
| 最初 | 準備・設計 | 現状分析、フィールドマッピング、HubSpot環境構築 |
| 次 | データ移行・テスト | データクレンジング、テスト移行、ワークフローの検証 |
| 最後 | 切り替え・安定化 | 本番移行、トレーニング、必要な併用、Salesforce停止の判定 |
現行データと業務を棚卸しし、対象レコード、利用項目、関連付け、自動化、レポート、外部連携を確認します。続いて、移すものと残すものを決め、フィールドマッピングとHubSpot側の環境を準備します。
テスト移行では、次の業務結果を確認します。
取込件数だけでなく、検索、更新、引き継ぎ、レポート確認まで試します。差異があれば、元データ、マッピング、取込結果を照合して原因を直します。同じ業務シナリオで再確認し、差異の理由を説明できた範囲から切り替え判定へ進めます。
Salesforceの契約更新日や通知期限は、契約書または管理画面で確認します。そのうえで、テスト移行と切り替え判定を終える日程を置きます。期限までに必要な業務テストを完了できない場合は、対象を限定した移行と併用範囲を検討します。
営業チームの切り替え時期は、現場が操作変更と通常業務を両立できるかを確認して決めます。段階的移行なら、各段階の終了条件を「フォームから登録されたコンタクトを営業が確認できる」のような業務結果で示します。一括移行なら、対象業務のテスト結果、差分データの取込方法、問題発生時の連絡先をそろえて判定します。
トレーニングでは画面の名称より、実際の業務シナリオを優先します。利用者に次の操作を試してもらい、手順を見れば自分で完了できるか確認します。
| 業務場面 | 確認する操作 |
|---|---|
| 新規リードへの対応 | コンタクト検索、会社との関連付け、活動記録 |
| 商談の開始 | 取引作成、担当者設定、ステージ更新 |
| 引き継ぎ | 履歴確認、メモ、タスク、関連レコードの確認 |
| 管理者の確認 | パイプライン、レポート、入力漏れの確認 |
| 顧客化後の対応 | 顧客情報、問い合わせ、受注後データの確認 |
操作できない箇所があれば、手順、画面設定、入力条件のどこに原因があるかを確認します。入力項目ごとに利用目的を説明し、実際に使わない項目は移行対象を見直します。担当者が通常業務を完了し、管理者が結果を確認できれば運用へ進めます。
移行後は、同期エラーの有無だけでなく、担当者の操作と管理者の判断が同じデータにつながっているかを確認します。データ、業務、自動化、レポートを順にたどり、途中で確認できない結果があれば原因を修正します。
コンタクト、会社、取引について、移行した各パターンからレコードを確認します。次のようにたどり、意図した関連先になっているか照合します。
関連先が欠けていれば、識別子または取込時の関連付けを修正して再確認します。
重複、空欄、想定外の選択肢が見つかった場合は、移行元の値、フィールドマッピング、同期後の値を並べます。特定の入力経路や同期ルールに原因があれば、その仕組みを修正し、同じ条件のレコードで結果を確かめてから対象を広げます。
ワークフローはテスト用レコードを使い、登録条件、割り当て、通知、プロパティ更新、後続処理を実行履歴からたどります。想定した結果が対象レコードに反映されれば運用へ進み、途中で止まれば分岐条件や権限を修正して再実行します。
レポートはSalesforceとHubSpotで対象期間、対象ステージ、集計条件をそろえて比較します。差があれば、データ欠損、ステージ定義、集計期間、受注日の扱い、フィルター条件を確認します。差の理由を説明できてから、管理指標の参照先を切り替えます。
一元管理、自動化、可視化はつながった業務として確認します。入力したデータが関連付けられ、そのデータで処理が動き、結果をレポートで確認できることが次へ進む条件です。
移行後の問い合わせ先、回答担当、よくある質問、設定変更の受付方法を決めます。担当者が操作に迷ったとき、どの業務で止まり、どのレコードを確認したかを伝えられるようにします。
新しい項目の追加依頼では、既存項目で代替できない理由、入力担当、利用する業務、参照するレポートを確認します。利用目的を説明できない項目は作成を保留し、現行の入力とレポートを見直します。日常業務に必要な操作と確認ができるようになったら、利用状況を見て自動化やレポートの拡張を判断します。
StartLinkは、HubSpotゴールドパートナーとして150社以上のHubSpot支援に携わっています。Salesforceから HubSpotへの移行支援では、公開ページに掲載している次の工程で、準委任で伴走します。企業様によって最適な形は異なります。
サービスページには、いきなりSalesforceを停止する必要はなく、双方を併用しながら移行する方法も選べると案内しています。カスタムオブジェクト、Apex、レポート、外部連携は、1対1の移行ではなく再設計を勧めています。期間の目安は3〜5か月程度で、データ量やカスタマイズの内容で変わります。最も業務が区切りやすい領域から始めて、段階的に広げます。標準連携で足りない会計・電子契約・チャットの連携は、自社開発のSyncシリーズで補えるかも確認します。公式連携の設定の詳細は連携ガイドを、導入全体のご支援はHubSpot導入・構築支援をご覧ください。
電子契約にクラウドサインを使う場合は、StartLinkが提供するSync for CloudSignで、HubSpotの取引から契約書を作成し、締結済みPDFをHubSpot FilesやGoogleドライブに保管できます。
ここでは、併用中の費用、独自処理、データ競合、移行方式の変更について、何を確認してから判断するかを整理します。契約条件は実際の契約で、機能や同期結果は利用環境で確かめてください。
併用期間の費用は、両システムの契約条件に加え、同期エラーの監視や環境管理に必要な作業も含めて比較します。実際の契約範囲と更新条件を確認し、部門ごとにHubSpotで完了させる業務、Salesforce側に残る業務、利用範囲を縮小する条件を記入します。
対象部門がSalesforceへ戻らず業務を完了でき、必要なデータを確認できれば、その部門の利用範囲を見直します。未完了の業務があれば併用範囲を保ち、不足する操作やデータを検証します。
コードの量だけでなく、何の業務を支え、どのデータを読み書きし、失敗時にどう復旧するかで判断します。処理ごとに業務目的を確認し、HubSpot側の設定、運用変更、外部連携を含めて実現方法を比較します。
必要な入力から出力までをテストできれば移行対象へ進めます。重要な例外処理を再現できない場合は、その業務を残した段階的移行か、業務手順の見直しを検討します。
競合した項目の更新前の値、両システムの更新者と更新時刻、設定済みの同期方向を並べます。決めていた正本と照合して値を修正し、同じ競合を生む更新経路が残っていないか確認します。
同期方向または業務権限を修正した後、同じ操作で競合が再発しないことをテストします。修正結果と再開担当を記録できた段階で同期を再開します。
残っている移行範囲、データ整合性、外部連携、利用者の操作を改めて確認したうえで判断します。Salesforce側の入力を止める条件、差分データの取込担当、照合結果の承認者を決めます。
差分の取込結果と関連付けを確認でき、切り替え後の業務シナリオを完了できればHubSpot側の入力を始めます。停止条件や照合担当が決まらなければ、一括切り替えへ進みません。
SalesforceとHubSpotの連携・併用では、移行方式より先に業務とデータの境界を決めます。データ種別ごとに正本、更新担当、同期方向、例外条件を書き出し、空欄がある領域は利用部門に確認します。
段階的移行は、対象を区切って業務と同期結果を確認し、各段階の終了条件を満たしてから範囲を広げます。一括移行は、データの照合、関連付け、自動化、外部連携、利用者の操作を確認してから切り替えます。どちらも、担当者が入力した情報を次の業務と管理判断に使えることが判定の基準です。
まずは次の順序で現行環境を整理してください。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。現行業務の棚卸し、正本と同期方向の整理、段階的移行と一括移行の切り替え条件についてご相談いただけます。
移行対象の洗い出しと切り替え手順を詳しく検討する場合は、移行ガイドと失敗要因の記事を確認してください。HubSpot側のCRM運用や現場への定着を検討する段階では、入力ルールと利用者支援を扱う記事が参考になります。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化(ERP/CRM/SFA/MAの導入)」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
株式会社StartLink 代表取締役。累計150社以上のHubSpotプロジェクト支援実績を持ち、Claude CodeやHubSpotを軸にしたAI活用支援・経営基盤AXのコンサルティング事業を展開。
HubSpotのトップパートナー企業や大手人材グループにて、エンタープライズCRM戦略策定・AI戦略ディレクションを経験した後、StartLinkを創業。現在はCRM×AIエージェントによる経営管理支援を専門とする。