Salesforce から HubSpot への移行は、何をコピーしないと決めたかで評価されます。レコード、自動化、レポートは、コピー、アーカイブ、再構築の3つに分けられます。意図的に仕分けを行ったチームは、信頼できる CRM を手にします。仕分けを省いたチームは、6週間で混乱をそのまま新しい環境へ持ち込むことになります。
私はスピードに反対しているわけではありません。ある HubSpot パートナーは、業務を止めずに6週間で移行できると謳っていますが、機械的な作業に関しては妥当な約束です。問題は、このスケジュールが測りやすい部分だけを測っていることです。
6週間というスケジュールが誤ったものを測っている理由
スケジュールが示すのは、データが新しいシステムに着地する時期だけです。そのデータが到着後も同じ意味を持つかどうかは、何も教えてくれません。Salesforce から HubSpot への移行は、予定どおりに完了しても、1年分のレポートが壊れた状態を残すことがあります。
2つのプラットフォームは、異なるデータモデルで作られています。Salesforce では、カスタムオブジェクト、レコードタイプ、入力規則を何年にもわたって積み重ねることができ、Salesforce 開発者ドキュメントを見ると、その構造の多くが設定可能であることが分かります。HubSpot は、オブジェクト、プロパティ、関連付けというよりフラットなモデルを採用しており、HubSpot 開発者ドキュメントで説明されています。Salesforce 固有の構造に依存していたものは、すべて変換するか設計し直す必要があります。
私たちが話を聞いたあるお客様は、約1,300件の重複レコードと、誰もテストしていないパイプラインステージの遷移を抱えたまま、すでに移行の期日が決まっていました。日付そのものは問題ではありませんでした。リスクは、答えの出ていない問いにありました。
Salesforce から HubSpot への移行の仕分け:コピー、アーカイブ、再構築
ここで私が使っているフレームワークをご紹介します。すべてのデータオブジェクト、自動化、レポートに対して、ひとつの問いを投げかけます。ビジネスは今もこれをもとに行動しているか、という問いです。答えが「はい」で、かつデータがきれいであればコピーします。過去の価値はあっても誰も行動の根拠にしていないなら、アーカイブします。人が行動の根拠にしていても、その仕組みが回避策にすぎないなら、再構築します。
| 資産 | 基本の判断 | 理由 |
|---|---|---|
| アカウント、コンタクト、進行中の取引 | 重複排除後にコピー | 営業担当が毎日使うため |
| 失注した取引と過去のアクティビティ | アーカイブ | 分析には役立つが、稼働中の CRM ではノイズになるため |
| ライフサイクルステージと取引ステージ | 再構築 | 古いステージは古い習慣を反映しているため |
| ワークフロー型の自動化 | 再構築 | 多くは継ぎはぎに継ぎはぎを重ねたものであるため |
| 流入元とキャンペーンのアトリビューション | 慎重にコピー | タイムスタンプの再作成は高くつくため |
良くも悪くも、時間がかかるのは再構築の列です。そして、価値が生まれるのもそこです。
データ:移行前に重複を排除し、すべてをコピーせずアーカイブする
最も安く直せる重複は、インポート前に直す重複です。別のお客様は、人員とエンリッチメント用のクレジットの両方が足りず、この規模の Salesforce データベースをきれいにするのは難しいと話していました。そのまま移していれば、データの問題が HubSpot の問題に変わり、しかもコンタクト単位の課金が上乗せされていたでしょう。
そこで目安となるルールがあります。営業サイクルに照らして妥当な期間内に、アクティビティも進行中の関連付けもないレコードは、CRM の外にアーカイブします。使い道が出てきたときには戻せます。しかし、営業担当がいったん習慣を築いてしまった稼働中のポータルを、元のきれいな状態に戻すのは簡単ではありません。
アトリビューションは例外です。流入元のデータや初回接触のタイムスタンプは、後から再構築するのが非常に難しく、扱いを誤ったフィールドは、のちにダイレクト流入として分類されて表面化することがよくあります。このパターンについてはHubSpot で AI 経由の流入がダイレクト流入になってしまう仕組みで解説しています。
自動化と請求ロジック:成果から再構築する
Salesforce の自動化を HubSpot にそのままコピーすれば、その癖までコピーすることになります。あるお客様の請求スケジュールが好例です。15日に成約した案件は、その時点で半額、翌月1日に残り半額を請求する仕組みで、Salesforce ではこれを扱うのにぎこちない方法を使っていました。正しい進め方は、そのぎこちない回避策を再現することではありません。経理上どのような結果になるべきかを決め、新しいシステムでそこに至る最短経路を作ることです。
私の実感では、成熟した組織で長く使われている自動化の約3分の1は、昔の制約のためだけに存在しています。この数字は調査ではなく、プロジェクトの経験に基づく私自身の目安です。自動化を一覧にするときは、それぞれの横に成果を書き込んでください。今も生きている成果のないものは、廃止の候補です。
レポート:経営陣が尋ねる問いから再構築する
そのまま移行したレポートは、ステージや流入元、あるいは「有望」なリードについての古い定義の上に作られたレポートです。まず、経営陣が毎週尋ねる5つか6つの問いから出発し、それらを新しいデータモデル上で最初に再構築してください。そのうえで旧来の数値と比較し、説明できる差異をすべて書き留めます。
この比較は、ダッシュボードそのものよりも重要です。新しいパイプラインの数値が旧来より8%低い場合、その原因が重複排除なのか、ステージ定義の変更なのか、バグなのかを知っておく必要があります。それがなければ、稼働開始後の最初の予測会議は、ツールをめぐる議論になってしまいます。
Salesforce から HubSpot への移行にかかる、ライセンス以外の本当のコスト
このテーマで目にする検索結果の多くは、スケジュールとフィールドマッピングの話で終わっており、総コストには触れていません。ここでは、ベンチマークではなく私自身の前提に基づく試算例を示します。営業担当12名が、システムに慣れ直してレコードを修正する6週間のあいだ、それぞれ週2時間を失うとします。これは約144時間にあたり、コンサルタントの工数や連携の作り直しは含まれていません。誰も見積もっていなかったレポートの再構築が加われば、移行されなかったものに対する請求額は、移行そのものの請求額を上回ります。
最初の90日間の定着も同じ理屈です。営業担当が新しい CRM を使うのは、ステージが自分たちの売り方に合っていて、レコード上のデータが信頼できるときです。それは研修の成果ではなく、再構築の成果です。
Salesforce にとどまるべきとき
これについて、明快なルールは持ち合わせていません。複雑なテリトリー階層、深い権限モデル、大幅にカスタマイズされたオブジェクトなどは、HubSpot では現状に見合わない可能性がある領域です。正直な提案が、とどまること、あるいは段階的に移行することである場合もあります。パートナーがそれを一度も口にしないなら、理由を尋ねてみてください。
Salesforce から HubSpot への移行に関する事例のチェックリストでは、契約前にどのような実績の証拠を求めるべきかを扱い、HubSpot 導入パートナーのスコアカードでは、作業を担う相手をどう評価するかを扱っています。すでに移行を終えたもののポータルに違和感がある場合は、壊れたポータルと再構築の見積もりを見分ける方法が次の読み物です。こうしたプロジェクトの進め方については、Salesforce から HubSpot への移行サービスと、より広いレベニューオペレーションの取り組みをご覧ください。
私の提案はこうです。Salesforce から HubSpot への移行では、6週間は簡単な部分だと割り切り、注意は仕分けに注いでください。