ほとんどの Salesforce から HubSpot への移行は、マッピング作業として設定されてしまいます。誰かが Salesforce のフィールドリストをエクスポートし、HubSpot のプロパティリストの隣に貼り付け、両者の間に線を引き、インポートのウィンドウを予約する。それは移行ではなく、既存の技術的負債を新しい方言に翻訳しているだけです。Salesforce から HubSpot へ移る本当の作業は、フィールド単位のトリアージです、1 行ずつ、そのフィールドが HubSpot に居場所を得るのか、先に変換されるのか、それとも cutover を生き残らないのかを決めること。マッピング表はその意思決定の出力であって、意思決定そのものではありません。
なぜ今これが重要か
Series B 以降の Salesforce インスタンスには、何百もの custom field が存在しますが、フィールドの数自体は問題の小さな部分です。より大きな問題は、それらフィールド上の構造化データの半分未満しか実際の意思決定に使われていないということ、これは Harvard Business Review のデータ戦略に関する仕事で記録された結果で、その後の年月を経てよく耐えてきた知見です。フィールド単位の HubSpot への移植は、役に立たない半分も役に立つ半分と一緒に運んでしまい、チームはその後、新しいプラットフォームの中にデッドウェイトを引きずり続けることになります。移行のウィンドウは、CRM のライフサイクルの中で唯一、フィールドを削除するコストが安い瞬間です。それを飛ばせば、次にスキーマに触れる人は、前進ではなく、引き継いだ遺産との戦いに追われることになります。
マッピング doc ではなく、トリアージ表
Salesforce から HubSpot への移行を駆動する成果物は、Salesforce フィールドごとに 1 行と、3 つの意思決定列(keep, edit, delete)を持つスプレッドシートです。これは継承したインスタンスに対するより広範な brownfield 監査を支配するのと同じ keep / edit / delete のフレームですが、より狭い対象に向けられています、workflow や report ではなく、フィールドそのもの。同じフレームのインスタンス単位のバージョンは、HubSpot や Salesforce のインスタンスを継承することについての姉妹記事に書かれています。各フィールドの行には、Salesforce API name、フィールドの型、過去 90 日に変更された Record における populate 率、提案する HubSpot プロパティ、変換、行をサインオフする責任者の名前が記録されます。
典型的な mid-stage の Salesforce インスタンスでは、トリアージ後はおおよそ 3 分の 1 が delete、4 分の 1 が edit、残りが keep のままになります。数字よりも規律のほうが重要です、すべてのフィールドは意思決定であり、すべての意思決定の隣には名前が書かれています。
Salesforce のフィールド型と HubSpot のプロパティ型
両システムは型システムを共有していません。そして、ミスマッチがフィールド単位の移行ミスのほとんどが起こる場所です。実際に重要なカテゴリ:
Picklist と dropdown / radio / checkbox
Salesforce の multi-select picklist には、HubSpot にきれいな等価物がありません。HubSpot の multi-checkbox プロパティは構造的なケースをカバーしますが、Salesforce の record-type ごとの picklist 値は、値が実際には共有されていない意味論である場合、HubSpot 側では別々のプロパティへ展開されることが多くあります。移行の瞬間こそが整理の瞬間です。20 を超える値を持ち、その半分が過去半年に選ばれていない picklist は、実際の record に現れる値だけに編集します。
Formula フィールド
Salesforce の formula フィールドは移行されません。HubSpot 側では 3 つのいずれかに展開されます、formula が同じ record 上の他のプロパティの純関数であれば calculation property、トリガーで通常のプロパティへ書き込む workflow、あるいは背後のロジックがもう不要なら delete。診断は、その formula が読んでいるフィールドが keep か edit か delete か、ということ。入力がすべて delete に向かう formula フィールドは、推移的に delete です。
Lookup と master-detail のリレーション
Salesforce の Lookup は HubSpot の association に翻訳されますが、その翻訳は 1:1 ではありません。HubSpot の association label は意味を持ちます、"primary signer" 対 "economic buyer" 対 "champion"、Salesforce ではこれをしばしば custom lookup field と横にある role picklist で符号化しています。きれいな移行は、lookup プラス role のパターンを単一のラベル付き association に統合します。これは保守が短く、レポートに対しても壊れにくくなります。master-detail の関係は別の問いを示します、子オブジェクトが本当に HubSpot custom object であるべきなのか、それとも別の標準オブジェクト上に乗り、親が association として表されるべきなのか。
Owner、queue、sharing-rule フィールド
Salesforce の sharing rule や queue ownership は、紙の上では無害に見えるフィールドの中に可視性のロジックを隠していることがよくあります。"Account Region"、"Deal Pod"、"Owner Role" は、レポートのためではなく、3 層下の sharing rule を駆動するために存在することが多いのです。これらのフィールドを削除する前に、sharing rule の影響範囲を必ず追跡してください。HubSpot のパーミッションモデルはより浅く、より宣言的です。これらフィールドの一部は、新システムでは team の所属や partition rule に吸収されますが、依存関係をマッピングしてから初めて消すことができます。
履歴データの問題
Salesforce から HubSpot への移行は、必ずどれだけの履歴を持ってくるかという問いに突き当たります。正直な答えは、ほとんどの場合「すべて」ではありません。私たちが守る既定値は、過去 90 日の activity history、年齢を問わず開いているすべての opportunity の全ライフサイクル、そしてまだ更新サイクルにあるすべての deal の closed-won の record です。それ以外は、チームが参照はできるが編集はできない Salesforce read-only アーカイブにとどめます。線を厳しく引く理由は、活動の履歴データが移行時間の最大の貢献者であり、前向きな意思決定への最小の貢献者だからです。元担当者の 5 年分の activity task をインポートしたチームは、より遅い HubSpot インスタンスと、ほぼ同じ forecast 精度を手にすることになります。
現場からのパターン
EMEA の Series B 段階の B2B SaaS チームが、Account・Contact・Opportunity の各オブジェクトに 600 を少し超える custom field を持つ Salesforce インスタンスのまま、移行の途中で私たちのところへ来ました。当初のスコープは 1:1 のフィールドマップ、すべての Salesforce フィールドが HubSpot プロパティを得て、インポートが走り、チームが再教育を受ける、というものでした。最初のトリアージのパスで、フィールドのおよそ 35% が即削除としてマークされ、その多くは数年前に誰も覚えていないキャンペーンのために数百の record にだけ populate された custom field でした。さらに 25% は edit でした、picklist の整理、formula の展開、Lookup から association への翻訳、HubSpot のより厳密なタイムゾーン処理に着地させる必要がある日付フィールドが少々。残りの 40% は keep のままでした。HubSpot ポータルは約 240 の custom property で本番に出て、チームが本当に保守できる表面積です、そのインスタンス上での最初の四半期の forecasting は、この 2 年間で初めて、call の前に手作業のデータ整合性パスを必要としない四半期になりました。
解決策:トリアージのプレイブック
Salesforce から HubSpot への移行を実行しようとしているチームへ:
- マッピングの線を引く前に、フィールドのインベントリを引き出してください。すべての標準・カスタムオブジェクト上の Salesforce custom field ごとに 1 行。API name、フィールド型、過去 90 日に変更された record における populate 率、そして依存メタデータ、workflow rule、validation rule、formula 参照、sharing rule。
- keep / edit / delete のパスを実行してください。各行は意思決定と、名指しされたオーナーを得ます。最近の record で populate が 10% を切るフィールドは、誰かが書面で擁護しない限り、既定で delete です。
- マッピングの前に picklist を整理してください。picklist の値を実際の record に現れるものに削り、整理後のリストを HubSpot にマップします。死んだ値はインポートしないでください。
- formula フィールドを calculation・workflow・delete に展開してください。そのまま移行する formula フィールドは存在しません。ひとつずつ再実装するか、再ルーティングするか、削除します。
- Lookup を HubSpot の association label に翻訳してください。lookup プラス role のパターンはラベル付き association に集約されます。custom object は、HubSpot 側でデータモデルが本当に必要としている場合に限って、その旅を勝ち取ります。
- 可視性を担うフィールドを削除する前に、sharing rule の影響範囲をマップしてください。Salesforce sharing rule を駆動する owner・region・pod・role のフィールドは、ただ消えることはできません。HubSpot の team・partition rule・role ベースの権限へと翻訳され、その翻訳はフィールドごとに文書化されます。
- インポートを走らせる前にスプレッドシートをサインオフしてください。トリアージ表は cutover の成果物です。HubSpot のインポートはそのスプレッドシートの関数であり、並行する別作業ではありません。フィールドがサインオフされていなければ、それは動きません。
ステップ 1 から 7 がプロジェクトの 80% です。実際のインポートは金曜の午後の作業です。
Checkpoint がどこで関わるか
フィールド単位のトリアージは、Salesforce から HubSpot への移行が綺麗に出るか、新しいロゴをまとった同じインスタンスとして出てしまうかを決定する仕事です。私たちは触れるすべての CRM migration でこの作業を実行しており、これがレガシーシステムの下流にある HubSpot implementation へのアプローチの背骨です。トリアージがプロジェクトであるなら、出来上がったインスタンスを使うオペレーティングモデルがそれを耐久あるものにします、それが続きの revenue operations の仕事です。Salesforce から HubSpot への移行をスコープしていて、会話がマッピング表から始まっているなら、インポートのウィンドウを予約する前に、ぜひ私たちに相談してください。
出典
- "What's Your Data Strategy?" Harvard Business Review, 2017 年 5–6 月号. hbr.org
- Lemkin, Jason. "Which CRM Should You Use in 2026/2027? Follow the Agents." SaaStr, 2026 年 4 月. saastr.com