Salesforce から HubSpot への移行事例では、次の4点が示されているべきです。移行されなかったものは何か、データディクショナリの状態は移行前後でどう変わったか、ワークフローのうちコピーではなく再構築されたものはいくつか、そして3か月後にも営業担当者がシステムを使い続けているか、という点です。「6週間で完了、業務への影響なし」といった見出しは、そのどれも証明しません。わかるのはプロジェクトがどれだけ早く終わったかだけで、稼働を始めたシステムが機能するかどうかはわかりません。
私はこの種の事例を数多く読んできました。たとえば HubSpot パートナーのトップページに載っているお客様の声には、中断なく6週間で移行が完了したと書かれていることがあります。それは本当だと思います。ただし、「中断がなかった」ことと「何も壊れなかった」ことは別の主張であり、引用されているのは前者だけだということも知っています。
スピードが移行事例で最も弱い証拠である理由
スピードは報告しやすく、実現するのも簡単です。重複排除、項目マッピングの判断、ステージ定義、権限設定といった、レコードを使えるものにするための作業を省けば、レコードは素早く移せます。スケジュール上は見栄えが良くなりますが、そのツケは3か月目に表れます。
私の経験則では、事例が信頼に値する度合いは、どれだけ失敗や損失を認めているかに比例します。損失がまったく書かれていない話は、著者が確認しなかったか、あなたに見せたくなかったかのどちらかです。そのため、Salesforce から HubSpot への移行事例を読むときは、タイムラインを飛ばして「失ったもの」の欄を探してください。
最初に求めるべきは、移行されなかったものの一覧です
どの移行でも、何かは置き去りになります。問題は、パートナーが何を置いていくかを把握し、意図的に判断し、本番稼働前にクライアントへ伝えていたかどうかです。
よくある対象は、アトリビューション履歴、ファイルや添付ファイル、Salesforce 専用機能に依存する自動化、レポートのロジック、権限構造です。オブジェクトの順序も重要です。HubSpot のインポートに関するドキュメントに明記されているとおり、関連付けはレコードをどのように、いつ読み込むかに左右されるため、順序を誤ると、コンタクト、会社、取引の間の関係が気づかないうちに失われます。
確認方法は次のとおりです。パートナーに、過去のプロジェクトの「置き去りにしたもの」のリストを求めてください。要約ではなく、リストそのものです。良いリストには項目が並び、それぞれに理由(アーカイブした、別の形で再構築した、誰も使っていないため廃止した)と、承認した担当者が記されています。「重要なものは何も失われていません」という答えが返ってきたなら、得られる情報はありますが、相手が意図したものとは違うでしょう。
Salesforce から HubSpot への移行事例におけるデータディクショナリの状態
データディクショナリとは、各項目が何を意味し、誰が管理し、どの値が許容され、どのシステムが書き込むのかを記した文書です。稼働して5年ほど経つ Salesforce の環境の多くには、誰も信頼できるものがありません。何百もの項目があり、同じ意味のものが複数あり、誰にも説明できないものも少なくありません。
そうした混乱をそのまま1対1で移行することを、私は「リフト&シフト」と呼んでいます。新しいポータルが、ロゴだけ変わった古いポータルのように感じられる最も一般的な原因です。優れた事例には、移行前後の項目数が書かれています。カスタムプロパティが400から150に減ったのであれば、誰かが判断を下した証拠です。400のままであれば、そのプロジェクトは家具を動かしただけです。
重複も、同じ話を小さくしたものです。私たちが話を聞いたあるお客様は、移行元のCRMに約1,300件の重複レコードを抱え、期限が迫る中でパイプラインのステージ遷移も未検証のまま移行に臨んでいました。この2点こそがプロジェクトの本体です。プラットフォームの切り替えは簡単な部分です。HubSpot の重複排除に関するガイダンスで説明されているように、2つのプラットフォームは重複の扱いが異なるため、事例にはクレンジングをいつ行ったか、どのレコードを残すかを誰が決めたかを書くべきです。
ワークフローの再構築:数を数え、廃止したものを尋ねる
自動化は移行できません。作り直されるものであり、判断が問われるのは再構築の場面です。Salesforce のフローをすべて HubSpot で作り直すパートナーは、あなたの技術的負債をそのまま持ち込んだことになります。
3つの数字を尋ねてください。旧システムのワークフロー数、再構築した数、廃止した数です。そのうえで、それぞれの例を1つずつ挙げてもらいます。たとえば、誰にも説明できないリード割り当てルールは廃止し、誰もが頼りにしている更新リマインダーは再構築し、誰も開かないダッシュボードに数値を送っていたステージ変更トリガーは削除すべきでしょう。事例がこうした内訳を示せないなら、その再構築は機械的なものだったということです。
ここは、ルーティングやステージ定義が試される場面でもあります。当社の記事壊れたポータルと再構築の見積もりを見分ける方法では、同じ考え方を逆の側から扱っています。
本番稼働後の定着こそが、唯一意味のある成果です
このテーマの検索結果は、ほとんどが本番稼働で終わっています。そこは請求書が止まる地点であると同時に、リスクが始まる地点でもあります。営業担当者はスプレッドシートに戻り、マネージャーは予測を信用しなくなり、マーケティングは静かに独自のレポートを作り直します。
CRM移行から90日後の営業担当者の定着率について、明確な業界ベンチマークは持っていませんし、それを引用する人は信用していません。事例に求めたいのはもっと素朴なことです。30日、60日、90日時点での担当者ごとのログイン数と活動記録数、旧四半期と比べた予測精度、旧システムを完全に停止した日付。それに、経理と営業の両方が承認したレポートです。旧環境でアトリビューションを扱っていたなら、それがどうなったかも確認してください。AIの影響を受けたトラフィックやタグのないトラフィックの多くは、すでに HubSpot で直接流入として記録されています。これは直接流入として処理されるAI経由の流入で取り上げたとおりです。
その Salesforce から HubSpot への移行事例は、御社のような会社の話ですか?
事例が証拠になるのは、その対象が御社に似ている場合だけです。レコード数、カスタムオブジェクト数、稼働中の連携数、ユーザー数の4点を尋ねてください。カスタムオブジェクトのない15席のチームと、CPQを使う300席のチームは、同じ名前で呼ばれていても別のプロジェクトです。
次に、総額でいくらかかったかを尋ねてください。見積もりはあくまで1つの数字です。そこにパートナー費用、両システムが並行稼働する間のライセンス重複、再教育で失われる営業担当者の時間、手戻りを加えます。仮定のみを使った計算例です。営業担当者40人が6週間にわたり週2時間を失うと、手戻りを含める前の段階で、営業に使えたはずの時間が480時間失われます。優れたパートナーは、これが価格の正直な姿なので、一緒に説明してくれます。
Salesforce から HubSpot への移行事例を見るときの簡単なチェックリスト
契約の前に、実在する1つのプロジェクトについて、パートナーに次のものを見せてもらってください。
- 置き去りにしたものの一覧(担当者付き)
- 移行前後の項目・プロパティ数
- 再構築したワークフローと廃止したワークフロー
- 30日、60日、90日時点の定着状況と予測の数値
- 当初の見積もりに対する総コスト
以上の5つの資料です。これらを持っているチームなら、数分で提出してくれるはずです。私たちも自社のプロジェクトを文書化することを誇りにしているので、変に聞こえるかもしれませんが、そうなります。持っていないチームは、あなたが知るべきことをすでに教えてくれています。
こうした証拠が私たち自身の仕事でどのように見えるかを知りたい場合は、まずCRM移行の事例と、Salesforce から HubSpot への移行サービスの対象範囲をご覧ください。私たちも同じリストで評価してください。この姿勢はCRM以外の仕事にも当てはまります。ポジショニングよりも証拠が勝るという主張は、SEOの順位とAIによる引用や、導入支援会社にAEOを後付けしても不十分な理由でも述べています。