「SalesforceからHubSpotへ移行したい。でも、何から手をつければいいのかわからない」——移行を検討し始めた企業から、最初に聞くのはこの言葉です。
長年使ってきたSalesforceには、大量のデータと複雑な設定が溜まっています。それをまるごと別のツールに移すとなれば、不安になるのは当然です。実際、進め方を間違えて途中で頓挫したり、移行はできたものの運用が回らなくなったりするケースは存在します。
ただ、先にお伝えしたいのは、移行は正しい手順で進めれば、大きな失敗は避けられるということです。怖いのは移行そのものではなく、手順を飛ばすことです。
私はHubSpot Japanのカスタマーサクセスマネージャーとして200社以上を支援し、現在はSalesforceからHubSpotへの移行支援を専門に行っています。この記事では、要件定義からリリースまでの全ステップと、つまずかないための考え方を解説します。
移行プロジェクトの全体ステップ
まず、移行プロジェクトの全体像です。大きく、以下の流れで進みます。
- 業務フローのヒアリング → 要件定義
- 設計（要件定義書として「どんな設計で・何を・どう実現するか」を提示）
- 実装
- テスト
- UAT（ユーザー受入テスト。実際に使う方々に試してもらう）
- フィードバックを受けて改善
- リリース
特別な流れではありません。しかし、この流れを飛ばさず、順番に進めることが基本であり、最大の失敗予防策です。
よくあるのは、「データを移すだけだから」と要件定義を軽く済ませ、いきなり実装に入ってしまうケースです。すると、移行の終盤になって「この業務が回らない」「このデータがない」という問題が次々と発覚します。終盤での手戻りは、序盤の何倍ものコストがかかります。急がば回れ——この言葉が最もよく当てはまるのが、CRMの移行プロジェクトです。
最重要の準備：スコープと要件を最初に固める
全ステップの中で、成否を最も左右するのは最初の要件定義です。業務フローのヒアリングを通じて、「何をどう実現するのか」をしっかり確定させること。ここが固まっていれば、後の工程は淡々と進みます。
そして、要件定義の前提として極めて重要なのが、「プロジェクトのスコープ」を最初に決めておくことです。
移行プロジェクトでは、進めるうちに「あれもやりたい」「これも直したい」という要望が必ず出てきます。長年の運用で溜まった不満が、移行を機に一気に噴き出すからです。気持ちはよくわかります。しかし、期間内にやりたいことを全部盛り込もうとして時間が足りなくなるケースは、本当に多いのです。
だからこそ、「契約期間内にどこまでやるか」を最初に決める。その線引きの上で、要件定義をしながら「できること」を確定していく。スコープの外に出た要望は、リリース後の次のフェーズに回す。この規律が、プロジェクトを守ります。
データ移行の進め方：「全部移さない」が鉄則
移行の中心となるのが、データ移行です。ここでの鉄則をひとことで言えば、**「全部移さない」**です。
まず棚卸しと分析から始める
いきなり全データを移行しようとしてはいけません。まずやるべきは、Salesforceの棚卸しです。
どんな種類のデータが、どれだけの件数あり、どんな項目を持っていて、それが実際にどれだけ使われているか——これを一つひとつ分析します。同時に、業務の面からも「Salesforceを実際にどう使っているか」を現場にヒアリングします。データの実態と業務の実態、両方を把握して初めて、「何を移すべきか」が判断できるようになります。
必要なデータだけを移行する——移行を機に「断捨離」する
棚卸しをすると、必ず見つかるものがあります。Salesforceに最初から用意されていたものの一度も使っていないデータの入れ物、過去のキャンペーンで使ったきり放置されているデータ、退職者が作った誰も中身を知らない項目——。
こうしたものを、移行の段階で取捨選択します。イメージとしては、引っ越しと同時に断捨離をするということです。使っていないものまで新居に運び込めば、運送費がかさむだけでなく、新居が最初から散らかった状態になります。CRMも同じで、不要なデータを移せば移行の工数が膨らみ、HubSpotが初日からゴミの混ざった状態でスタートしてしまいます。
大切なのは、意図的に「移さない部分」を作っていくことです。「念のため全部」は、移行においては悪手です。
移行手法は4つ、状況に応じて選ぶ
実際にデータを移す方法は、大きく4つあります。
- データインポート——ファイルに書き出して取り込む、最もシンプルな方法
- アプリ連携による移行——SalesforceとHubSpotをつなぐ連携機能を使う方法
- プログラムによる移行——両ツールの接続口を使い、専用のプログラムを書いて移行する方法
- サードパーティの移行ツール——移行専用の外部ツールを使う方法
どれが正解ということはなく、データの量・複雑さ・予算・期間といったプロジェクトの状況に合わせて最適な方法を選びます。中でもプログラムによる移行は、速く・正確で・問題が見つかったときの修正も容易なため、条件が合えば有力な選択肢です。私自身、大規模な移行ではこの方法を中心に使っています。
移行は「経験者」がやるべき
ここで、正直にお伝えしておきたいことがあります。データ移行は、実装者の経験に大きく左右される領域だということです。
経験の浅い人が移行を行うと、何が起きるか。同じ顧客のデータが重複して大量に生成される。移行したかったはずのデータが移行できていない。移行の途中でデータが壊れる——。こうしたミスは、単なる手戻りでは済みません。壊れたデータや重複したデータの修正は非常に大変で、ここで膨大な時間を食い、プロジェクト全体が止まるケースも多いのです。
移行は一度きりの作業だからこそ、移行実績のある人が担当すること。これは費用の問題ではなく、リスクの問題として考えていただきたいポイントです。
最大の落とし穴：「移行」と「改善」を同時にやらない
手順の話をしてきましたが、移行プロジェクトで最もつまずくポイントを、ひとつだけ挙げるとすればこれです。「移行」と「改善」を同時にやろうとすること。 これは私自身、過去に痛い思いをして学んだことでもあります。
CRMへ「移行する」ことと、移行した上で「改善する」ことは、実は別の作業です。ところが移行のタイミングでは、「せっかくだから」とデータの持たせ方を完全に変えたり、新しい管理の仕方を試したりしたくなります。
これをやると、どうなるか。元の状態を再現することもできず、かといって改善もうまくいかず、中途半端な状態に陥ります。何か問題が起きたときに、「移行のミスなのか、新しいやり方が悪いのか」の切り分けすらできなくなるのです。
だからこそ、発注側にもぜひ理解しておいていただきたいのが、「移行の成功」には2種類あるということです。
- まず、今の状態を新しいCRM（HubSpot）に**「再現」**する
- その上で、HubSpotに移行したことを活かして**「さらに良くする」**
この2つを、順番にやる。まず再現、次に改善。地味に聞こえるかもしれませんが、この順番を守ったプロジェクトと守らなかったプロジェクトでは、結果がまったく違います。
発注側（お客様側）が準備・協力すべきこと
移行は、支援会社に丸投げして終わるものではありません。発注側の準備と協力が、成功率を大きく左右します。具体的には3つです。
1. 業務フローを構造化して伝える
自社の業務フローを、コンサル側にしっかり伝えてください。「誰が、どんな順番で、何をして、どこに何を記録しているか」——これをできる限り整理した形で伝えられると、要件定義が格段にスムーズになります。完璧な資料である必要はありません。箇条書きでも図でも、構造化しようとした跡があるだけで、ヒアリングの質が変わります。
2. 「シンプル化する」という意思を持つ
これが最も重要です。SalesforceからHubSpotへの移行は、簡単に言えば**「多くのことができるツール」から「よりシンプルなツール」への移行**です。
正直に申し上げると、Salesforceと全く同じことができるとは思わない方がいいです。できることは減ります。しかしそれは悪いことではありません。Salesforceの多機能さを持て余していたからこそ、移行を検討しているはずだからです。
だからこそ、データの断捨離・不要な設定の断捨離を行い、「移行を機に業務をシンプルにするんだ」という意思を持って取り組んでください。
最もよくないのは、「なんとかSalesforceを完全再現しよう」とすることです。それをやると、HubSpotの設計思想に合わない使い方になり、運用に無理が出て、不必要に複雑化します。結果、「シンプルにしたくて移行したのに、余計複雑になった」という本末転倒が起きます。発注側が「シンプル化する」という姿勢で協力してくださると、移行は格段に成功しやすくなります。
3. 技術的制約の中での落としどころを一緒に考える
SalesforceとHubSpotには、それぞれ得意・不得意があります。「Salesforceでやっていたこの管理を、HubSpotではどう実現するか」——ここには必ず、制約の中での落としどころを探る場面が出てきます。
そのとき、「できないなら困る」で止まるのではなく、「では自社の業務をどう合わせるか」を自分たちでも考える姿勢を持っていただけると、良い着地点が見つかります。CRMは支援会社のものではなく、御社が使い続けるものだからです。
まとめ
SalesforceからHubSpotへの移行の基本は、次の順番に集約されます。
スコープを決める → 棚卸しして必要なデータだけ移す → 経験者が最適な手法で移行する → まず再現し、その後に改善する。
そして、成功と失敗を分けるのは、発注側が「シンプル化する」という意思を持てるかどうかです。Salesforceでやっていたことを完全再現しようとするのではなく、この機会に業務をシンプルにする——その発想を持てた会社の移行は、うまくいきます。
よくある質問
Q. SalesforceからHubSpotへの移行は、どんな手順で進みますか？
A. 業務フローのヒアリングによる要件定義→設計→実装→テスト→UAT（ユーザー受入テスト）→改善→リリース、という流れで進みます。中でも重要なのは最初の段階で、「契約期間内にどこまでやるか」というプロジェクトのスコープを最初に決めることが、成功の最大の鍵です。
Q. データ移行で気をつけるべきことは何ですか？
A. 全部移さないことです。まずSalesforceのデータを棚卸しし、実際に使われているものだけを選んで移行します。移行を機に不要なデータを断捨離するイメージです。また、データ移行は実装者の経験に大きく左右される領域のため、重複や欠落・データ破損を避けるには、移行実績のある人が担当することが重要です。
Q. 移行プロジェクトで一番失敗しやすいポイントはどこですか？
A. 「移行」と「改善」を同時にやろうとすることです。移行と同時にデータの持たせ方や管理方法まで変えると、元の状態の再現も改善も中途半端になります。まず今の状態をHubSpot上に再現し、安定してから改善に着手する——この順番を守ることが、失敗を避ける最大のポイントです。
SalesforceからHubSpotへの移行のご相談はHarekaへ
Harekaは、SalesforceからHubSpotへの移行支援を専門としています。要件定義からデータ移行、リリース後の定着まで、この記事でお伝えした手順に沿って一貫して支援します。
代表の岩間が全案件を一貫して担当する体制のため、途中での引き継ぎや担当変更はありません。HubSpot Japanのカスタマーサクセスマネージャーとして200社以上を支援した経験と、Salesforceにも実際に触れてきた経験の両方をもとに、両ツールの制約を踏まえた現実的な落としどころをご提案します。数十万件規模のデータをプログラムによる移行で欠落ゼロで移した実績もあります。
「移行を決めたわけではないが、進め方だけ知りたい」という段階でも、ぜひお気軽にご相談ください。