「決して安くない費用を払っているのに、機能のほとんどを活用できていない」 「設定が難しく、使いこなせる人が社内におらず、いつまでたっても定着しない」 「切り替えたい気持ちはある。ただ、これまでのデータが膨大で、移行に踏み切れない」 HubSpotへの移行のご相談で、いちばんよく聞く悩みがこの3つです。 費用に見合う活用ができていない。設定が難しくて、現場に根づかない。それでも、長年ためてきたデータの引っ越しを考えると、なかなか踏み切れない。この3つが重なって、「変えたいのに、動けない」という状態になっている会社が少なくありません。 最初にはっきりお伝えしたいことがあります。 Salesforceが悪いわけではありません。 Salesforceは世界で最も広く使われているCRM(顧客管理の仕組み)のひとつで、大きな組織や複雑な商流を支える力は群を抜いています。問題はツールの優劣ではなく、その費用と設定の難しさに見合う体制が、いまの自社にあるかどうか。服のサイズ選びと同じで、良い服でも体に合わなければ動きづらい、それだけの話です。 この記事では、SalesforceからHubSpotへの移行を検討している方に向けて、移行すべきかの判断基準、移行の全体像(計画→設計→データ移行→定着)、そして「データが膨大で踏み切れない」というためらいの解き方を、支援の現場でくり返し見てきた実感をもとに整理します。 まず考えたい。移行「すべきか」の判断基準 移行の話に入る前に、いちばん大事な問いから始めます。そもそも移行すべきなのか、です。 移行は小さくない仕事です。データの引っ越し、業務の組み替え、現場への説明。それだけの労力をかける価値があるかどうかは、次のような視点で判断できます。 いちばん大きな判断材料は、費用と活用のバランス 移行を検討する理由として、実際にいちばん多いのが費用の話です。ただし、大事なのは「高いか安いか」ではありません。「いま払っている費用に見合う活用が、できているか」です。 Salesforceの費用は、ライセンスのプラン、追加のオプション、ユーザー数、そして設定変更を外部へ依頼する運用費と、使い方に応じて積み上がっていく構造です。フル活用している会社にとっては妥当な投資ですが、次のような状態なら、費用と活用のバランスが崩れているサインです。 ほとんどログインしていない人の分まで、ライセンス費用を払い続けている 上位プランを契約しているのに、使っているのは基本機能だけ 小さな設定変更のたびに外部への依頼費用がかかり、運用費が読めない 更新のたびに費用は増えるのに、営業の成果や業務の楽さは変わっていない 費用はライセンス料だけでなく、運用の外注費や社内の手間まで含めた「全体の費用」で見てください。そのうえで活用が一部にとどまっているなら、移行を検討する十分な理由になります。 あわせて見たい「合っていない」サイン 専任の管理者がいない。設定変更のたびに外部へ依頼が発生し、小さな改善が後回しになっている 使っている機能がごく一部。高い費用を払いながら、実際は商談の一覧管理にしか使っていない 入力が定着していない。営業の記録が残らず、結局Excelや個人のメモに情報が散らばっている レポートを作れる人が限られている。数字を見たいのに、特定の担当者に頼まないと出てこない マーケティングとの連携に別ツールの継ぎ足しが増えている。ツール間の連携維持だけで手間がかかっている 逆に、移行を急がなくてよい場合 一方で、次のような状況なら、Salesforceを使い続ける方が合理的なことも多いです。 複雑な承認の流れや独自の商流が、深い作り込みによって業務の中核として動いている 専任の管理者や開発体制があり、運用がきちんと回っている 基幹システムとの連携が広く深く、移行の影響範囲が非常に大きい 判断の軸:「Salesforceの機能に不満があるか」ではなく、「いまの費用と体制に見合う活用ができているか」。費用が活用に見合っておらず、今後もそれを活かす体制を作る予定がないなら、移行を検討する意味があります。 移行の全体像。4つの段階で進める 移行すると決めたら、次は進め方です。私たちは移行を「計画」「設計」「データ移行」「定着」の4段階で捉えることをおすすめしています。 いきなりデータの引っ越しから始めたくなりますが、ここはこらえてください。データ移行は4段階のうちの3番目。その前の2段階が、移行の成否をほぼ決めます。 移行期間の目安 通常:3〜4ヶ月程度 利用規模が大きい場合:3ヶ月〜半年程度(カスタム項目や連携するシステムが多い場合など) 第1段階:計画 ― 何のために移るのかを言葉にする 最初にやるのは、移行の目的をはっきりさせることです。「Salesforceをやめたい」は目的ではありません。「営業全員が自分で入力し、数字を毎週の会議でそのまま使える状態にしたい」のように、移行後にどうなっていたいかを言葉にします。 あわせて、関係者と時期の整理もこの段階で行います。契約の更新月、営業の繁忙期、マーケティング施策の予定。切り替えの時期は、これらを避けて選ぶのが基本です。 第2段階:設計 ― 旧環境の再現ではなく、あるべき形を描く ここがいちばんの分かれ道です。設計とは、HubSpot上でどんな項目を持ち、商談の段階をどう区切り、誰がどこまで見られるようにするかを決める作業です。 やってしまいがちなのが、Salesforceの画面や項目をそのままHubSpotに再現しようとすること。Salesforceに合わなさを感じて移行するのに、その環境を写し取ってしまっては、合わない部分ごと引っ越すことになります。移行は、長年の運用で溜まった複雑さを一度リセットできる貴重な機会です。「今の業務に本当に必要な項目はどれか」からゼロベースで考え直しましょう。 第3段階:データ移行 ― 対応関係を決めて、試してから、本番 設計が固まってはじめて、データの引っ越しに入ります。SalesforceとHubSpotではデータの持ち方(オブジェクトの構造)が違うため、「Salesforceのこのデータを、HubSpotのどこに入れるか」の対応表を作るところから始めます。この対応の考え方は、後の章でくわしく説明します。 大事なのは、いきなり全件を移さないこと。まず一部のデータで試験的に移行し、件数・項目の中身・担当者の紐づきを確認してから本番に進みます。 第4段階:定着 ― 移行の完了は「使われ始めた日」 データが移り、画面が切り替わっても、移行はまだ終わりではありません。営業メンバーが日々の活動を自然にHubSpotへ記録し、会議でHubSpotの数字が使われるようになって、はじめて移行は完了します。 切り替え後の1〜2ヶ月は、質問にすぐ答えられる窓口を用意し、入力ルールを最小限に絞り、小さなつまずきをこまめに拾う。この地道な期間が、その後の何年かを決めます。 計画:移行の目的と時期を言葉にする 設計:旧環境の再現ではなく、あるべき形を描く データ移行:対応表→試験移行→本番の順で 定着:使われ始めてはじめて完了 期間の目安:通常3〜4ヶ月程度。規模によっては半年程度を想定 「移行しないもの」を決める勇気 データ移行の話になると、多くの方がこう考えます。「せっかく貯めたデータだから、全部持っていきたい」。 気持ちはよく分かります。ただ、支援の現場で見てきた限り、移行がこじれる原因の多くは「全部持っていこうとすること」にあります。 数年分の活動履歴、退職した担当者の古いメモ、一度も更新されていない見込み客の情報。これらをすべて移そうとすると、データの整理・変換の工数がふくらみ、移行後のHubSpotも初日から「よく分からない古いデータ」であふれます。新しい環境の気持ちよさが、最初から損なわれてしまうのです。 持っていくかどうかの判断基準 迷ったら、次の3つの問いで仕分けしてみてください。 直近1〜2年で更新・参照されたか。長く触られていないデータは、移行後も触られない可能性が高い 今後の営業・マーケティング活動に使うか。「いつか使うかも」は、たいてい使いません 契約や法令の関係で保存が必要か。必要なら移行ではなく「保管」で対応できないかを考える ここで大事なのは、移行しない=捨てる、ではないということです。Salesforceのデータは一括で書き出せます。移行対象から外したデータも、CSVなどの形で書き出して社内に保管しておけば、必要になったときに参照できます。「HubSpotに入れるもの」と「書き出して保管するもの」の2つに分ける、と考えると気持ちが楽になるはずです。 まとめ:全部移すのではなく、「HubSpotで今後使うデータ」だけを移す。残りは書き出して保管。この仕分けが、移行の工数と移行後の使いやすさの両方を大きく左右します。 オブジェクト対応の考え方 ― リードはどこへ行くのか データ移行でいちばん質問が多いのが、この話です。SalesforceとHubSpotは、データの入れ物(オブジェクト)の構造が少し違います。まず全体の対応関係を見てみましょう。 SalesforceHubSpot気をつけたい点 リードコンタクト独立したオブジェクトがなく、ライフサイクルステージで表現 取引先責任者コンタクトリードと同じ入れ物に統合される 取引先会社ほぼそのまま対応 商談取引フェーズの区切り方を設計し直す好機 活動(ToDo・行動)アクティビティメモ・通話・会議などの種類に振り分け ケースチケットService Hubの利用有無を先に確認 カスタムオブジェクトカスタムオブジェクト利用プランの確認と、そもそも必要かの見直し 最大のポイントは「リードとコンタクトの統合」 表の中でいちばん大きな構造の違いが、リードの扱いです。 Salesforceでは、見込み段階の相手は「リード」、商談化した相手は「取引先責任者」と、別々のオブジェクトで管理します。一方HubSpotでは、どちらも「コンタクト」というひとつの入れ物で管理し、その人が今どの段階にいるかを「ライフサイクルステージ」という項目で表します。見込み客も既存顧客も同じ場所にいて、札の色だけが違う、というイメージです。 移行の際は、Salesforceのリードを「ライフサイクルステージ=リード」のコンタクトとして、取引先責任者をより進んだ段階のコンタクトとして取り込む、という対応づけが基本形になります。このとき、リードと取引先責任者に同じ人が重複して存在していないかの確認も忘れずに。統合される分、重複がそのまま持ち込まれやすいのです。 カスタム項目は「全部作り直す」前提で棚卸しを 長く使ったSalesforce環境には、カスタム項目が数百個あることも珍しくありません。これを機械的に全部HubSpotへ作ると、設計の章で触れた「旧環境の再現」に逆戻りします。項目ごとに「最後に入力されたのはいつか」「レポートで使われているか」を確認し、生きている項目だけを移す。地味ですが、ここで手を抜かないことが移行後の使いやすさに直結します。 まとめ:オブジェクト対応の基本は「リード・取引先責任者→コンタクト」「取引先→会社」「商談→取引」。構造の違いを機械的に写すのではなく、統合や項目の棚卸しを通じて、データをきれいにする機会として使いましょう。 並行稼働期間をどう設計するか データを移したら、すぐSalesforceを解約してよいのでしょうか。ここも相談の多いところです。 結論から言うと、一定の並行稼働期間を置くのが安全です。切り替え直後は、「あの案件のデータが見当たらない」「この数字、前と合っているか」といった確認が必ず発生します。旧環境が参照できる状態にあると、こうした確認がすぐでき、現場の不安もやわらぎます。 並行稼働の期間と役割分担 期間は、組織の規模やデータ量によりますが、数週間から1〜2ヶ月程度の幅で設定